| Message ID | 1390260542-22213-1-git-send-email-nm@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 ?
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.
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 :-(
On Tue, Jan 21, 2014 at 12:05 PM, Felipe Balbi <balbi@ti.com> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jan 21, 2014 at 01:39:20PM -0600, Nishanth Menon wrote: > On Tue, Jan 21, 2014 at 12:05 PM, Felipe Balbi <balbi@ti.com> 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@ti.com>
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 <nm@ti.com> > --- > > 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 <balajitk@ti.com> > > 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <nm@ti.com> >> --- >> >> 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 <balajitk@ti.com> > >> >> 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; >> >
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 <nm@ti.com> >>> --- >>> >>> 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 <balajitk@ti.com> >> >>> >>> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <nm@ti.com> >>>> --- >>>> >>>> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Nishanth Menon <nm@ti.com> [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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/13/2014 05:05 PM, Tony Lindgren wrote: > * Nishanth Menon <nm@ti.com> [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/
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;
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 <nm@ti.com> --- 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(+)