Patchwork [GIT,PULL] make mach-omap2 boot with device tree only for v3.14

login
register
mail settings
Submitter Tony Lindgren
Date Dec. 10, 2013, 2:42 a.m.
Message ID <pull-1386643347-596413>
Download mbox
Permalink /patch/299253/
State New
Headers show

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/omap3-board-removal-signed

Comments

Tony Lindgren - Dec. 10, 2013, 2:42 a.m.
The following changes since commit f2e2c9d9b4087b74eb9e00d8dfac148354cb0b71:

  ARM: dts: Fix booting for secure omaps (2013-12-06 15:30:43 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/omap3-board-removal-signed

for you to fetch changes up to 736e812636ea72be444b85fa7e92554967459069:

  ARM: OMAP2+: Remove unused platform init code and headers (2013-12-08 14:15:46 -0800)

----------------------------------------------------------------
We can now finally make mach-omap2 to boot with device tree only and get
rid of over 20k lines of platform init code that way.

Most basic devices already work using device tree based initialization
and the remaining devices can be initialized using platform data
with pdata-quirks.c.

So for most missing boards it's just a question of adding a .dts file
that should be fairly similar to one of the existing .dts files as
we've tried to cover all basic omap3 board types.

For people getting started updating their board files to for device
tree, there are some basic instructions in commit 8dc8b3ddf5d7
(ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2
DT only for booting).

Please also note that there are also some related fixes making their way
into the mainline kernel that are needed for some use cases:

PM off-idle for omap3 and wake-up events need the following two patches:

[PATCH] of/platform: Fix no irq domain found errors when populating interrupts
http://lkml.org/lkml/2013/11/22/520

[PATCH] ARM: dts: Fix omap serial wake-up when booted with device tree
http://www.spinics.net/lists/devicetree/msg13374.html

EMAC Ethernet on am3517 boards needs:

[PATCH] net: davinci_emac: Fix platform data handling and make usable for am3517
http://patchwork.ozlabs.org/patch/296351/

Ethernet for boards using smc91x needs:

[PATCH v2] net: smc91x: Fix device tree based configuration so it's usable
http://www.spinics.net/lists/netdev/msg258913.html

----------------------------------------------------------------
Aaro Koskinen (1):
      ARM: OMAP2+: dts: add n8x0 onenand

Javier Martinez Canillas (3):
      ARM: OMAP2+: Remove legacy smsc911x and smc91x GPMC support
      ARM: OMAP2+: Remove unnecesary include in GPMC driver
      ARM: OMAP2+: Remove legacy board-flash.c

Tony Lindgren (34):
      mfd: twl-core: Fix passing of platform data in the device tree case
      Merge branch 'dt-regressions' into omap-for-v3.13/fixes-take4
      ARM: dts: Add basic device tree support for omap2430 sdp
      ARM: dts: Add basic Nokia N8X0 support
      ARM: dts: Add basic support for omap3 LDP zoom1 labrador
      Merge branch 'omap-for-v3.13/fixes-take4' into omap-for-v3.14/board-removal
      Merge branch 'omap-for-v3.14/dt' into omap-for-v3.14/board-removal
      ARM: OMAP2+: Add support for board specific auxdata quirks
      ARM: OMAP2+: Add device tree compatible revision checks for n8x0
      ARM: OMAP2+: Make n8x0 behave better with device tree based booting
      ARM: OMAP2+: Add quirks support for n8x0
      ARM: OMAP2+: Remove legacy booting support for n8x0
      ARM: OMAP2+: Remove board file for H4
      ARM: OMAP2+: Remove legacy board file for 2430sdp
      ARM: OMAP2+: Remove legacy mux code for omap2
      ARM: OMAP2+: Remove legacy hwmod entries for omap2
      Merge branch 'omap-for-v3.14/board-removal' into omap-for-v3.14/omap3-board-removal
      ARM: OMAP2+: Add support for legacy auxdata for twl
      ARM: OMAP2+: Use pdata quirks for emac on am3517
      ARM: dts: Add basic devices on am3517-evm
      ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2 DT only for booting
      ARM: OMAP2+: Remove legacy serial.c
      ARM: OMAP2+: Remove legacy hsmmc.c
      ARM: OMAP2+: Remove legacy i2c.c platform init code
      ARM: OMAP2+: Remove legacy PM init
      ARM: OMAP2+: Remove legacy twl4030 platform init code
      ARM: OMAP2+: Remove legacy usb-host.c platform init code
      ARM: OMAP2+: Remove legacy muxing for usb-tusb6010.c
      ARM: OMAP2+: Remove legacy usb-musb.c platform init code
      ARM: OMAP2+: Remove legacy hwmod mux code
      ARM: OMAP2+: Remove legacy mux code
      ARM: OMAP2+: Remove legacy data from hwmod for omap3
      ARM: OMAP2+: Remove legacy emac code
      ARM: OMAP2+: Remove unused platform init code and headers

 arch/arm/boot/dts/Makefile                         |    5 +
 arch/arm/boot/dts/am3517-evm.dts                   |   29 +
 arch/arm/boot/dts/omap2420-n800.dts                |    8 +
 arch/arm/boot/dts/omap2420-n810-wimax.dts          |    8 +
 arch/arm/boot/dts/omap2420-n810.dts                |    8 +
 arch/arm/boot/dts/omap2420-n8x0-common.dtsi        |   99 +
 arch/arm/boot/dts/omap2430-sdp.dts                 |   49 +
 arch/arm/boot/dts/omap3-ldp.dts                    |  231 +++
 arch/arm/mach-omap1/Kconfig                        |   26 +
 arch/arm/mach-omap1/i2c.c                          |   83 +
 arch/arm/mach-omap2/Kconfig                        |  125 --
 arch/arm/mach-omap2/Makefile                       |   51 +-
 arch/arm/mach-omap2/am33xx-restart.c               |    2 -
 arch/arm/mach-omap2/am35xx-emac.c                  |  115 --
 arch/arm/mach-omap2/am35xx-emac.h                  |   15 -
 arch/arm/mach-omap2/board-2430sdp.c                |  273 ---
 arch/arm/mach-omap2/board-3430sdp.c                |  633 ------
 arch/arm/mach-omap2/board-am3517crane.c            |  150 --
 arch/arm/mach-omap2/board-am3517evm.c              |  379 ----
 arch/arm/mach-omap2/board-cm-t35.c                 |  771 --------
 arch/arm/mach-omap2/board-cm-t3517.c               |  337 ----
 arch/arm/mach-omap2/board-devkit8000.c             |  655 -------
 arch/arm/mach-omap2/board-flash.c                  |  245 ---
 arch/arm/mach-omap2/board-flash.h                  |   62 -
 arch/arm/mach-omap2/board-h4.c                     |  365 ----
 arch/arm/mach-omap2/board-ldp.c                    |  425 ----
 arch/arm/mach-omap2/board-n8x0.c                   |  239 +--
 arch/arm/mach-omap2/board-omap3beagle.c            |  596 ------
 arch/arm/mach-omap2/board-omap3logic.c             |  251 ---
 arch/arm/mach-omap2/board-omap3pandora.c           |  630 ------
 arch/arm/mach-omap2/board-omap3stalker.c           |  438 -----
 arch/arm/mach-omap2/board-omap3touchbook.c         |  396 ----
 arch/arm/mach-omap2/board-overo.c                  |  572 ------
 arch/arm/mach-omap2/board-rx51-peripherals.c       | 1323 -------------
 arch/arm/mach-omap2/board-rx51-video.c             |   67 -
 arch/arm/mach-omap2/board-rx51.c                   |  142 --
 arch/arm/mach-omap2/board-rx51.h                   |   11 -
 arch/arm/mach-omap2/board-ti8168evm.c              |   62 -
 arch/arm/mach-omap2/common-board-devices.h         |    3 +-
 arch/arm/mach-omap2/common.h                       |   16 +-
 arch/arm/mach-omap2/devices.c                      |   34 -
 arch/arm/mach-omap2/dss-common.c                   |    1 -
 arch/arm/mach-omap2/gpmc-smc91x.c                  |  186 --
 arch/arm/mach-omap2/gpmc-smc91x.h                  |   42 -
 arch/arm/mach-omap2/gpmc-smsc911x.c                |  100 -
 arch/arm/mach-omap2/gpmc-smsc911x.h                |   35 -
 arch/arm/mach-omap2/gpmc.c                         |    1 -
 arch/arm/mach-omap2/hsmmc.c                        |  518 -----
 arch/arm/mach-omap2/hsmmc.h                        |   53 -
 arch/arm/mach-omap2/i2c.c                          |   97 -
 arch/arm/mach-omap2/i2c.h                          |   13 -
 arch/arm/mach-omap2/include/mach/serial.h          |   66 -
 arch/arm/mach-omap2/io.c                           |    2 -
 arch/arm/mach-omap2/msdi.c                         |   70 -
 arch/arm/mach-omap2/mux.c                          | 1161 -----------
 arch/arm/mach-omap2/mux.h                          |  357 ----
 arch/arm/mach-omap2/mux2420.c                      |  690 -------
 arch/arm/mach-omap2/mux2420.h                      |  282 ---
 arch/arm/mach-omap2/mux2430.c                      |  793 --------
 arch/arm/mach-omap2/mux2430.h                      |  370 ----
 arch/arm/mach-omap2/mux34xx.c                      | 2061 --------------------
 arch/arm/mach-omap2/mux34xx.h                      |  402 ----
 arch/arm/mach-omap2/omap4-keypad.h                 |    8 -
 arch/arm/mach-omap2/omap_device.c                  |    2 +
 arch/arm/mach-omap2/omap_hwmod.c                   |  160 +-
 arch/arm/mach-omap2/omap_hwmod_2420_data.c         |  147 --
 arch/arm/mach-omap2/omap_hwmod_2430_data.c         |  274 ---
 .../omap_hwmod_2xxx_3xxx_interconnect_data.c       |  134 +-
 .../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c |  201 +-
 .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c |  166 +-
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |   72 +-
 .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |    7 -
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |  854 +-------
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    8 -
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |   10 -
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c          |   10 -
 arch/arm/mach-omap2/omap_hwmod_common_data.h       |    5 -
 arch/arm/mach-omap2/omap_twl.c                     |  314 ---
 arch/arm/mach-omap2/pdata-quirks.c                 |  107 +-
 arch/arm/mach-omap2/pm.c                           |  164 +-
 arch/arm/mach-omap2/serial.c                       |  335 ----
 arch/arm/mach-omap2/serial.h                       |    1 -
 arch/arm/mach-omap2/twl-common.c                   |  570 ------
 arch/arm/mach-omap2/twl-common.h                   |   66 -
 arch/arm/mach-omap2/usb-host.c                     |  496 -----
 arch/arm/mach-omap2/usb-musb.c                     |  114 --
 arch/arm/mach-omap2/usb-tusb6010.c                 |   21 -
 arch/arm/plat-omap/Kconfig                         |   26 -
 arch/arm/plat-omap/Makefile                        |    3 -
 arch/arm/plat-omap/i2c.c                           |  116 --
 drivers/mfd/twl-core.c                             |   15 +-
 91 files changed, 773 insertions(+), 20862 deletions(-)
 create mode 100644 arch/arm/boot/dts/omap2420-n800.dts
 create mode 100644 arch/arm/boot/dts/omap2420-n810-wimax.dts
 create mode 100644 arch/arm/boot/dts/omap2420-n810.dts
 create mode 100644 arch/arm/boot/dts/omap2420-n8x0-common.dtsi
 create mode 100644 arch/arm/boot/dts/omap2430-sdp.dts
 create mode 100644 arch/arm/boot/dts/omap3-ldp.dts
 delete mode 100644 arch/arm/mach-omap2/am35xx-emac.c
 delete mode 100644 arch/arm/mach-omap2/am35xx-emac.h
 delete mode 100644 arch/arm/mach-omap2/board-2430sdp.c
 delete mode 100644 arch/arm/mach-omap2/board-3430sdp.c
 delete mode 100644 arch/arm/mach-omap2/board-am3517crane.c
 delete mode 100644 arch/arm/mach-omap2/board-am3517evm.c
 delete mode 100644 arch/arm/mach-omap2/board-cm-t35.c
 delete mode 100644 arch/arm/mach-omap2/board-cm-t3517.c
 delete mode 100644 arch/arm/mach-omap2/board-devkit8000.c
 delete mode 100644 arch/arm/mach-omap2/board-flash.c
 delete mode 100644 arch/arm/mach-omap2/board-flash.h
 delete mode 100644 arch/arm/mach-omap2/board-h4.c
 delete mode 100644 arch/arm/mach-omap2/board-ldp.c
 delete mode 100644 arch/arm/mach-omap2/board-omap3beagle.c
 delete mode 100644 arch/arm/mach-omap2/board-omap3logic.c
 delete mode 100644 arch/arm/mach-omap2/board-omap3pandora.c
 delete mode 100644 arch/arm/mach-omap2/board-omap3stalker.c
 delete mode 100644 arch/arm/mach-omap2/board-omap3touchbook.c
 delete mode 100644 arch/arm/mach-omap2/board-overo.c
 delete mode 100644 arch/arm/mach-omap2/board-rx51-peripherals.c
 delete mode 100644 arch/arm/mach-omap2/board-rx51-video.c
 delete mode 100644 arch/arm/mach-omap2/board-rx51.c
 delete mode 100644 arch/arm/mach-omap2/board-rx51.h
 delete mode 100644 arch/arm/mach-omap2/board-ti8168evm.c
 delete mode 100644 arch/arm/mach-omap2/gpmc-smc91x.c
 delete mode 100644 arch/arm/mach-omap2/gpmc-smc91x.h
 delete mode 100644 arch/arm/mach-omap2/gpmc-smsc911x.c
 delete mode 100644 arch/arm/mach-omap2/gpmc-smsc911x.h
 delete mode 100644 arch/arm/mach-omap2/hsmmc.c
 delete mode 100644 arch/arm/mach-omap2/hsmmc.h
 delete mode 100644 arch/arm/mach-omap2/include/mach/serial.h
 delete mode 100644 arch/arm/mach-omap2/mux.c
 delete mode 100644 arch/arm/mach-omap2/mux.h
 delete mode 100644 arch/arm/mach-omap2/mux2420.c
 delete mode 100644 arch/arm/mach-omap2/mux2420.h
 delete mode 100644 arch/arm/mach-omap2/mux2430.c
 delete mode 100644 arch/arm/mach-omap2/mux2430.h
 delete mode 100644 arch/arm/mach-omap2/mux34xx.c
 delete mode 100644 arch/arm/mach-omap2/mux34xx.h
 delete mode 100644 arch/arm/mach-omap2/omap4-keypad.h
 delete mode 100644 arch/arm/mach-omap2/omap_twl.c
 delete mode 100644 arch/arm/mach-omap2/serial.c
 delete mode 100644 arch/arm/mach-omap2/serial.h
 delete mode 100644 arch/arm/mach-omap2/twl-common.c
 delete mode 100644 arch/arm/mach-omap2/twl-common.h
 delete mode 100644 arch/arm/mach-omap2/usb-host.c
 delete mode 100644 arch/arm/mach-omap2/usb-musb.c
 delete mode 100644 arch/arm/plat-omap/i2c.c
Russell King - ARM Linux - Dec. 10, 2013, 2:35 p.m.
On Mon, Dec 09, 2013 at 06:42:27PM -0800, Tony Lindgren wrote:
> We can now finally make mach-omap2 to boot with device tree only and get
> rid of over 20k lines of platform init code that way.
> 
> Most basic devices already work using device tree based initialization
> and the remaining devices can be initialized using platform data
> with pdata-quirks.c.
> 
> So for most missing boards it's just a question of adding a .dts file
> that should be fairly similar to one of the existing .dts files as
> we've tried to cover all basic omap3 board types.
> 
> For people getting started updating their board files to for device
> tree, there are some basic instructions in commit 8dc8b3ddf5d7
> (ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2
> DT only for booting).
> 
> Please also note that there are also some related fixes making their way
> into the mainline kernel that are needed for some use cases:
> 
> PM off-idle for omap3 and wake-up events need the following two patches:

While this is good, what seems to be happening is a complete switch
from one method of booting to a different method of booting with no
compatibility inbetween.  We're going from only supporting the ATAG
booting protocol for these platforms in v3.12 to only supporting the
DT booting protocol in v3.13.  There's no forward or backwards
compatibility - it's one or the other.

This is bad: this is the kind of "flag day" change which Linus hates -
and I hate it because it means I need to update my build test system
at the same time that arm-soc merges this stuff.

This is utterly crap - it's crap not only from the point of view of the
user perspective, but also from the development methodology point of
view.
Tony Lindgren - Dec. 10, 2013, 4:01 p.m.
* Russell King - ARM Linux <linux@arm.linux.org.uk> [131210 06:37]:
> On Mon, Dec 09, 2013 at 06:42:27PM -0800, Tony Lindgren wrote:
> > We can now finally make mach-omap2 to boot with device tree only and get
> > rid of over 20k lines of platform init code that way.
> > 
> > Most basic devices already work using device tree based initialization
> > and the remaining devices can be initialized using platform data
> > with pdata-quirks.c.
> > 
> > So for most missing boards it's just a question of adding a .dts file
> > that should be fairly similar to one of the existing .dts files as
> > we've tried to cover all basic omap3 board types.
> > 
> > For people getting started updating their board files to for device
> > tree, there are some basic instructions in commit 8dc8b3ddf5d7
> > (ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2
> > DT only for booting).
> > 
> > Please also note that there are also some related fixes making their way
> > into the mainline kernel that are needed for some use cases:
> > 
> > PM off-idle for omap3 and wake-up events need the following two patches:
> 
> While this is good, what seems to be happening is a complete switch
> from one method of booting to a different method of booting with no
> compatibility inbetween.  We're going from only supporting the ATAG
> booting protocol for these platforms in v3.12 to only supporting the
> DT booting protocol in v3.13.  There's no forward or backwards
> compatibility - it's one or the other.

Hmm hey this is for v3.14, not for v3.13.

The reason why I've been sending fixes all over the place is to have them
out of the way for v3.13 so we have v3.13 work reasonably the same way
with both legacy booting and device tree based booting. Of course some
.dts files will not be there for v3.13 though.

> This is bad: this is the kind of "flag day" change which Linus hates -
> and I hate it because it means I need to update my build test system
> at the same time that arm-soc merges this stuff.

Unfortunately there's no way around that unless we carry the legacy
booting setup for longer. We can certainly postpone the flip over if
if there's a real neeed to do it.

But if the issue is just building an appended DTB image, I'd rather just
get done with it as that problem we're always going to have no matter
how much we delay the flip over.

> This is utterly crap - it's crap not only from the point of view of the
> user perspective, but also from the development methodology point of
> view.

The crappy part here is the fact that we need to build the kernel with
appended DTB. Maybe there's something more we can do to make it easier.

Regards,

Tony
Russell King - ARM Linux - Dec. 10, 2013, 4:07 p.m.
On Tue, Dec 10, 2013 at 08:01:44AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [131210 06:37]:
> > On Mon, Dec 09, 2013 at 06:42:27PM -0800, Tony Lindgren wrote:
> > > We can now finally make mach-omap2 to boot with device tree only and get
> > > rid of over 20k lines of platform init code that way.
> > > 
> > > Most basic devices already work using device tree based initialization
> > > and the remaining devices can be initialized using platform data
> > > with pdata-quirks.c.
> > > 
> > > So for most missing boards it's just a question of adding a .dts file
> > > that should be fairly similar to one of the existing .dts files as
> > > we've tried to cover all basic omap3 board types.
> > > 
> > > For people getting started updating their board files to for device
> > > tree, there are some basic instructions in commit 8dc8b3ddf5d7
> > > (ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2
> > > DT only for booting).
> > > 
> > > Please also note that there are also some related fixes making their way
> > > into the mainline kernel that are needed for some use cases:
> > > 
> > > PM off-idle for omap3 and wake-up events need the following two patches:
> > 
> > While this is good, what seems to be happening is a complete switch
> > from one method of booting to a different method of booting with no
> > compatibility inbetween.  We're going from only supporting the ATAG
> > booting protocol for these platforms in v3.12 to only supporting the
> > DT booting protocol in v3.13.  There's no forward or backwards
> > compatibility - it's one or the other.
> 
> Hmm hey this is for v3.14, not for v3.13.

Yes, I meant 3.14.

> > This is bad: this is the kind of "flag day" change which Linus hates -
> > and I hate it because it means I need to update my build test system
> > at the same time that arm-soc merges this stuff.
> 
> Unfortunately there's no way around that unless we carry the legacy
> booting setup for longer. We can certainly postpone the flip over if
> if there's a real neeed to do it.
> 
> But if the issue is just building an appended DTB image, I'd rather just
> get done with it as that problem we're always going to have no matter
> how much we delay the flip over.

Right, so I should just turn off building OMAP3 for the remainder of this
cycle.

What's the fscking point me running a build system, because if I switch
it now, OMAP3 breaks.  If I don't switch it now and your pull request is
merged, it breaks at that point.

This is utterly insane.
Tony Lindgren - Dec. 10, 2013, 4:59 p.m.
* Russell King - ARM Linux <linux@arm.linux.org.uk> [131210 08:08]:
> On Tue, Dec 10, 2013 at 08:01:44AM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [131210 06:37]:
> > > On Mon, Dec 09, 2013 at 06:42:27PM -0800, Tony Lindgren wrote:
> > > > We can now finally make mach-omap2 to boot with device tree only and get
> > > > rid of over 20k lines of platform init code that way.
> > > > 
> > > > Most basic devices already work using device tree based initialization
> > > > and the remaining devices can be initialized using platform data
> > > > with pdata-quirks.c.
> > > > 
> > > > So for most missing boards it's just a question of adding a .dts file
> > > > that should be fairly similar to one of the existing .dts files as
> > > > we've tried to cover all basic omap3 board types.
> > > > 
> > > > For people getting started updating their board files to for device
> > > > tree, there are some basic instructions in commit 8dc8b3ddf5d7
> > > > (ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2
> > > > DT only for booting).
> > > > 
> > > > Please also note that there are also some related fixes making their way
> > > > into the mainline kernel that are needed for some use cases:
> > > > 
> > > > PM off-idle for omap3 and wake-up events need the following two patches:
> > > 
> > > While this is good, what seems to be happening is a complete switch
> > > from one method of booting to a different method of booting with no
> > > compatibility inbetween.  We're going from only supporting the ATAG
> > > booting protocol for these platforms in v3.12 to only supporting the
> > > DT booting protocol in v3.13.  There's no forward or backwards
> > > compatibility - it's one or the other.
> > 
> > Hmm hey this is for v3.14, not for v3.13.
> 
> Yes, I meant 3.14.
> 
> > > This is bad: this is the kind of "flag day" change which Linus hates -
> > > and I hate it because it means I need to update my build test system
> > > at the same time that arm-soc merges this stuff.
> > 
> > Unfortunately there's no way around that unless we carry the legacy
> > booting setup for longer. We can certainly postpone the flip over if
> > if there's a real neeed to do it.
> > 
> > But if the issue is just building an appended DTB image, I'd rather just
> > get done with it as that problem we're always going to have no matter
> > how much we delay the flip over.
> 
> Right, so I should just turn off building OMAP3 for the remainder of this
> cycle.
> 
> What's the fscking point me running a build system, because if I switch
> it now, OMAP3 breaks.  If I don't switch it now and your pull request is
> merged, it breaks at that point.

Fair enough, I hear you.
 
> This is utterly insane.

Well let's do this. Let's merge the parts that add stuff now, then wait
a week (or longer as needed) so you have both ways working with linux
next for a while. Does that sounds reasonable to you?

Regards,

Tony
Arnd Bergmann - Dec. 10, 2013, 6:36 p.m.
On Tuesday 10 December 2013, Tony Lindgren wrote:
> The crappy part here is the fact that we need to build the kernel with
> appended DTB. Maybe there's something more we can do to make it easier.
> 

You are aware of the impedence matcher project [1], right?

	Arnd

[1] https://github.com/zonque/pxa-impedance-matcher
Tony Lindgren - Dec. 10, 2013, 6:43 p.m.
* Arnd Bergmann <arnd@arndb.de> [131210 10:38]:
> On Tuesday 10 December 2013, Tony Lindgren wrote:
> > The crappy part here is the fact that we need to build the kernel with
> > appended DTB. Maybe there's something more we can do to make it easier.
> > 
> 
> You are aware of the impedence matcher project [1], right?

Oh OK cool :) AFAIK the only omaps we're currently supporting in the
mainline tree where the bootloader cannot be updated easily are the
n9* that require a signed bootloader. But I think those already have
some kind of 3rd stage bootloaders available for them.

