diff mbox

[0/4] Drop legacy support for omap3517

Message ID 201501241300.00723@pali (mailing list archive)
State New, archived
Headers show

Commit Message

Pali Rohár Jan. 24, 2015, noon UTC
On Thursday 15 January 2015 15:25:36 Sebastian Reichel wrote:
> On Tue, Jan 13, 2015 at 12:42:20PM -0800, Tony Lindgren wrote:
> > * Arnd Bergmann <arnd@arndb.de> [150113 12:27]:
> > > 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?
> > 
> > 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.
> 
> 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:



With this patch identification works fine:

/ # cat /sys/block/mmcblk0/device/../slot_name 
external
/ # cat /sys/block/mmcblk1/device/../slot_name 
internal

Without patch omap_hsmmc driver does not create slot_name.

Comments

Arnd Bergmann Jan. 24, 2015, 10:08 p.m. UTC | #1
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Pali Rohár Jan. 24, 2015, 10:14 p.m. UTC | #2
On Saturday 24 January 2015 23:08:00 Arnd Bergmann wrote:
> 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

Why? omap_hsmmc.c has already support for slot_name sysfs entry, 
just it is not filled from DT data (only from platform_data)...
Sebastian Reichel Jan. 25, 2015, 3:18 p.m. UTC | #3
On Sat, Jan 24, 2015 at 01:00:00PM +0100, 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:
> 
> diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
> index 8571027..31ca609 100644
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -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>;
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 7c71dcd..cd189eb 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -2021,6 +2021,8 @@ static struct omap_hsmmc_platform_data *of_get_hsmmc_pdata(struct device *dev)
>  	if (of_find_property(np, "enable-sdio-wakeup", NULL))
>  		pdata->pm_caps |= MMC_PM_WAKE_SDIO_IRQ;
>  
> +	of_property_read_string(np, "slot-name", &pdata->name);
> +
>  	return pdata;
>  }
>  #else

I suggest to use "label" as DT property name, which is also used for
labeling GPIOs, LEDs, partitions, ... in DT.

-- Sebastian
Pavel Machek Jan. 25, 2015, 9:22 p.m. UTC | #4
On Sat 2015-01-24 13:00:00, Pali Rohár wrote:
> On Thursday 15 January 2015 15:25:36 Sebastian Reichel wrote:
> > On Tue, Jan 13, 2015 at 12:42:20PM -0800, Tony Lindgren wrote:
> > > * Arnd Bergmann <arnd@arndb.de> [150113 12:27]:
> > > > 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?
> > > 
> > > 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.
> > 
> > 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:

Thanks!

Does it need line into Documentation/devicetree/ somewhere?

With that,
Acked-by: Pavel Machek <pavel@ucw.cz>

									Pavel
Pavel Machek Jan. 25, 2015, 9:23 p.m. UTC | #5
On Sat 2015-01-24 23:08:00, Arnd Bergmann wrote:
> 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.

I'd guess this is going to be useful on more than just n900, and thus
is worth supporting generically...

									Pavel
Sebastian Reichel Jan. 25, 2015, 9:49 p.m. UTC | #6
On Sun, Jan 25, 2015 at 10:22:58PM +0100, Pavel Machek 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:
> 
> Thanks!
> 
> Does it need line into Documentation/devicetree/ somewhere?

Documentation/devicetree/bindings/mmc/mmc.txt (generic)
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt (omap specific)

-- Sebastian
Arnd Bergmann Jan. 26, 2015, 10:16 a.m. UTC | #7
On Saturday 24 January 2015 23:14:58 Pali Rohár wrote:
> On Saturday 24 January 2015 23:08:00 Arnd Bergmann wrote:
> > 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.
> 
> Why? omap_hsmmc.c has already support for slot_name sysfs entry, 
> just it is not filled from DT data (only from platform_data)...

It's a highly nonstandard interface, none of the other controllers
support it, and even changing the the other omap machines to use
the same strings might break existing user space that might rely
on whatever gets printed in those properties today.

We should limit the use of those strings to the boards that
are known to run software that requires them to avoid regressions.
We could also define a standard way of finding out whether an
mmc device is removable. We already have the MMC_CAP_NONREMOVABLE
flag in the kernel and could have a read-only boolean attribute
in sysfs for it.

Putting a "name" property into DT because some random user space
requires a particular name to show up in sysfs however does not
seem a legitimate hardware description.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 8571027..31ca609 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -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>;
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 7c71dcd..cd189eb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2021,6 +2021,8 @@  static struct omap_hsmmc_platform_data *of_get_hsmmc_pdata(struct device *dev)
 	if (of_find_property(np, "enable-sdio-wakeup", NULL))
 		pdata->pm_caps |= MMC_PM_WAKE_SDIO_IRQ;
 
+	of_property_read_string(np, "slot-name", &pdata->name);
+
 	return pdata;
 }
 #else