mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot

When device is booted using devicetree, platforms impacted by Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum indicates that the module cannot do multi-block transfers.

Handle this by providing a boolean flag to indicate to driver that it is working on a hardware with mentioned limitation.

Quoted 6 lines · Nishanth Menon

When device is booted using devicetree, platforms impacted by Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum indicates that the module cannot do multi-block transfers.

Handle this by providing a boolean flag to indicate to driver that it is working on a hardware with mentioned limitation.

sure there's no way of reading the revision register to figure this one out without having to add a new DT attribute ?

Quoted 11 lines · Felipe Balbi

Quoted 6 lines · Nishanth Menon

When device is booted using devicetree, platforms impacted by Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum indicates that the module cannot do multi-block transfers.

Handle this by providing a boolean flag to indicate to driver that it is working on a hardware with mentioned limitation.

sure there's no way of reading the revision register to figure this one out without having to add a new DT attribute ?

I did a quick patch to read the Module revision register:
http://slexy.org/view/s21TKvlWlR

sdp2430: Revision: 1.2, Spec: 0.0, normal interrupt

OMAP3430-ldp: (ES2.1): Revision: 2.6, Spec: 0.0, normal interrupt SDP3430:(ES3.0) Revision: 2.6, Spec: 0.0, normal interrupt
AM3517-evm: (ES1.1): Revision: 2.6, Spec: 0.0, normal interrupt AM3517-crane:(ES1.1): Revision: 2.6, Spec: 0.0, normal interrupt

AM37x-evm: (ES1.2) Revision: 2.6, Spec: 0.0, normal interrupt OMAP3630-beag-xm (ES1.2): Revision: 2.6, Spec: 0.0, normal interrupt

am335x-evm:(ES1.0): Revision: 3.1, Spec: 0.1, normal interrupt
am335x-sk: (ES2.1): Revision: 3.1, Spec: 0.1, normal interrupt am335x-beaglebone-black:(ES2.0): Revision: 3.1, Spec: 0.1, normal interrupt

sdp4430.txt: (ES2.2): Revision: 3.1, Spec: 0.1, normal interrupt

OMAP4460-panda-es (ES1.1): Revision: 3.1, Spec: 0.1, normal interrupt

OMAP5uevm:(ES2.0): Revision: 3.3, Spec: 0.2, normal interrupt dra7-evm (es1.1): Revision: 3.3, Spec: 0.2, normal interrupt

OMAP3430-ldp seems to be the only one impacted with module revision 2.6 -> so using revision information is not really helpful here. Hence the usage of a flag in dt attribute to indicate hardware impacted by erratum.

Hi,

Quoted 38 lines · Nishanth Menon

Quoted 11 lines · Felipe Balbi

Quoted 6 lines · Nishanth Menon

When device is booted using devicetree, platforms impacted by Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum indicates that the module cannot do multi-block transfers.

Handle this by providing a boolean flag to indicate to driver that it is working on a hardware with mentioned limitation.

sure there's no way of reading the revision register to figure this one out without having to add a new DT attribute ?

I did a quick patch to read the Module revision register:
http://slexy.org/view/s21TKvlWlR

sdp2430: Revision: 1.2, Spec: 0.0, normal interrupt

OMAP3430-ldp: (ES2.1): Revision: 2.6, Spec: 0.0, normal interrupt SDP3430:(ES3.0) Revision: 2.6, Spec: 0.0, normal interrupt
AM3517-evm: (ES1.1): Revision: 2.6, Spec: 0.0, normal interrupt AM3517-crane:(ES1.1): Revision: 2.6, Spec: 0.0, normal interrupt

AM37x-evm: (ES1.2) Revision: 2.6, Spec: 0.0, normal interrupt OMAP3630-beag-xm (ES1.2): Revision: 2.6, Spec: 0.0, normal interrupt

am335x-evm:(ES1.0): Revision: 3.1, Spec: 0.1, normal interrupt
am335x-sk: (ES2.1): Revision: 3.1, Spec: 0.1, normal interrupt am335x-beaglebone-black:(ES2.0): Revision: 3.1, Spec: 0.1, normal interrupt