Regards,

Tony
 
> [1] https://github.com/zonque/pxa-impedance-matcher
Paul Walmsley - Dec. 10, 2013, 6:45 p.m.
On Mon, 9 Dec 2013, Tony Lindgren wrote:

> The following changes since commit f2e2c9d9b4087b74eb9e00d8dfac148354cb0b71:
> 
>   ARM: dts: Fix booting for secure omaps (2013-12-06 15:30:43 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/omap3-board-removal-signed
> 
> for you to fetch changes up to 736e812636ea72be444b85fa7e92554967459069:
> 
>   ARM: OMAP2+: Remove unused platform init code and headers (2013-12-08 14:15:46 -0800)

The description in Tony's pull request below alludes to what regressions 
will occur when this is pulled.  But just to state it in terms of what 
happened on the local testbed here when I tried it:

- CM-T3517 booting will break since there's no .dts file for it.  Are
  there other boards that will be affected here too?

- 2430SDP NFS root will hang during boot, presumably due to the lack 
  of the smc91x patch that is mentioned below

- Dynamic idle PM tests will fail, due to the lack of the first two 
  patches that Tony mentioned.  (This is also a problem now for
  37xxevm in v3.13-rc.)

- The N800 isn't booting here with a concatenated uImage+dtb - but
  maybe I'm doing something wrong with this one.

Best if the pull request were to explicitly state the known 
regressions with this series, in terms of specific boards and 
configurations.  That way, people will know what to expect.


> ----------------------------------------------------------------
> We can now finally make mach-omap2 to boot with device tree only and get
> rid of over 20k lines of platform init code that way.
> 
> Most basic devices already work using device tree based initialization
> and the remaining devices can be initialized using platform data
> with pdata-quirks.c.
> 
> So for most missing boards it's just a question of adding a .dts file
> that should be fairly similar to one of the existing .dts files as
> we've tried to cover all basic omap3 board types.
> 
> For people getting started updating their board files to for device
> tree, there are some basic instructions in commit 8dc8b3ddf5d7
> (ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2
> DT only for booting).
> 
> Please also note that there are also some related fixes making their way
> into the mainline kernel that are needed for some use cases:
> 
> PM off-idle for omap3 and wake-up events need the following two patches:
> 
> [PATCH] of/platform: Fix no irq domain found errors when populating interrupts
> http://lkml.org/lkml/2013/11/22/520
> 
> [PATCH] ARM: dts: Fix omap serial wake-up when booted with device tree
> http://www.spinics.net/lists/devicetree/msg13374.html
> 
> EMAC Ethernet on am3517 boards needs:
> 
> [PATCH] net: davinci_emac: Fix platform data handling and make usable for am3517
> http://patchwork.ozlabs.org/patch/296351/
> 
> Ethernet for boards using smc91x needs:
> 
> [PATCH v2] net: smc91x: Fix device tree based configuration so it's usable
> http://www.spinics.net/lists/netdev/msg258913.html
> 

(snip)

- Paul
Tony Lindgren - Dec. 10, 2013, 6:59 p.m.
* Paul Walmsley <paul@pwsan.com> [131210 10:47]:
> On Mon, 9 Dec 2013, Tony Lindgren wrote:
> 
> > The following changes since commit f2e2c9d9b4087b74eb9e00d8dfac148354cb0b71:
> > 
> >   ARM: dts: Fix booting for secure omaps (2013-12-06 15:30:43 -0800)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/omap3-board-removal-signed
> > 
> > for you to fetch changes up to 736e812636ea72be444b85fa7e92554967459069:
> > 
> >   ARM: OMAP2+: Remove unused platform init code and headers (2013-12-08 14:15:46 -0800)
> 
> The description in Tony's pull request below alludes to what regressions 
> will occur when this is pulled.  But just to state it in terms of what 
> happened on the local testbed here when I tried it:
> 
> - CM-T3517 booting will break since there's no .dts file for it.  Are
>   there other boards that will be affected here too?

Yeah the cm-t3770 is on my todo list, but I've left it last as it's my
home router and has been behaving quite nicely.

That should then cover:

SBC-T3530
http://compulab.co.il/products/sbcs/sbc-t3530/

SBC-T3517
http://compulab.co.il/products/sbcs/sbc-t3517/

SBC-T3730
http://compulab.co.il/products/sbcs/sbc-t3730/

They all seem to have the same baseboard, and the CPU module is
different. So getting the 3530 and 3517 variants working should
be trivial. I don't have 3530 or 3517 variants, so somebody else
will need to do those two.

And Nishant just posted a .dts file for the 3517 craneboard.
  
> - 2430SDP NFS root will hang during boot, presumably due to the lack 
>   of the smc91x patch that is mentioned below

Yes that's correct, hopefully we'll have that in v3.13.
 
> - Dynamic idle PM tests will fail, due to the lack of the first two 
>   patches that Tony mentioned.  (This is also a problem now for
>   37xxevm in v3.13-rc.)

Yes that's something that should be fixes for v3.13 as well.
 
> - The N800 isn't booting here with a concatenated uImage+dtb - but
>   maybe I'm doing something wrong with this one.

Hmm n800 works for me here for sure, I can n-uple check today.
 
> Best if the pull request were to explicitly state the known 
> regressions with this series, in terms of specific boards and 
> configurations.  That way, people will know what to expect.

Well ideally we would have no regressions when doing this, but I've
been chasing people and bugs for few years now on this DT conversion
and we still always find something. In most cases it should be just
a question of configuring a board specific .dts file. I don't have
all the boards though, so I've only done the ones I have naturally.

Regards,

Tony
Tony Lindgren - Dec. 10, 2013, 7:08 p.m.
* Tony Lindgren <tony@atomide.com> [131210 11:00]:
> * Paul Walmsley <paul@pwsan.com> [131210 10:47]:
>  
> > - The N800 isn't booting here with a concatenated uImage+dtb - but
> >   maybe I'm doing something wrong with this one.
> 
> Hmm n800 works for me here for sure, I can n-uple check today.

Yeah n800 boots just fine here. Will email you the dmesg.

Tony
Tony Lindgren - Dec. 10, 2013, 7:27 p.m.
* Tony Lindgren <tony@atomide.com> [131210 11:00]:
> * Paul Walmsley <paul@pwsan.com> [131210 10:47]:
> > On Mon, 9 Dec 2013, Tony Lindgren wrote:
> > 
> > > The following changes since commit f2e2c9d9b4087b74eb9e00d8dfac148354cb0b71:
> > > 
> > >   ARM: dts: Fix booting for secure omaps (2013-12-06 15:30:43 -0800)
> > > 
> > > are available in the git repository at:
> > > 
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/omap3-board-removal-signed
> > > 
> > > for you to fetch changes up to 736e812636ea72be444b85fa7e92554967459069:
> > > 
> > >   ARM: OMAP2+: Remove unused platform init code and headers (2013-12-08 14:15:46 -0800)
> > 
> > The description in Tony's pull request below alludes to what regressions 
> > will occur when this is pulled.  But just to state it in terms of what 
> > happened on the local testbed here when I tried it:
> > 
> > - CM-T3517 booting will break since there's no .dts file for it.  Are
> >   there other boards that will be affected here too?
> 
> Yeah the cm-t3770 is on my todo list, but I've left it last as it's my
> home router and has been behaving quite nicely.
> 
> That should then cover:
> 
> SBC-T3530
> http://compulab.co.il/products/sbcs/sbc-t3530/
> 
> SBC-T3517
> http://compulab.co.il/products/sbcs/sbc-t3517/
> 
> SBC-T3730
> http://compulab.co.il/products/sbcs/sbc-t3730/
> 
> They all seem to have the same baseboard, and the CPU module is
> different. So getting the 3530 and 3517 variants working should
> be trivial. I don't have 3530 or 3517 variants, so somebody else
> will need to do those two.
> 
> And Nishant just posted a .dts file for the 3517 craneboard.

And here's a list of other boards we don't have .dts file for if
people have these:

board-devkit8000.c		omap3-ldp.dts or omap3-beagle.dts is a good starting point
board-omap3logic.c		omap3-ldp.dts or omap3-beagle.dts is a good starting point
board-omap3pandora.c		omap3-ldp.dts or omap3-beagle.dts is a good starting point
board-omap3stalker.c
board-omap3touchbook.c

For the ones above, omap3-ldp.dts or omap3-beagle.dts are good starting
points. There's the DPI display pdata patch too, but it seems we want to
wait to see if Tomi gets his display changes done before applying that.

I don't have any of the ones above, so people using those please
do the .dts files ASAP.

Or send me those boards with working boot loaders and I'll do them at
a rate of one board per day or so.. And then you're stuck with my
criteria of "usable" which is usually serial port and NFS root unless
I really like the board, mhuwahuaaaahh!

board-ti8168evm.c

I doubt ti8168evm has even worked for a long time.. It's in pretty
sorry state unfortunately with missing clock support and missing
handle_irq entry in the board-ti8168evm.c.

Regards,

Tony
Arnd Bergmann - Dec. 10, 2013, 7:39 p.m.
On Tuesday 10 December 2013, Tony Lindgren wrote:
> board-ti8168evm.c
> 
> I doubt ti8168evm has even worked for a long time.. It's in pretty
> sorry state unfortunately with missing clock support and missing
> handle_irq entry in the board-ti8168evm.c.

Does that imply the entire ti81xx soc support is lacking, or just
that board specifically? It seems to be the only board file that
ever got merged.

	Arnd
Paul Walmsley - Dec. 10, 2013, 7:44 p.m.
On Tue, 10 Dec 2013, Arnd Bergmann wrote:

> On Tuesday 10 December 2013, Tony Lindgren wrote:
> > board-ti8168evm.c
> > 
> > I doubt ti8168evm has even worked for a long time.. It's in pretty
> > sorry state unfortunately with missing clock support and missing
> > handle_irq entry in the board-ti8168evm.c.
> 
> Does that imply the entire ti81xx soc support is lacking, or just
> that board specifically? It seems to be the only board file that
> ever got merged.

We don't really support in mainline for 8148/8168 chips, so this is not 
much of a regression.  TI gave up trying to upstream it several years ago.

Aida Mynzhasova <aida.mynzhasova@skitlab.ru> has done some work on this 
recently, but I don't know what the current status is.  Maybe she can 
comment.


- Paul
Tony Lindgren - Dec. 10, 2013, 7:50 p.m.
* Arnd Bergmann <arnd@arndb.de> [131210 11:41]:
> On Tuesday 10 December 2013, Tony Lindgren wrote:
> > board-ti8168evm.c
> > 
> > I doubt ti8168evm has even worked for a long time.. It's in pretty
> > sorry state unfortunately with missing clock support and missing
> > handle_irq entry in the board-ti8168evm.c.
> 
> Does that imply the entire ti81xx soc support is lacking, or just
> that board specifically? It seems to be the only board file that
> ever got merged.

It's an omap3 variant and it's still waiting for the clock patches 
that now unfortunately have a dependency to the the omap clock
move to drivers/clk. Aida Mynzhasova posted some patches few months
ago here:

http://www.spinics.net/lists/linux-omap/msg96341.html

Since it's an omap3 variant, we should be able to make it usable
quite easily, so no need to remove the whole support at least
yet. Plus it seems to be an active TI part, so people are still it.

But it's definitely not a show stopper for making omap3 to boot in
device tree only mode.

Regards,

Tony
Tony Lindgren - Dec. 10, 2013, 8:36 p.m.
* Tony Lindgren <tony@atomide.com> [131210 09:01]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [131210 08:08]:
> > 
> > Right, so I should just turn off building OMAP3 for the remainder of this
> > cycle.
> > 
> > What's the fscking point me running a build system, because if I switch
> > it now, OMAP3 breaks.  If I don't switch it now and your pull request is
> > merged, it breaks at that point.
> 
> Fair enough, I hear you.
>  
> > This is utterly insane.
> 
> Well let's do this. Let's merge the parts that add stuff now, then wait
> a week (or longer as needed) so you have both ways working with linux
> next for a while. Does that sounds reasonable to you?

OK I've added a tag to the same branch earlier before we remove any of
the legacy omap3 support and sent a new pull request.

Regards,

Tony
Tony Lindgren - Dec. 10, 2013, 11:07 p.m.
* Tony Lindgren <tony@atomide.com> [131210 11:28]:
> * Tony Lindgren <tony@atomide.com> [131210 11:00]:
> > * Paul Walmsley <paul@pwsan.com> [131210 10:47]:
> > > On Mon, 9 Dec 2013, Tony Lindgren wrote:
> > > 
> > > > The following changes since commit f2e2c9d9b4087b74eb9e00d8dfac148354cb0b71:
> > > > 
> > > >   ARM: dts: Fix booting for secure omaps (2013-12-06 15:30:43 -0800)
> > > > 
> > > > are available in the git repository at:
> > > > 
> > > >   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/omap3-board-removal-signed
> > > > 
> > > > for you to fetch changes up to 736e812636ea72be444b85fa7e92554967459069:
> > > > 
> > > >   ARM: OMAP2+: Remove unused platform init code and headers (2013-12-08 14:15:46 -0800)
> > > 
> > > The description in Tony's pull request below alludes to what regressions 
> > > will occur when this is pulled.  But just to state it in terms of what 
> > > happened on the local testbed here when I tried it:
> > > 
> > > - CM-T3517 booting will break since there's no .dts file for it.  Are
> > >   there other boards that will be affected here too?
> > 
> > Yeah the cm-t3770 is on my todo list, but I've left it last as it's my
> > home router and has been behaving quite nicely.
> > 
> > That should then cover:
> > 
> > SBC-T3530
> > http://compulab.co.il/products/sbcs/sbc-t3530/
> > 
> > SBC-T3517
> > http://compulab.co.il/products/sbcs/sbc-t3517/
> > 
> > SBC-T3730
> > http://compulab.co.il/products/sbcs/sbc-t3730/
> > 
> > They all seem to have the same baseboard, and the CPU module is
> > different. So getting the 3530 and 3517 variants working should
> > be trivial. I don't have 3530 or 3517 variants, so somebody else
> > will need to do those two.
> > 
> > And Nishant just posted a .dts file for the 3517 craneboard.
> 
> And here's a list of other boards we don't have .dts file for if
> people have these:
> 
> board-devkit8000.c		omap3-ldp.dts or omap3-beagle.dts is a good starting point

Oops, sorry this one we already have covered with omap3-devkit8000.dts.
And please ignore the multiple comments, they all are pretty close to
omap3-ldp and omap3-beagle.

> board-omap3logic.c		omap3-ldp.dts or omap3-beagle.dts is a good starting point
> board-omap3pandora.c		omap3-ldp.dts or omap3-beagle.dts is a good starting point
> board-omap3stalker.c
> board-omap3touchbook.c
> 
> For the ones above, omap3-ldp.dts or omap3-beagle.dts are good starting
> points. There's the DPI display pdata patch too, but it seems we want to
> wait to see if Tomi gets his display changes done before applying that.
> 
> I don't have any of the ones above, so people using those please
> do the .dts files ASAP.
> 
> Or send me those boards with working boot loaders and I'll do them at
> a rate of one board per day or so.. And then you're stuck with my
> criteria of "usable" which is usually serial port and NFS root unless
> I really like the board, mhuwahuaaaahh!
> 
> board-ti8168evm.c
> 
> I doubt ti8168evm has even worked for a long time.. It's in pretty
> sorry state unfortunately with missing clock support and missing
> handle_irq entry in the board-ti8168evm.c.
> 
> Regards,
> 
> Tony
Paul Walmsley - Dec. 10, 2013, 11:56 p.m.
On Tue, 10 Dec 2013, Tony Lindgren wrote:

> * Paul Walmsley <paul@pwsan.com> [131210 10:47]:
>
> > - The N800 isn't booting here with a concatenated uImage+dtb - but
> >   maybe I'm doing something wrong with this one.
> 
> Hmm n800 works for me here for sure, I can n-uple check today.

The N800 here is booting now with this series.  My mistake, as 
suspected...

> > Best if the pull request were to explicitly state the known 
> > regressions with this series, in terms of specific boards and 
> > configurations.  That way, people will know what to expect.
> 
> Well ideally we would have no regressions when doing this, but I've
> been chasing people and bugs for few years now on this DT conversion
> and we still always find something. In most cases it should be just
> a question of configuring a board specific .dts file. I don't have
> all the boards though, so I've only done the ones I have naturally.

Yeah some level of regression is expected with this, for sure.  It's just 
good to have it documented if it's known.


- Paul
Tony Lindgren - Dec. 13, 2013, 7:26 p.m.
* Tony Lindgren <tony@atomide.com> [131210 15:08]:
> * Tony Lindgren <tony@atomide.com> [131210 11:28]:
> > * Tony Lindgren <tony@atomide.com> [131210 11:00]:
> > > * Paul Walmsley <paul@pwsan.com> [131210 10:47]:
> > > > On Mon, 9 Dec 2013, Tony Lindgren wrote:
> > > > 
> > > > > The following changes since commit f2e2c9d9b4087b74eb9e00d8dfac148354cb0b71:
> > > > > 
> > > > >   ARM: dts: Fix booting for secure omaps (2013-12-06 15:30:43 -0800)
> > > > > 
> > > > > are available in the git repository at:
> > > > > 
> > > > >   git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.14/omap3-board-removal-signed
> > > > > 
> > > > > for you to fetch changes up to 736e812636ea72be444b85fa7e92554967459069:
> > > > > 
> > > > >   ARM: OMAP2+: Remove unused platform init code and headers (2013-12-08 14:15:46 -0800)
> > > > 
> > > > The description in Tony's pull request below alludes to what regressions 
> > > > will occur when this is pulled.  But just to state it in terms of what 
> > > > happened on the local testbed here when I tried it:
> > > > 
> > > > - CM-T3517 booting will break since there's no .dts file for it.  Are
> > > >   there other boards that will be affected here too?
> > > 
> > > Yeah the cm-t3770 is on my todo list, but I've left it last as it's my
> > > home router and has been behaving quite nicely.
> > > 
> > > That should then cover:
> > > 
> > > SBC-T3530
> > > http://compulab.co.il/products/sbcs/sbc-t3530/
> > > 
> > > SBC-T3517
> > > http://compulab.co.il/products/sbcs/sbc-t3517/
> > > 
> > > SBC-T3730
> > > http://compulab.co.il/products/sbcs/sbc-t3730/
> > > 
> > > They all seem to have the same baseboard, and the CPU module is
> > > different. So getting the 3530 and 3517 variants working should
> > > be trivial. I don't have 3530 or 3517 variants, so somebody else
> > > will need to do those two.

OK posted a patch for the SBC-T3730 with minimal support also for
SBC-3530 and SBC-3517 that should boot far enough to start adding
more devices. Paul, care to try it on the CM-T3517, the patch is:

[PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730

Let's hope there's two smsc911x devices also on the 3517 based board,
otherwise it should have a completely separate .dts file.

> > > And Nishant just posted a .dts file for the 3517 craneboard.
> > 
> > And here's a list of other boards we don't have .dts file for if
> > people have these:
> > 
> > board-devkit8000.c		omap3-ldp.dts or omap3-beagle.dts is a good starting point
> 
> Oops, sorry this one we already have covered with omap3-devkit8000.dts.
> And please ignore the multiple comments, they all are pretty close to
> omap3-ldp and omap3-beagle.
> 
> > board-omap3logic.c		omap3-ldp.dts or omap3-beagle.dts is a good starting point
> > board-omap3pandora.c		omap3-ldp.dts or omap3-beagle.dts is a good starting point
> > board-omap3stalker.c
> > board-omap3touchbook.c
> > 
> > For the ones above, omap3-ldp.dts or omap3-beagle.dts are good starting
> > points. There's the DPI display pdata patch too, but it seems we want to
> > wait to see if Tomi gets his display changes done before applying that.
> > 
> > I don't have any of the ones above, so people using those please
> > do the .dts files ASAP.
> > 
> > Or send me those boards with working boot loaders and I'll do them at
> > a rate of one board per day or so.. And then you're stuck with my
> > criteria of "usable" which is usually serial port and NFS root unless
> > I really like the board, mhuwahuaaaahh!
> > 
> > board-ti8168evm.c
> > 
> > I doubt ti8168evm has even worked for a long time.. It's in pretty
> > sorry state unfortunately with missing clock support and missing
> > handle_irq entry in the board-ti8168evm.c.
> > 
> > Regards,
> > 
> > Tony
Paul Walmsley - Dec. 17, 2013, 7:14 a.m.
On Fri, 13 Dec 2013, Tony Lindgren wrote:

> OK posted a patch for the SBC-T3730 with minimal support also for
> SBC-3530 and SBC-3517 that should boot far enough to start adding
> more devices. Paul, care to try it on the CM-T3517, the patch is:
> 
> [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730

Didn't get anything out of the serial port:

http://www.pwsan.com/omap/testlogs/test_tonys_conversion_v3.14/20131215235827/boot/cmt3517/cmt3517_log.txt

As a partial sanity check, AM3517 EVM was included as part of the run 
(with a separate uImage+dtb of course) and that seems to boot OK:

http://www.pwsan.com/omap/testlogs/test_tonys_conversion_v3.14/20131215235827/boot/3517evm/3517evm_log.txt

In case it's useful, here's a CM-T3517 boot log from v3.13-rc4:

http://www.pwsan.com/omap/testlogs/test_v3.13-rc4/20131215195251/boot/cmt3517/cmt3517_log.txt


- Paul
Tony Lindgren - Dec. 17, 2013, 3:26 p.m.
* Paul Walmsley <paul@pwsan.com> [131216 23:16]:
> On Fri, 13 Dec 2013, Tony Lindgren wrote:
> 
> > OK posted a patch for the SBC-T3730 with minimal support also for
> > SBC-3530 and SBC-3517 that should boot far enough to start adding
> > more devices. Paul, care to try it on the CM-T3517, the patch is:
> > 
> > [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730
> 
> Didn't get anything out of the serial port:
> 
> http://www.pwsan.com/omap/testlogs/test_tonys_conversion_v3.14/20131215235827/boot/cmt3517/cmt3517_log.txt

OK thanks for testing. Looks like the CompuLab guys will need to
take a look at it. I'll update my patch for SBC-T3730 only with the
comments from Igor.
 
> As a partial sanity check, AM3517 EVM was included as part of the run 
> (with a separate uImage+dtb of course) and that seems to boot OK:
> 
> http://www.pwsan.com/omap/testlogs/test_tonys_conversion_v3.14/20131215235827/boot/3517evm/3517evm_log.txt

Hmm OK, weird that the 3517 EVM boots but not the CM-T3517.
 
> In case it's useful, here's a CM-T3517 boot log from v3.13-rc4:
> 
> http://www.pwsan.com/omap/testlogs/test_v3.13-rc4/20131215195251/boot/cmt3517/cmt3517_log.txt

OK thanks.

Tony