Re: [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
On 02/13/2014 05:05 PM, Tony Lindgren wrote: > * Nishanth Menon [140205 06:15]: >> On Wed 05 Feb 2014 08:10:34 AM CST, Balaji T K wrote: > > 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. >> >> 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? > yep - that is a very good idea. updated v2 series tested and posted: http://marc.info/?l=linux-omap&m=139235682727541&w=2 https://patchwork.kernel.org/patch/3650061/ https://patchwork.kernel.org/patch/3650031/ -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
* Nishanth Menon [140205 06:15]: > On Wed 05 Feb 2014 08:10:34 AM CST, Balaji T K wrote: > >>> > >>> 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. > > 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? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
On Wed 05 Feb 2014 08:10:34 AM CST, Balaji T K wrote: > On Tuesday 04 February 2014 08:48 PM, Nishanth Menon wrote: >> On 02/04/2014 06:44 AM, Balaji T K wrote: >>> On Tuesday 21 January 2014 04:59 AM, Nishanth Menon wrote: 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 --- 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(+) diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index 8c8908a..ab36f8b 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -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. >> > > 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. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
On Tuesday 04 February 2014 08:48 PM, Nishanth Menon wrote: On 02/04/2014 06:44 AM, Balaji T K wrote: On Tuesday 21 January 2014 04:59 AM, Nishanth Menon wrote: 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 --- 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(+) diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index 8c8908a..ab36f8b 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -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. But in this case there is only one. disable multi block read is more readable than the errata reference, No strong feelings though. Acked-by: Balaji T K Examples: diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 014bfe5..f2d5940 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -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; -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
On 02/04/2014 06:44 AM, Balaji T K wrote: > On Tuesday 21 January 2014 04:59 AM, Nishanth Menon wrote: >> 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 >> --- >> >> 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(+) >> >> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt >> b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt >> index 8c8908a..ab36f8b 100644 >> --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt >> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt >> @@ -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. > > Acked-by: Balaji T K > >> >> Examples: >> >> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c >> index 014bfe5..f2d5940 100644 >> --- a/drivers/mmc/host/omap_hsmmc.c >> +++ b/drivers/mmc/host/omap_hsmmc.c >> @@ -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; >> > -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
On Tuesday 21 January 2014 04:59 AM, Nishanth Menon wrote: 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 --- 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(+) diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index 8c8908a..ab36f8b 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -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 Examples: diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 014bfe5..f2d5940 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -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; -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
On Tue, Jan 21, 2014 at 01:39:20PM -0600, Nishanth Menon wrote: > On Tue, Jan 21, 2014 at 12:05 PM, Felipe Balbi wrote: > > Hi, > > > > On Tue, Jan 21, 2014 at 11:38:00AM -0600, Nishanth Menon wrote: > >> On 01/20/2014 05:39 PM, Felipe Balbi wrote: > >> > On Mon, Jan 20, 2014 at 05:29:02PM -0600, Nishanth Menon wrote: > >> >> 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. > > > > alright, that's too bad. Seems like revision in this module isn't very > > useful :-( > > Can I take that as an acked-by? sure Acked-by: Felipe Balbi -- balbi signature.asc Description: Digital signature
Re: [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
On Tue, Jan 21, 2014 at 12:05 PM, Felipe Balbi wrote: > Hi, > > On Tue, Jan 21, 2014 at 11:38:00AM -0600, Nishanth Menon wrote: >> On 01/20/2014 05:39 PM, Felipe Balbi wrote: >> > On Mon, Jan 20, 2014 at 05:29:02PM -0600, Nishanth Menon wrote: >> >> 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. > > alright, that's too bad. Seems like revision in this module isn't very > useful :-( Can I take that as an acked-by? Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
Hi, On Tue, Jan 21, 2014 at 11:38:00AM -0600, Nishanth Menon wrote: > On 01/20/2014 05:39 PM, Felipe Balbi wrote: > > On Mon, Jan 20, 2014 at 05:29:02PM -0600, Nishanth Menon wrote: > >> 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. alright, that's too bad. Seems like revision in this module isn't very useful :-( -- balbi signature.asc Description: Digital signature
Re: [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
On 01/20/2014 05:39 PM, Felipe Balbi wrote: > On Mon, Jan 20, 2014 at 05:29:02PM -0600, Nishanth Menon wrote: >> 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. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: omap_hsmmc: Add support for Erratum 2.1.1.128 in device tree boot
On Mon, Jan 20, 2014 at 05:29:02PM -0600, Nishanth Menon wrote: > 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 ? -- balbi signature.asc Description: Digital signature
[PATCH] 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. Signed-off-by: Nishanth Menon --- 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(+) diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index 8c8908a..ab36f8b 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -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 Examples: diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 014bfe5..f2d5940 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -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; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