sdp4430.txt: (ES2.2): Revision: 3.1, Spec: 0.1, normal interrupt

OMAP4460-panda-es (ES1.1): Revision: 3.1, Spec: 0.1, normal interrupt

OMAP5uevm:(ES2.0): Revision: 3.3, Spec: 0.2, normal interrupt dra7-evm (es1.1): Revision: 3.3, Spec: 0.2, normal interrupt

Quoted 4 lines

OMAP3430-ldp seems to be the only one impacted with module revision 2.6 -> so using revision information is not really helpful here. Hence the usage of a flag in dt attribute to indicate hardware impacted by erratum.

alright, that's too bad. Seems like revision in this module isn't very useful :-(

Quoted 46 lines · Felipe Balbi

Hi,

Quoted 42 lines · Nishanth Menon

Quoted 11 lines · Felipe Balbi

Quoted 6 lines · Nishanth Menon

When device is booted using devicetree, platforms impacted by Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum indicates that the module cannot do multi-block transfers.

Handle this by providing a boolean flag to indicate to driver that it is working on a hardware with mentioned limitation.

sure there's no way of reading the revision register to figure this one out without having to add a new DT attribute ?

I did a quick patch to read the Module revision register:
http://slexy.org/view/s21TKvlWlR

sdp2430: Revision: 1.2, Spec: 0.0, normal interrupt

OMAP3430-ldp: (ES2.1): Revision: 2.6, Spec: 0.0, normal interrupt SDP3430:(ES3.0) Revision: 2.6, Spec: 0.0, normal interrupt
AM3517-evm: (ES1.1): Revision: 2.6, Spec: 0.0, normal interrupt AM3517-crane:(ES1.1): Revision: 2.6, Spec: 0.0, normal interrupt

AM37x-evm: (ES1.2) Revision: 2.6, Spec: 0.0, normal interrupt OMAP3630-beag-xm (ES1.2): Revision: 2.6, Spec: 0.0, normal interrupt

am335x-evm:(ES1.0): Revision: 3.1, Spec: 0.1, normal interrupt
am335x-sk: (ES2.1): Revision: 3.1, Spec: 0.1, normal interrupt am335x-beaglebone-black:(ES2.0): Revision: 3.1, Spec: 0.1, normal interrupt

sdp4430.txt: (ES2.2): Revision: 3.1, Spec: 0.1, normal interrupt

OMAP4460-panda-es (ES1.1): Revision: 3.1, Spec: 0.1, normal interrupt

OMAP5uevm:(ES2.0): Revision: 3.3, Spec: 0.2, normal interrupt dra7-evm (es1.1): Revision: 3.3, Spec: 0.2, normal interrupt

OMAP3430-ldp seems to be the only one impacted with module revision 2.6 -> so using revision information is not really helpful here. Hence the usage of a flag in dt attribute to indicate hardware impacted by erratum.

Quoted 2 lines

alright, that's too bad. Seems like revision in this module isn't very useful :-(

Can I take that as an acked-by?

When device is booted using devicetree, platforms impacted by Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum indicates that the module cannot do multi-block transfers.

Handle this by providing a boolean flag to indicate to driver that it is working on a hardware with mentioned limitation.

Signed-off-by Nishanth Menon <[email protected]>

---

This explains the logs I see:
OMAP3430 LDP (ES2.2):
uImage only boot: http://slexy.org/raw/s2YrbMAi7c
uImage+dtb concatenated boot: http://slexy.org/raw/s20qVg17T0

With the following flag set, device is now able to consistently boot with device tree supported uImage+dtb concat boot.

  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |    2 ++
  drivers/mmc/host/omap_hsmmc.c                      |    3 +++
  2 files changed, 5 insertions(+)

Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +0 -0

index 8c8908a..ab36f8b 100644

Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +0 -0

  Examples:
 

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

index 014bfe5..f2d5940 100644
@@ -1730,6 +1730,9 @@ static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev)
  	if (of_find_property(np, "ti,dual-volt", NULL))
  		pdata->controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT;
 
+	if (of_find_property(np, "ti,erratum-2.1.1.128", NULL))
+		pdata->controller_flags |= OMAP_HSMMC_BROKEN_MULTIBLOCK_READ;
+
  	/* This driver only supports 1 slot */
  	pdata->nr_slots = 1;
  	pdata->slots[0].switch_pin = cd_gpio;

Quoted 22 lines · Nishanth Menon

When device is booted using devicetree, platforms impacted by Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum indicates that the module cannot do multi-block transfers.

Handle this by providing a boolean flag to indicate to driver that it is working on a hardware with mentioned limitation.

Signed-off-by Nishanth Menon <[email protected]>

---

This explains the logs I see:
OMAP3430 LDP (ES2.2):
uImage only boot: http://slexy.org/raw/s2YrbMAi7c
uImage+dtb concatenated boot: http://slexy.org/raw/s20qVg17T0

With the following flag set, device is now able to consistently boot with device tree supported uImage+dtb concat boot.

  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |    2 ++
  drivers/mmc/host/omap_hsmmc.c                      |    3 +++
  2 files changed, 5 insertions(+)

Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt specifier is required. · line 30

Quoted 10 lines

Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +2 -0

index 8c8908a..ab36f8b 100644
@@ -26,6 +26,8 @@ specifier is required.
  dma-names: List of DMA request names. These strings correspond
  1:1 with the DMA specifiers listed in dmas. The string naming is
  to be "rx" and "tx" for RX and TX DMA requests, respectively.
+ti,erratum-2.1.1.128: boolean, for OMAP3430/OMAP35xx platforms with broken
+multiblock reads

Rather than ti,errata.. specific property, something like caps no/disable multiblock read is more readable in my opinion, Otherwise

Acked-by Balaji T K <[email protected]>

Quoted 18 lines

Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +0 -0

  Examples:
 

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

index 014bfe5..f2d5940 100644
@@ -1730,6 +1730,9 @@ static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev)
  	if (of_find_property(np, "ti,dual-volt", NULL))
  		pdata->controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT;
 
