Drop legacy support for omap3517

It seems we can now drop omap3517 legacy booting support to get a bit closer to making all of omap3 boot in device tree only mode.

All these boards have at least minimal support for booting with device tree, and pretty much anything supported with the legacy board files can be configured also for device tree based booting if not done already.

Quoted 8 lines · On Tuesday 13 January 2015 09:57:41 Tony Lindgren wrote:

It seems we can now drop omap3517 legacy booting support to get a bit closer to making all of omap3 boot in device tree only mode.

All these boards have at least minimal support for booting with device tree, and pretty much anything supported with the legacy board files can be configured also for device tree based booting if not done already.

Ah, very nice.

Just out of curiosity, what are the remaining showstoppers for the 3430 and 3530 based boards?

Quoted 10 lines · Arnd Bergmann

Quoted 8 lines · On Tuesday 13 January 2015 09:57:41 Tony Lindgren wrote:

It seems we can now drop omap3517 legacy booting support to get a bit closer to making all of omap3 boot in device tree only mode.

All these boards have at least minimal support for booting with device tree, and pretty much anything supported with the legacy board files can be configured also for device tree based booting if not done already.

Quoted 4 lines

Ah, very nice.

Just out of curiosity, what are the remaining showstoppers for the 3430 and 3530 based boards?

Not much really. We're now printing a warning to get a people to upgrade their systems. So with some boards we need to wait a while.

Then here are the remaining items that I'm aware of:

- A regression at least on some n900 with appended DTB not booting properly any longer reported by Pali

- A regression where the legacy ATAGs don't seem to get properly translated by the uncompress code for atag_rev at least reported by Pali

- A few missing .dts files for devkit8000, omap3logic, omap3stalker, omap3pandora and omap3touchbook

Pali and Sebastian probably know best of any other remaining issues to drop n900 legacy booting.

If people have the boards listed above, please pitch in to do the .dts files or send the boards to me and I can do minimal .dts files for them.

Regards,

Tony

CCing Pavel Machek

He reported also some (still not fixed) regressions on n900.

Quoted 1 line

He reported also some (still not fixed) regressions on n900.

adp1653 flash driver does not have device tree bindings, yet. Patches were submitted, but I guess I'll need to push them some more.

Quoted 10 lines · Arnd Bergmann

Quoted 8 lines · On Tuesday 13 January 2015 09:57:41 Tony Lindgren wrote:

It seems we can now drop omap3517 legacy booting support to get a bit closer to making all of omap3 boot in device tree only mode.

All these boards have at least minimal support for booting with device tree, and pretty much anything supported with the legacy board files can be configured also for device tree based booting if not done already.

Quoted 4 lines

Ah, very nice.

Just out of curiosity, what are the remaining showstoppers for the 3430 and 3530 based boards?

Not much really. We're now printing a warning to get a people to upgrade their systems. So with some boards we need to wait a while.

Then here are the remaining items that I'm aware of:

- A regression at least on some n900 with appended DTB not booting properly any longer reported by Pali

- A regression where the legacy ATAGs don't seem to get properly translated by the uncompress code for atag_rev at least reported by Pali

- A few missing .dts files for devkit8000, omap3logic, omap3stalker, omap3pandora and omap3touchbook

Pali and Sebastian probably know best of any other remaining issues to drop n900 legacy booting.

Quoted 38 lines · Tony Lindgren

Quoted 10 lines · Arnd Bergmann

Quoted 8 lines · On Tuesday 13 January 2015 09:57:41 Tony Lindgren wrote:

It seems we can now drop omap3517 legacy booting support to get a bit closer to making all of omap3 boot in device tree only mode.

All these boards have at least minimal support for booting with device tree, and pretty much anything supported with the legacy board files can be configured also for device tree based booting if not done already.

Quoted 4 lines

Ah, very nice.

Just out of curiosity, what are the remaining showstoppers for the 3430 and 3530 based boards?

Not much really. We're now printing a warning to get a people to upgrade their systems. So with some boards we need to wait a while.

Then here are the remaining items that I'm aware of:

- A regression at least on some n900 with appended DTB not booting

properly any longer reported by Pali

- A regression where the legacy ATAGs don't seem to get properly

translated by the uncompress code for atag_rev at least reported by Pali

- A few missing .dts files for devkit8000, omap3logic, omap3stalker,

omap3pandora and omap3touchbook

Quoted 2 lines

Pali and Sebastian probably know best of any other remaining issues to drop n900 legacy booting.

Apart from the bugs there is only one feature-wise regression when the system is booted via DT, which is the accelerometer. I will (re)send patches for that in the next days.

-- Sebastian

Another regression for DT setup (which does not occur for board code):

omap_hsmmc driver does not export slot_name sysfs entry because it not supported by DT yet. Entry slot_name is used by userspace application to determinate if mmc block device is internal eMMC memory or external uSD card. So support for this property also in DT is needed.

Here is simple patch which fix this problem:

Quoted 10 lines · On Saturday 24 January 2015 13:00:00 Pali Roh?r wrote:

Another regression for DT setup (which does not occur for board code):

