ARM: OMAP: i2c, gpio, spi, regulator and mmc DTS updates

Hi Tony,

Here are the remaining DTS patches for 3.4.

On top of the previous pull request, I just added the MMC DTS since the driver adaptation just got queued.

It will be still be good to have that for 3.4 if possible, otherwise we will have a bunch of drivers DT adapted but no DTS file to use them :-(

This series is based on your lo/dt-part2 branch.

Thanks,
Benoit

The following changes since commit 328ae2cb50af2f96b6061eb462aa92966a462bbc:
Ilya Yanok (1):
arm/dts: mt_ventoux: very basic support for TeeJet Mt.Ventoux board

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.4/dts/all

Benoit Cousson (11):
arm/dts: twl6030: Add DTS file for twl6030 PMIC arm/dts: twl4030: Add DTS file for twl4030 PM + Audio IC arm/dts: omap4-panda: Add twl6030 and i2c EEPROM arm/dts: omap4-sdp: Add twl6030, i2c3 and i2c4 devices arm/dts: omap3-beagle: Add twl4030 and i2c EEPROM
ARM: OMAP2+: board-generic: Remove i2c static init arm/dts: OMAP4: Add gpio nodes
arm/dts: OMAP3: Add gpio nodes
arm/dts: OMAP4: Add SPI controller nodes arm/dts: OMAP3: Add SPI controller nodes arm/dts: omap4-sdp: Add ks8851 ethernet SPI device

Rajendra Nayak (3):
arm/dts: twl: Pass regulator data from dt arm/dts: OMAP4: Add mmc controller nodes and board data arm/dts: OMAP3: Add mmc controller nodes and board data

 arch/arm/boot/dts/omap3-beagle.dts  |   49 +++++++++++++++
 arch/arm/boot/dts/omap3.dtsi        |  102 ++++++++++++++++++++++++++++++
 arch/arm/boot/dts/omap4-panda.dts   |   56 +++++++++++++++++
 arch/arm/boot/dts/omap4-sdp.dts     |   97 +++++++++++++++++++++++++++++
 arch/arm/boot/dts/omap4.dtsi        |  117 +++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/twl4030.dtsi      |   39 ++++++++++++
 arch/arm/boot/dts/twl6030.dtsi      |   86 +++++++++++++++++++++++++
 arch/arm/mach-omap2/board-generic.c |   37 +----------
 arch/arm/mach-omap2/devices.c       |    4 +-
 arch/arm/mach-omap2/gpio.c          |    8 ++-
 10 files changed, 557 insertions(+), 38 deletions(-)
 create mode 100644 arch/arm/boot/dts/twl4030.dtsi
 create mode 100644 arch/arm/boot/dts/twl6030.dtsi

Quoted 6 lines · Cousson, Benoit

Hi Tony,

Here are the remaining DTS patches for 3.4.

On top of the previous pull request, I just added the MMC DTS since the driver adaptation just got queued.

Quoted 2 lines

It will be still be good to have that for 3.4 if possible, otherwise we will have a bunch of drivers DT adapted but no DTS file to use them :-(

This might be doable as a follow-up patch series at the end of the merge window or at -rc1 when the related driver changes have been merged.

Arnd and Olof, what do you guys think?

Quoted 14 lines · Tony Lindgren

Quoted 8 lines · Cousson, Benoit

Hi Tony,

Here are the remaining DTS patches for 3.4.

On top of the previous pull request, I just added the MMC DTS since the driver adaptation just got queued.

It will be still be good to have that for 3.4 if possible, otherwise we will have a bunch of drivers DT adapted but no DTS file to use them :-(

This might be doable as a follow-up patch series at the end of the merge window or at -rc1 when the related driver changes have been merged.

Quoted 1 line

Arnd and Olof, what do you guys think?

I'll have to look at the patches more closely, but from the diffstat it definitely looks ok for a later merge once the driver is in. If you can rebase the branch on top of the mmc tree (or the merge of that tree with whatever else is needed), it should give us a bisectable history and I can stick it into a late/* branch right away.

Hi Arnd and Olof,

Quoted 24 lines · Arnd Bergmann

Quoted 15 lines · Tony Lindgren

Quoted 11 lines · Cousson, Benoit

Hi Tony,

Here are the remaining DTS patches for 3.4.

On top of the previous pull request, I just added the MMC DTS since the driver adaptation just got queued.

It will be still be good to have that for 3.4 if possible, otherwise we will
have a bunch of drivers DT adapted but no DTS file to use them :-(

Quoted 5 lines

This might be doable as a follow-up patch series at the end of the merge window or at -rc1 when the related driver changes have been merged.

Arnd and Olof, what do you guys think?

Quoted 9 lines

I'll have to look at the patches more closely, but from the diffstat it definitely
looks ok for a later merge once the driver is in. If you can rebase the branch on
top of the mmc tree (or the merge of that tree with whatever else is needed), it
should give us a bisectable history and I can stick it into a late/* branch right
away.

FYI, MMC DT adaptation just got merged, I2C, GPIO, SPI, regulator DT adaptation were already merged before, so it means that this branch can be merged to take advantage of all the DT adapted drivers.

Quoted 3 lines · Benoit

FYI, MMC DT adaptation just got merged, I2C, GPIO, SPI, regulator DT adaptation were already merged before, so it means that this branch can be merged to take advantage of all the DT adapted drivers.

I've pulled this in as late/omap-dt, included in next/dt3 and for-next. I'll let it sit in linux-next for at least one day before it's sent in. Since it's just device tree additions, risk for regressions should be low.

Benoit, Tony,

Quoted 9 lines · Olof Johansson

Quoted 3 lines · Benoit

FYI, MMC DT adaptation just got merged, I2C, GPIO, SPI, regulator DT adaptation were already merged before, so it means that this branch can be merged to take advantage of all the DT adapted drivers.

I've pulled this in as late/omap-dt, included in next/dt3 and for-next. I'll let it sit in linux-next for at least one day before it's sent in. Since it's just device tree additions, risk for regressions should be low.

As you've noticed, this didn't make it into 3.4 due to the window closing early. :(

I've renamed the branch in arm-soc to omap/dt-missed-3.4 and merged it into next/dt for the 3.5 merge window.

Benoit, Tony,

Quoted 5 lines · Olof Johansson

Quoted 3 lines · Benoit

FYI, MMC DT adaptation just got merged, I2C, GPIO, SPI, regulator DT adaptation were already merged before, so it means that this branch can be merged to take advantage of all the DT adapted drivers.

Quoted 4 lines

I've pulled this in as late/omap-dt, included in next/dt3 and for-next. I'll let it sit in linux-next for at least one day before it's sent in. Since it's just device tree additions, risk for regressions should be low.

As you've noticed, this didn't make it into 3.4 due to the window closing early. :(

I've renamed the branch in arm-soc to omap/dt-missed-3.4 and merged it into next/dt for the 3.5 merge window.