+	if (of_find_property(np, "ti,erratum-2.1.1.128", NULL))
+		pdata->controller_flags |= OMAP_HSMMC_BROKEN_MULTIBLOCK_READ;
+
  	/* This driver only supports 1 slot */
  	pdata->nr_slots = 1;
  	pdata->slots[0].switch_pin = cd_gpio;

Quoted 23 lines · Balaji T K

Quoted 22 lines · Nishanth Menon

When device is booted using devicetree, platforms impacted by Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum indicates that the module cannot do multi-block transfers.

Handle this by providing a boolean flag to indicate to driver that it is working on a hardware with mentioned limitation.

Signed-off-by Nishanth Menon <[email protected]>

---

This explains the logs I see:
OMAP3430 LDP (ES2.2):
uImage only boot: http://slexy.org/raw/s2YrbMAi7c
uImage+dtb concatenated boot: http://slexy.org/raw/s20qVg17T0

With the following flag set, device is now able to consistently boot with device tree supported uImage+dtb concat boot.

   .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |    2 ++
   drivers/mmc/host/omap_hsmmc.c                      |    3 +++
   2 files changed, 5 insertions(+)

Quoted 13 lines

Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt specifier is required. · line 30

Quoted 10 lines

Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +2 -0

index 8c8908a..ab36f8b 100644
@@ -26,6 +26,8 @@ specifier is required.
   dma-names: List of DMA request names. These strings correspond
   1:1 with the DMA specifiers listed in dmas. The string naming is
   to be "rx" and "tx" for RX and TX DMA requests, respectively.
+ti,erratum-2.1.1.128: boolean, for OMAP3430/OMAP35xx platforms with broken
+multiblock reads

Rather than ti,errata.. specific property, something like caps no/disable multiblock read is more readable in my opinion, Otherwise

Is'nt the better definition to state i have quirk X and allow the driver to do the necessary thing/things needed to handle quirk X? in this case, there is just one thing to do: broken multi_block_read, in the case of other quirks, there might be more than 1 thing to do.. let driver figure that out, dts just states the h/w capabilty or in this case, the quirk capability.

Quoted 22 lines

Acked-by Balaji T K <[email protected]>

Quoted 18 lines

Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +0 -0

   Examples:
 

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