omap_hsmmc driver does not export slot_name sysfs entry because it not supported by DT yet. Entry slot_name is used by userspace application to determinate if mmc block device is internal eMMC memory or external uSD card. So support for this property also in DT is needed.

Here is simple patch which fix this problem:

The sysfs file only exists for the two OMAP drivers, and the naming is used only by board-n8x0, board-rx51 and board-omap3logic.

It may be better to add a board-specific hack for these to keep the existing user space working but not spread the use of this file anywhere else.

Arnd

Quoted 15 lines · On Saturday 24 January 2015 23:08:00 Arnd Bergmann wrote:

Quoted 10 lines · On Saturday 24 January 2015 13:00:00 Pali Roh?r wrote:

Another regression for DT setup (which does not occur for board code):

omap_hsmmc driver does not export slot_name sysfs entry because it not supported by DT yet. Entry slot_name is used by userspace application to determinate if mmc block device is internal eMMC memory or external uSD card. So support for this property also in DT is needed.

Here is simple patch which fix this problem:

The sysfs file only exists for the two OMAP drivers, and the naming is used only by board-n8x0, board-rx51 and board-omap3logic.

Quoted 3 lines

It may be better to add a board-specific hack for these to keep the existing user space working but not spread the use of this file anywhere else.

Why? omap_hsmmc.c has already support for slot_name sysfs entry, just it is not filled from DT data (only from platform_data)...

Quoted 11 lines · On Saturday 24 January 2015 13:00:00 Pali Roh?r wrote:

Another regression for DT setup (which does not occur for board code):

omap_hsmmc driver does not export slot_name sysfs entry because it not supported by DT yet. Entry slot_name is used by userspace application to determinate if mmc block device is internal eMMC memory or external uSD card. So support for this property also in DT is needed.

Here is simple patch which fix this problem:

The sysfs file only exists for the two OMAP drivers, and the naming is used only by board-n8x0, board-rx51 and board-omap3logic.

It may be better to add a board-specific hack for these to keep the existing user space working but not spread the use of this file anywhere else.

Another regression for DT setup (which does not occur for board code):

omap_hsmmc driver does not export slot_name sysfs entry because it not supported by DT yet. Entry slot_name is used by userspace application to determinate if mmc block device is internal eMMC memory or external uSD card. So support for this property also in DT is needed.

Here is simple patch which fix this problem:

arch/arm/boot/dts/omap3-n900.dts +2 -0

index 8571027..31ca609 100644
@@ -665,6 +665,7 @@
 };
 
 &mmc1 {
+	slot-name = "external";
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc1_pins>;
 	vmmc-supply = <&vmmc1>;

@@ -674,6 +675,7 @@
 
 /* most boards use vaux3, only some old versions use vmmc2 instead */
 &mmc2 {
+	slot-name = "internal";
 	pinctrl-names = "default";
 	pinctrl-0 = <&mmc2_pins>;
 	vmmc-supply = <&vaux3>;

drivers/mmc/host/omap_hsmmc.c +0 -0

index 7c71dcd..cd189eb 100644

Quoted 39 lines · On Thursday 15 January 2015 15:25:36 Sebastian Reichel wrote:

Quoted 38 lines · Tony Lindgren

Quoted 10 lines · Arnd Bergmann

Quoted 8 lines · On Tuesday 13 January 2015 09:57:41 Tony Lindgren wrote:

It seems we can now drop omap3517 legacy booting support to get a bit closer to making all of omap3 boot in device tree only mode.

All these boards have at least minimal support for booting with device tree, and pretty much anything supported with the legacy board files can be configured also for device tree based booting if not done already.

Quoted 4 lines

Ah, very nice.

Just out of curiosity, what are the remaining showstoppers for the 3430 and 3530 based boards?

Not much really. We're now printing a warning to get a people to upgrade their systems. So with some boards we need to wait a while.

Then here are the remaining items that I'm aware of:

- A regression at least on some n900 with appended DTB not booting

properly any longer reported by Pali

- A regression where the legacy ATAGs don't seem to get properly

translated by the uncompress code for atag_rev at least reported by Pali

- A few missing .dts files for devkit8000, omap3logic, omap3stalker,

omap3pandora and omap3touchbook

Quoted 8 lines

Quoted 2 lines

Pali and Sebastian probably know best of any other remaining issues to drop n900 legacy booting.

Apart from the bugs there is only one feature-wise regression when the system is booted via DT, which is the accelerometer. I will (re)send patches for that in the next days.

-- Sebastian

Another regression for DT setup (which does not occur for board code):

omap_hsmmc driver does not export slot_name sysfs entry because it not supported by DT yet. Entry slot_name is used by userspace application to determinate if mmc block device is internal eMMC memory or external uSD card. So support for this property also in DT is needed.

Here is simple patch which fix this problem:

Quoted 8 lines

Another regression for DT setup (which does not occur for board code):

omap_hsmmc driver does not export slot_name sysfs entry because it not supported by DT yet. Entry slot_name is used by userspace application to determinate if mmc block device is internal eMMC memory or external uSD card. So support for this property also in DT is needed.

Quoted 1 line

Here is simple patch which fix this problem:

Thanks!

Does it need line into Documentation/devicetree/ somewhere?