index 014bfe5..f2d5940 100644
@@ -1730,6 +1730,9 @@ static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev)
   	if (of_find_property(np, "ti,dual-volt", NULL))
   		pdata->controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT;
 
+	if (of_find_property(np, "ti,erratum-2.1.1.128", NULL))
+		pdata->controller_flags |= OMAP_HSMMC_BROKEN_MULTIBLOCK_READ;
+
   	/* This driver only supports 1 slot */
   	pdata->nr_slots = 1;
   	pdata->slots[0].switch_pin = cd_gpio;

Quoted 38 lines · Nishanth Menon

Quoted 23 lines · Balaji T K

Quoted 22 lines · Nishanth Menon

When device is booted using devicetree, platforms impacted by Erratum 2.1.1.128 is not detected easily in the mmc driver. This erratum indicates that the module cannot do multi-block transfers.

Handle this by providing a boolean flag to indicate to driver that it is working on a hardware with mentioned limitation.

Signed-off-by Nishanth Menon <[email protected]>

---

This explains the logs I see:
OMAP3430 LDP (ES2.2):
uImage only boot: http://slexy.org/raw/s2YrbMAi7c
uImage+dtb concatenated boot: http://slexy.org/raw/s20qVg17T0

With the following flag set, device is now able to consistently boot with device tree supported uImage+dtb concat boot.

   .../devicetree/bindings/mmc/ti-omap-hsmmc.txt      |    2 ++
   drivers/mmc/host/omap_hsmmc.c                      |    3 +++
   2 files changed, 5 insertions(+)

Quoted 13 lines

Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt specifier is required. · line 30

Quoted 10 lines

Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +2 -0

index 8c8908a..ab36f8b 100644
@@ -26,6 +26,8 @@ specifier is required.
   dma-names: List of DMA request names. These strings correspond
   1:1 with the DMA specifiers listed in dmas. The string naming is
   to be "rx" and "tx" for RX and TX DMA requests, respectively.
+ti,erratum-2.1.1.128: boolean, for OMAP3430/OMAP35xx platforms with broken
+multiblock reads

Rather than ti,errata.. specific property, something like caps no/disable multiblock read is more readable in my opinion, Otherwise

Quoted 7 lines

Is'nt the better definition to state i have quirk X and allow the driver to do the necessary thing/things needed to handle quirk X? in this case, there is just one thing to do: broken multi_block_read, in the case of other quirks, there might be more than 1 thing to do.. let driver figure that out, dts just states the h/w capabilty or in this case, the quirk capability.

But in this case there is only one. disable multi block read is more readable than the errata reference, No strong feelings though.

Quoted 12 lines · Balaji T K

Quoted 11 lines

Quoted 3 lines

Rather than ti,errata.. specific property, something like caps no/disable multiblock read is more readable in my opinion, Otherwise

Is'nt the better definition to state i have quirk X and allow the driver to do the necessary thing/things needed to handle quirk X? in this case, there is just one thing to do: broken multi_block_read, in the case of other quirks, there might be more than 1 thing to do.. let driver figure that out, dts just states the h/w capabilty or in this case, the quirk capability.

Quoted 2 lines

But in this case there is only one. disable multi block read is more readable than the errata reference, No strong feelings though.

Considering this might set an precedence for other quirk description, I'd like to leave it as it stands.

Quoted 16 lines · Nishanth Menon

Quoted 14 lines · Balaji T K

Quoted 11 lines

Quoted 3 lines

Rather than ti,errata.. specific property, something like caps no/disable multiblock read is more readable in my opinion, Otherwise

Is'nt the better definition to state i have quirk X and allow the driver to do the necessary thing/things needed to handle quirk X? in this case, there is just one thing to do: broken multi_block_read, in the case of other quirks, there might be more than 1 thing to do.. let driver figure that out, dts just states the h/w capabilty or in this case, the quirk capability.

But in this case there is only one. disable multi block read is more readable than the errata reference, No strong feelings though.

Quoted 2 lines

Considering this might set an precedence for other quirk description, I'd like to leave it as it stands.

Hmm if this really depends on the hardware version, how about just add new compatible flag ti,omap3430-rev-xyz-hsmmc that allows the driver to deal with the errata?