* [RFC 0/2] Add device tree property and quirk for supporting sdhci @ 2016-09-23 20:01 ` Zach Brown 0 siblings, 0 replies; 19+ messages in thread From: Zach Brown @ 2016-09-23 20:01 UTC (permalink / raw) To: ulf.hansson Cc: adrian.hunter, robh+dt, mark.rutland, linux-mmc, devicetree, linux-kernel, zach.brown Some board configurations can not support sd highspeed mode due to the distance between the card slot and the controller. The card and controller report that they are capable of highspeed however, so we need a mechanism for specifying that the setup is incapable of supporting highspeed mode. The first patch adds documentation about a new devicetree property sd-broken-highspeed. The second patch keeps the sd controller and card from going into highspeed mode when the property is set. Chen Yee Chew (1): sdhci: Prevent SD from doing high-speed timing when sd-broken-highspeed property is set Zach Brown (1): sdhci: Add device tree property sd-broken-highspeed Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ arch/arm/boot/dts/ni-77D5.dts | 1 - drivers/mmc/host/sdhci-pltfm.c | 3 +++ drivers/mmc/host/sdhci.c | 3 ++- drivers/mmc/host/sdhci.h | 2 ++ 5 files changed, 9 insertions(+), 2 deletions(-) -- 2.7.4 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC 0/2] Add device tree property and quirk for supporting sdhci @ 2016-09-23 20:01 ` Zach Brown 0 siblings, 0 replies; 19+ messages in thread From: Zach Brown @ 2016-09-23 20:01 UTC (permalink / raw) To: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A Cc: adrian.hunter-ral2JQCrhuEAvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8, linux-mmc-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA, zach.brown-acOepvfBmUk Some board configurations can not support sd highspeed mode due to the distance between the card slot and the controller. The card and controller report that they are capable of highspeed however, so we need a mechanism for specifying that the setup is incapable of supporting highspeed mode. The first patch adds documentation about a new devicetree property sd-broken-highspeed. The second patch keeps the sd controller and card from going into highspeed mode when the property is set. Chen Yee Chew (1): sdhci: Prevent SD from doing high-speed timing when sd-broken-highspeed property is set Zach Brown (1): sdhci: Add device tree property sd-broken-highspeed Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ arch/arm/boot/dts/ni-77D5.dts | 1 - drivers/mmc/host/sdhci-pltfm.c | 3 +++ drivers/mmc/host/sdhci.c | 3 ++- drivers/mmc/host/sdhci.h | 2 ++ 5 files changed, 9 insertions(+), 2 deletions(-) -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed 2016-09-23 20:01 ` Zach Brown (?) @ 2016-09-23 20:01 ` Zach Brown 2016-10-03 17:37 ` Rob Herring 2016-10-05 18:33 ` Ulf Hansson -1 siblings, 2 replies; 19+ messages in thread From: Zach Brown @ 2016-09-23 20:01 UTC (permalink / raw) To: ulf.hansson Cc: adrian.hunter, robh+dt, mark.rutland, linux-mmc, devicetree, linux-kernel, zach.brown Certain board configurations can make highspeed malfunction due to timing issues. In these cases a way is needed to force the controller and card into standard speed even if they otherwise appear to be capable of highspeed. The sd-broken-highspeed property will let the sdhci driver know that highspeed will not work. Signed-off-by: Zach Brown <zach.brown@ni.com> --- Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 8a37782..59332ea 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -52,6 +52,8 @@ Optional properties: - no-sdio: controller is limited to send sdio cmd during initialization - no-sd: controller is limited to send sd cmd during initialization - no-mmc: controller is limited to send mmc cmd during initialization +- sd-broken-highspeed: Highspeed is broken, even if the controller and card + themselves claim they support highspeed. *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line polarity properties, we have to fix the meaning of the "normal" and "inverted" -- 2.7.4 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed @ 2016-10-03 17:37 ` Rob Herring 0 siblings, 0 replies; 19+ messages in thread From: Rob Herring @ 2016-10-03 17:37 UTC (permalink / raw) To: Zach Brown Cc: ulf.hansson, adrian.hunter, mark.rutland, linux-mmc, devicetree, linux-kernel On Fri, Sep 23, 2016 at 03:01:08PM -0500, Zach Brown wrote: > Certain board configurations can make highspeed malfunction due to > timing issues. In these cases a way is needed to force the controller > and card into standard speed even if they otherwise appear to be capable > of highspeed. > > The sd-broken-highspeed property will let the sdhci driver know that > highspeed will not work. > > Signed-off-by: Zach Brown <zach.brown@ni.com> > --- > Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ > 1 file changed, 2 insertions(+) Acked-by: Rob Herring <robh@kernel.org> ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed @ 2016-10-03 17:37 ` Rob Herring 0 siblings, 0 replies; 19+ messages in thread From: Rob Herring @ 2016-10-03 17:37 UTC (permalink / raw) To: Zach Brown Cc: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A, adrian.hunter-ral2JQCrhuEAvxtiuMwx3w, mark.rutland-5wv7dgnIgG8, linux-mmc-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA On Fri, Sep 23, 2016 at 03:01:08PM -0500, Zach Brown wrote: > Certain board configurations can make highspeed malfunction due to > timing issues. In these cases a way is needed to force the controller > and card into standard speed even if they otherwise appear to be capable > of highspeed. > > The sd-broken-highspeed property will let the sdhci driver know that > highspeed will not work. > > Signed-off-by: Zach Brown <zach.brown-acOepvfBmUk@public.gmane.org> > --- > Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ > 1 file changed, 2 insertions(+) Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed 2016-09-23 20:01 ` [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed Zach Brown 2016-10-03 17:37 ` Rob Herring @ 2016-10-05 18:33 ` Ulf Hansson 2016-10-05 20:03 ` Rob Herring 1 sibling, 1 reply; 19+ messages in thread From: Ulf Hansson @ 2016-10-05 18:33 UTC (permalink / raw) To: Zach Brown Cc: Adrian Hunter, Rob Herring, Mark Rutland, linux-mmc, devicetree, linux-kernel On 23 September 2016 at 22:01, Zach Brown <zach.brown@ni.com> wrote: > Certain board configurations can make highspeed malfunction due to > timing issues. In these cases a way is needed to force the controller > and card into standard speed even if they otherwise appear to be capable > of highspeed. > > The sd-broken-highspeed property will let the sdhci driver know that > highspeed will not work. > > Signed-off-by: Zach Brown <zach.brown@ni.com> > --- > Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt > index 8a37782..59332ea 100644 > --- a/Documentation/devicetree/bindings/mmc/mmc.txt > +++ b/Documentation/devicetree/bindings/mmc/mmc.txt > @@ -52,6 +52,8 @@ Optional properties: > - no-sdio: controller is limited to send sdio cmd during initialization > - no-sd: controller is limited to send sd cmd during initialization > - no-mmc: controller is limited to send mmc cmd during initialization > +- sd-broken-highspeed: Highspeed is broken, even if the controller and card > + themselves claim they support highspeed. Regarding a broken card, that is managed via the card quirks and not in DT. If this is about a controller limitation, we already have the option to describe what it supports, so we don't need an option to tell what it *not* supports. For example "cap-sd-highspeed" tells whether the controller supports SD high-speed, please use that instead. > > *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line > polarity properties, we have to fix the meaning of the "normal" and "inverted" > -- > 2.7.4 > Kind regards Uffe ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed 2016-10-05 18:33 ` Ulf Hansson @ 2016-10-05 20:03 ` Rob Herring 2016-10-05 21:22 ` Julia Cartwright 2016-10-06 8:03 ` Ulf Hansson 0 siblings, 2 replies; 19+ messages in thread From: Rob Herring @ 2016-10-05 20:03 UTC (permalink / raw) To: Ulf Hansson Cc: Zach Brown, Adrian Hunter, Mark Rutland, linux-mmc, devicetree, linux-kernel On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote: > On 23 September 2016 at 22:01, Zach Brown <zach.brown@ni.com> wrote: >> Certain board configurations can make highspeed malfunction due to >> timing issues. In these cases a way is needed to force the controller >> and card into standard speed even if they otherwise appear to be capable >> of highspeed. >> >> The sd-broken-highspeed property will let the sdhci driver know that >> highspeed will not work. >> >> Signed-off-by: Zach Brown <zach.brown@ni.com> >> --- >> Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt >> index 8a37782..59332ea 100644 >> --- a/Documentation/devicetree/bindings/mmc/mmc.txt >> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt >> @@ -52,6 +52,8 @@ Optional properties: >> - no-sdio: controller is limited to send sdio cmd during initialization >> - no-sd: controller is limited to send sd cmd during initialization >> - no-mmc: controller is limited to send mmc cmd during initialization >> +- sd-broken-highspeed: Highspeed is broken, even if the controller and card >> + themselves claim they support highspeed. > > Regarding a broken card, that is managed via the card quirks and not in DT. > > If this is about a controller limitation, we already have the option > to describe what it supports, so we don't need an option to tell what > it *not* supports. > > For example "cap-sd-highspeed" tells whether the controller supports > SD high-speed, please use that instead. If a controller has a capability register and it lies (perhaps the board has limitations that the SoC does not), then you may need to disable a feature. Rob ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed @ 2016-10-05 21:22 ` Julia Cartwright 0 siblings, 0 replies; 19+ messages in thread From: Julia Cartwright @ 2016-10-05 21:22 UTC (permalink / raw) To: Rob Herring Cc: Ulf Hansson, Zach Brown, Adrian Hunter, Mark Rutland, linux-mmc, devicetree, linux-kernel On Wed, Oct 05, 2016 at 03:03:44PM -0500, Rob Herring wrote: > On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote: > > On 23 September 2016 at 22:01, Zach Brown <zach.brown@ni.com> wrote: > >> Certain board configurations can make highspeed malfunction due to > >> timing issues. In these cases a way is needed to force the controller > >> and card into standard speed even if they otherwise appear to be capable > >> of highspeed. > >> > >> The sd-broken-highspeed property will let the sdhci driver know that > >> highspeed will not work. > >> > >> Signed-off-by: Zach Brown <zach.brown@ni.com> > >> --- > >> Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt > >> index 8a37782..59332ea 100644 > >> --- a/Documentation/devicetree/bindings/mmc/mmc.txt > >> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt > >> @@ -52,6 +52,8 @@ Optional properties: > >> - no-sdio: controller is limited to send sdio cmd during initialization > >> - no-sd: controller is limited to send sd cmd during initialization > >> - no-mmc: controller is limited to send mmc cmd during initialization > >> +- sd-broken-highspeed: Highspeed is broken, even if the controller and card > >> + themselves claim they support highspeed. > > > > Regarding a broken card, that is managed via the card quirks and not in DT. > > > > If this is about a controller limitation, we already have the option > > to describe what it supports, so we don't need an option to tell what > > it *not* supports. > > > > For example "cap-sd-highspeed" tells whether the controller supports > > SD high-speed, please use that instead. > > If a controller has a capability register and it lies (perhaps the > board has limitations that the SoC does not), then you may need to > disable a feature. That's precisely the case here. This is a board-level problem, not a card or controller problem. As Zach mentioned in the cover letter, the trace length between controller and card on some of our boards is too long to meet high-speed timings, even though both card and controller advertise it. Thanks, Julia ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed @ 2016-10-05 21:22 ` Julia Cartwright 0 siblings, 0 replies; 19+ messages in thread From: Julia Cartwright @ 2016-10-05 21:22 UTC (permalink / raw) To: Rob Herring Cc: Ulf Hansson, Zach Brown, Adrian Hunter, Mark Rutland, linux-mmc, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA On Wed, Oct 05, 2016 at 03:03:44PM -0500, Rob Herring wrote: > On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: > > On 23 September 2016 at 22:01, Zach Brown <zach.brown-acOepvfBmUk@public.gmane.org> wrote: > >> Certain board configurations can make highspeed malfunction due to > >> timing issues. In these cases a way is needed to force the controller > >> and card into standard speed even if they otherwise appear to be capable > >> of highspeed. > >> > >> The sd-broken-highspeed property will let the sdhci driver know that > >> highspeed will not work. > >> > >> Signed-off-by: Zach Brown <zach.brown-acOepvfBmUk@public.gmane.org> > >> --- > >> Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt > >> index 8a37782..59332ea 100644 > >> --- a/Documentation/devicetree/bindings/mmc/mmc.txt > >> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt > >> @@ -52,6 +52,8 @@ Optional properties: > >> - no-sdio: controller is limited to send sdio cmd during initialization > >> - no-sd: controller is limited to send sd cmd during initialization > >> - no-mmc: controller is limited to send mmc cmd during initialization > >> +- sd-broken-highspeed: Highspeed is broken, even if the controller and card > >> + themselves claim they support highspeed. > > > > Regarding a broken card, that is managed via the card quirks and not in DT. > > > > If this is about a controller limitation, we already have the option > > to describe what it supports, so we don't need an option to tell what > > it *not* supports. > > > > For example "cap-sd-highspeed" tells whether the controller supports > > SD high-speed, please use that instead. > > If a controller has a capability register and it lies (perhaps the > board has limitations that the SoC does not), then you may need to > disable a feature. That's precisely the case here. This is a board-level problem, not a card or controller problem. As Zach mentioned in the cover letter, the trace length between controller and card on some of our boards is too long to meet high-speed timings, even though both card and controller advertise it. Thanks, Julia -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed 2016-10-05 21:22 ` Julia Cartwright (?) @ 2016-10-06 1:34 ` Shawn Lin 2016-10-06 6:13 ` Adrian Hunter -1 siblings, 1 reply; 19+ messages in thread From: Shawn Lin @ 2016-10-06 1:34 UTC (permalink / raw) To: Julia Cartwright, Rob Herring Cc: shawn.lin, Ulf Hansson, Zach Brown, Adrian Hunter, Mark Rutland, linux-mmc, devicetree, linux-kernel On 2016/10/6 5:22, Julia Cartwright wrote: > On Wed, Oct 05, 2016 at 03:03:44PM -0500, Rob Herring wrote: >> On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>> On 23 September 2016 at 22:01, Zach Brown <zach.brown@ni.com> wrote: >>>> Certain board configurations can make highspeed malfunction due to >>>> timing issues. In these cases a way is needed to force the controller >>>> and card into standard speed even if they otherwise appear to be capable >>>> of highspeed. >>>> >>>> The sd-broken-highspeed property will let the sdhci driver know that >>>> highspeed will not work. >>>> >>>> Signed-off-by: Zach Brown <zach.brown@ni.com> >>>> --- >>>> Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ >>>> 1 file changed, 2 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt >>>> index 8a37782..59332ea 100644 >>>> --- a/Documentation/devicetree/bindings/mmc/mmc.txt >>>> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt >>>> @@ -52,6 +52,8 @@ Optional properties: >>>> - no-sdio: controller is limited to send sdio cmd during initialization >>>> - no-sd: controller is limited to send sd cmd during initialization >>>> - no-mmc: controller is limited to send mmc cmd during initialization >>>> +- sd-broken-highspeed: Highspeed is broken, even if the controller and card >>>> + themselves claim they support highspeed. >>> >>> Regarding a broken card, that is managed via the card quirks and not in DT. >>> >>> If this is about a controller limitation, we already have the option >>> to describe what it supports, so we don't need an option to tell what >>> it *not* supports. >>> >>> For example "cap-sd-highspeed" tells whether the controller supports >>> SD high-speed, please use that instead. >> >> If a controller has a capability register and it lies (perhaps the >> board has limitations that the SoC does not), then you may need to >> disable a feature. > > That's precisely the case here. This is a board-level problem, not a > card or controller problem. As Zach mentioned in the cover letter, the > trace length between controller and card on some of our boards is too > long to meet high-speed timings, even though both card and controller > advertise it. IIRC, I saw the same problem while using sdhci to bring up a industrial board for vehicle. The trace length is so long that I have to limit the max-frequency to make it works properly when running at hishspeed. So could you try to limit the max-frequency in your DT to see if it could work for you? I guess it should work as once reducing the frequency, the timing per cycle will be large enough to meet the spec. At least that helped me solve my problem. For further consideration, I deployed a mechanism called "tuning for non UHS or non-hs200/400" for my donwstream tree at that time. The basic concept is to ask devices to send ext_csd(or send status for SD case) *repeatedly*. Some hosts, i.e. sdhci-of-arasan or dw_mmc-rockchip, can manually set rx delay via some clock unit registers to capture the working sample window and select the middle point of the longest good phase region. The same for retune. But it is a little complicated, and could only be applicable to the hosts who could adjust the rx delay manually when claiming the caps of MMC_CAPS_CAN_TUNING_FOR_HS, whatever the name is... I don't know if it is worth to add this, and I don't know if it's a legit way. Anyway, I just share my thought(experience) for you and linux-mmc to think more about how to deal with the case you meet rather than sacrificing the performence by removing highspeed or reducing frequency.. > > Thanks, > Julia > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Best Regards Shawn Lin ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed @ 2016-10-06 6:13 ` Adrian Hunter 0 siblings, 0 replies; 19+ messages in thread From: Adrian Hunter @ 2016-10-06 6:13 UTC (permalink / raw) To: Shawn Lin, Julia Cartwright, Rob Herring Cc: Ulf Hansson, Zach Brown, Mark Rutland, linux-mmc, devicetree, linux-kernel On 06/10/16 04:34, Shawn Lin wrote: > On 2016/10/6 5:22, Julia Cartwright wrote: >> On Wed, Oct 05, 2016 at 03:03:44PM -0500, Rob Herring wrote: >>> On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >>>> On 23 September 2016 at 22:01, Zach Brown <zach.brown@ni.com> wrote: >>>>> Certain board configurations can make highspeed malfunction due to >>>>> timing issues. In these cases a way is needed to force the controller >>>>> and card into standard speed even if they otherwise appear to be capable >>>>> of highspeed. >>>>> >>>>> The sd-broken-highspeed property will let the sdhci driver know that >>>>> highspeed will not work. >>>>> >>>>> Signed-off-by: Zach Brown <zach.brown@ni.com> >>>>> --- >>>>> Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ >>>>> 1 file changed, 2 insertions(+) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt >>>>> b/Documentation/devicetree/bindings/mmc/mmc.txt >>>>> index 8a37782..59332ea 100644 >>>>> --- a/Documentation/devicetree/bindings/mmc/mmc.txt >>>>> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt >>>>> @@ -52,6 +52,8 @@ Optional properties: >>>>> - no-sdio: controller is limited to send sdio cmd during initialization >>>>> - no-sd: controller is limited to send sd cmd during initialization >>>>> - no-mmc: controller is limited to send mmc cmd during initialization >>>>> +- sd-broken-highspeed: Highspeed is broken, even if the controller and >>>>> card >>>>> + themselves claim they support highspeed. >>>> >>>> Regarding a broken card, that is managed via the card quirks and not in DT. >>>> >>>> If this is about a controller limitation, we already have the option >>>> to describe what it supports, so we don't need an option to tell what >>>> it *not* supports. >>>> >>>> For example "cap-sd-highspeed" tells whether the controller supports >>>> SD high-speed, please use that instead. >>> >>> If a controller has a capability register and it lies (perhaps the >>> board has limitations that the SoC does not), then you may need to >>> disable a feature. >> >> That's precisely the case here. This is a board-level problem, not a >> card or controller problem. As Zach mentioned in the cover letter, the >> trace length between controller and card on some of our boards is too >> long to meet high-speed timings, even though both card and controller >> advertise it. > > IIRC, I saw the same problem while using sdhci to bring up a > industrial board for vehicle. The trace length is so long that > I have to limit the max-frequency to make it works properly when > running at hishspeed. > > So could you try to limit the max-frequency in your DT to see > if it could work for you? I guess it should work as once reducing > the frequency, the timing per cycle will be large enough to meet > the spec. At least that helped me solve my problem. > > For further consideration, I deployed a mechanism called "tuning for > non UHS or non-hs200/400" for my donwstream tree at that time. The basic > concept is to ask devices to send ext_csd(or send status for SD case) > *repeatedly*. Some hosts, i.e. sdhci-of-arasan or dw_mmc-rockchip, can > manually set rx delay via some clock unit registers to capture the > working sample window and select the middle point of the longest good > phase region. The same for retune. But it is a little complicated, and > could only be applicable to the hosts who could adjust the rx delay > manually when claiming the caps of MMC_CAPS_CAN_TUNING_FOR_HS, whatever > the name is... > > I don't know if it is worth to add this, and I don't know if it's > a legit way. Anyway, I just share my thought(experience) for you and > linux-mmc to think more about how to deal with the case you meet rather > than sacrificing the performence by removing highspeed or reducing > frequency.. > As Shawn points out, using max-frequency is a possibility. Did you consider that? There are 2 high speed caps: cap-sd-highspeed cap-mmc-highspeed Yet patch in 2, the effect of sd-broken-highspeed is to suppress highspeed for both SD and MMC. Should it then be called just broken-highspeed? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed @ 2016-10-06 6:13 ` Adrian Hunter 0 siblings, 0 replies; 19+ messages in thread From: Adrian Hunter @ 2016-10-06 6:13 UTC (permalink / raw) To: Shawn Lin, Julia Cartwright, Rob Herring Cc: Ulf Hansson, Zach Brown, Mark Rutland, linux-mmc, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA On 06/10/16 04:34, Shawn Lin wrote: > On 2016/10/6 5:22, Julia Cartwright wrote: >> On Wed, Oct 05, 2016 at 03:03:44PM -0500, Rob Herring wrote: >>> On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >>>> On 23 September 2016 at 22:01, Zach Brown <zach.brown-acOepvfBmUk@public.gmane.org> wrote: >>>>> Certain board configurations can make highspeed malfunction due to >>>>> timing issues. In these cases a way is needed to force the controller >>>>> and card into standard speed even if they otherwise appear to be capable >>>>> of highspeed. >>>>> >>>>> The sd-broken-highspeed property will let the sdhci driver know that >>>>> highspeed will not work. >>>>> >>>>> Signed-off-by: Zach Brown <zach.brown-acOepvfBmUk@public.gmane.org> >>>>> --- >>>>> Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ >>>>> 1 file changed, 2 insertions(+) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt >>>>> b/Documentation/devicetree/bindings/mmc/mmc.txt >>>>> index 8a37782..59332ea 100644 >>>>> --- a/Documentation/devicetree/bindings/mmc/mmc.txt >>>>> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt >>>>> @@ -52,6 +52,8 @@ Optional properties: >>>>> - no-sdio: controller is limited to send sdio cmd during initialization >>>>> - no-sd: controller is limited to send sd cmd during initialization >>>>> - no-mmc: controller is limited to send mmc cmd during initialization >>>>> +- sd-broken-highspeed: Highspeed is broken, even if the controller and >>>>> card >>>>> + themselves claim they support highspeed. >>>> >>>> Regarding a broken card, that is managed via the card quirks and not in DT. >>>> >>>> If this is about a controller limitation, we already have the option >>>> to describe what it supports, so we don't need an option to tell what >>>> it *not* supports. >>>> >>>> For example "cap-sd-highspeed" tells whether the controller supports >>>> SD high-speed, please use that instead. >>> >>> If a controller has a capability register and it lies (perhaps the >>> board has limitations that the SoC does not), then you may need to >>> disable a feature. >> >> That's precisely the case here. This is a board-level problem, not a >> card or controller problem. As Zach mentioned in the cover letter, the >> trace length between controller and card on some of our boards is too >> long to meet high-speed timings, even though both card and controller >> advertise it. > > IIRC, I saw the same problem while using sdhci to bring up a > industrial board for vehicle. The trace length is so long that > I have to limit the max-frequency to make it works properly when > running at hishspeed. > > So could you try to limit the max-frequency in your DT to see > if it could work for you? I guess it should work as once reducing > the frequency, the timing per cycle will be large enough to meet > the spec. At least that helped me solve my problem. > > For further consideration, I deployed a mechanism called "tuning for > non UHS or non-hs200/400" for my donwstream tree at that time. The basic > concept is to ask devices to send ext_csd(or send status for SD case) > *repeatedly*. Some hosts, i.e. sdhci-of-arasan or dw_mmc-rockchip, can > manually set rx delay via some clock unit registers to capture the > working sample window and select the middle point of the longest good > phase region. The same for retune. But it is a little complicated, and > could only be applicable to the hosts who could adjust the rx delay > manually when claiming the caps of MMC_CAPS_CAN_TUNING_FOR_HS, whatever > the name is... > > I don't know if it is worth to add this, and I don't know if it's > a legit way. Anyway, I just share my thought(experience) for you and > linux-mmc to think more about how to deal with the case you meet rather > than sacrificing the performence by removing highspeed or reducing > frequency.. > As Shawn points out, using max-frequency is a possibility. Did you consider that? There are 2 high speed caps: cap-sd-highspeed cap-mmc-highspeed Yet patch in 2, the effect of sd-broken-highspeed is to suppress highspeed for both SD and MMC. Should it then be called just broken-highspeed? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed 2016-10-06 6:13 ` Adrian Hunter (?) @ 2016-10-07 18:56 ` Zach Brown -1 siblings, 0 replies; 19+ messages in thread From: Zach Brown @ 2016-10-07 18:56 UTC (permalink / raw) To: Adrian Hunter Cc: Shawn Lin, Julia Cartwright, Rob Herring, Ulf Hansson, Mark Rutland, linux-mmc, devicetree, linux-kernel On Thu, Oct 06, 2016 at 09:13:24AM +0300, Adrian Hunter wrote: > On 06/10/16 04:34, Shawn Lin wrote: > > On 2016/10/6 5:22, Julia Cartwright wrote: > >> On Wed, Oct 05, 2016 at 03:03:44PM -0500, Rob Herring wrote: > >>> On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote: > >>>> On 23 September 2016 at 22:01, Zach Brown <zach.brown@ni.com> wrote: > >>>>> Certain board configurations can make highspeed malfunction due to > >>>>> timing issues. In these cases a way is needed to force the controller > >>>>> and card into standard speed even if they otherwise appear to be capable > >>>>> of highspeed. > >>>>> > >>>>> The sd-broken-highspeed property will let the sdhci driver know that > >>>>> highspeed will not work. > >>>>> > >>>>> Signed-off-by: Zach Brown <zach.brown@ni.com> > >>>>> --- > >>>>> Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ > >>>>> 1 file changed, 2 insertions(+) > >>>>> > >>>>> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt > >>>>> b/Documentation/devicetree/bindings/mmc/mmc.txt > >>>>> index 8a37782..59332ea 100644 > >>>>> --- a/Documentation/devicetree/bindings/mmc/mmc.txt > >>>>> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt > >>>>> @@ -52,6 +52,8 @@ Optional properties: > >>>>> - no-sdio: controller is limited to send sdio cmd during initialization > >>>>> - no-sd: controller is limited to send sd cmd during initialization > >>>>> - no-mmc: controller is limited to send mmc cmd during initialization > >>>>> +- sd-broken-highspeed: Highspeed is broken, even if the controller and > >>>>> card > >>>>> + themselves claim they support highspeed. > >>>> > >>>> Regarding a broken card, that is managed via the card quirks and not in DT. > >>>> > >>>> If this is about a controller limitation, we already have the option > >>>> to describe what it supports, so we don't need an option to tell what > >>>> it *not* supports. > >>>> > >>>> For example "cap-sd-highspeed" tells whether the controller supports > >>>> SD high-speed, please use that instead. > >>> > >>> If a controller has a capability register and it lies (perhaps the > >>> board has limitations that the SoC does not), then you may need to > >>> disable a feature. > >> > >> That's precisely the case here. This is a board-level problem, not a > >> card or controller problem. As Zach mentioned in the cover letter, the > >> trace length between controller and card on some of our boards is too > >> long to meet high-speed timings, even though both card and controller > >> advertise it. > > > > IIRC, I saw the same problem while using sdhci to bring up a > > industrial board for vehicle. The trace length is so long that > > I have to limit the max-frequency to make it works properly when > > running at hishspeed. > > > > So could you try to limit the max-frequency in your DT to see > > if it could work for you? I guess it should work as once reducing > > the frequency, the timing per cycle will be large enough to meet > > the spec. At least that helped me solve my problem. > > > > For further consideration, I deployed a mechanism called "tuning for > > non UHS or non-hs200/400" for my donwstream tree at that time. The basic > > concept is to ask devices to send ext_csd(or send status for SD case) > > *repeatedly*. Some hosts, i.e. sdhci-of-arasan or dw_mmc-rockchip, can > > manually set rx delay via some clock unit registers to capture the > > working sample window and select the middle point of the longest good > > phase region. The same for retune. But it is a little complicated, and > > could only be applicable to the hosts who could adjust the rx delay > > manually when claiming the caps of MMC_CAPS_CAN_TUNING_FOR_HS, whatever > > the name is... > > > > I don't know if it is worth to add this, and I don't know if it's > > a legit way. Anyway, I just share my thought(experience) for you and > > linux-mmc to think more about how to deal with the case you meet rather > > than sacrificing the performence by removing highspeed or reducing > > frequency.. > > > > As Shawn points out, using max-frequency is a possibility. Did you consider > that? > I hadn't. So I looked into it and, as I stated the issue using max-frequency would work, but I forgot to add that, because we pass the signal through an fpga it has to be standard speed. If the card and controller are not in standard speed then it won't pass hold time. Specifically we need the data to change on the falling edge of the clock. I'll add this justification to the commit message. > There are 2 high speed caps: > cap-sd-highspeed > cap-mmc-highspeed > > Yet patch in 2, the effect of sd-broken-highspeed is to suppress highspeed > for both SD and MMC. Should it then be called just broken-highspeed? > I agree, broken-highspeed makes more sense. Will change in the next version. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed @ 2016-10-06 8:03 ` Ulf Hansson 0 siblings, 0 replies; 19+ messages in thread From: Ulf Hansson @ 2016-10-06 8:03 UTC (permalink / raw) To: Rob Herring Cc: Zach Brown, Adrian Hunter, Mark Rutland, linux-mmc, devicetree, linux-kernel On 5 October 2016 at 22:03, Rob Herring <robh+dt@kernel.org> wrote: > On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote: >> On 23 September 2016 at 22:01, Zach Brown <zach.brown@ni.com> wrote: >>> Certain board configurations can make highspeed malfunction due to >>> timing issues. In these cases a way is needed to force the controller >>> and card into standard speed even if they otherwise appear to be capable >>> of highspeed. >>> >>> The sd-broken-highspeed property will let the sdhci driver know that >>> highspeed will not work. >>> >>> Signed-off-by: Zach Brown <zach.brown@ni.com> >>> --- >>> Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt >>> index 8a37782..59332ea 100644 >>> --- a/Documentation/devicetree/bindings/mmc/mmc.txt >>> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt >>> @@ -52,6 +52,8 @@ Optional properties: >>> - no-sdio: controller is limited to send sdio cmd during initialization >>> - no-sd: controller is limited to send sd cmd during initialization >>> - no-mmc: controller is limited to send mmc cmd during initialization >>> +- sd-broken-highspeed: Highspeed is broken, even if the controller and card >>> + themselves claim they support highspeed. >> >> Regarding a broken card, that is managed via the card quirks and not in DT. >> >> If this is about a controller limitation, we already have the option >> to describe what it supports, so we don't need an option to tell what >> it *not* supports. >> >> For example "cap-sd-highspeed" tells whether the controller supports >> SD high-speed, please use that instead. > > If a controller has a capability register and it lies (perhaps the > board has limitations that the SoC does not), then you may need to > disable a feature. I understand, although the SDHCI capabilities register is broken for most SDHCI variants. In principle, we would more or less have to add a *-broken binding for each bit in that register. I don't like that! Maybe a better option is to add a "sdhci-cap-broken" or perhaps "sdhci-cap-speed-modes-broken", which tells the driver to not rely on the capabilities register and instead find out what *is* supported by looking at the other mmc generic DT bindings. What do you think of that? Kind regards Uffe ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed @ 2016-10-06 8:03 ` Ulf Hansson 0 siblings, 0 replies; 19+ messages in thread From: Ulf Hansson @ 2016-10-06 8:03 UTC (permalink / raw) To: Rob Herring Cc: Zach Brown, Adrian Hunter, Mark Rutland, linux-mmc, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA On 5 October 2016 at 22:03, Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote: > On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote: >> On 23 September 2016 at 22:01, Zach Brown <zach.brown-acOepvfBmUk@public.gmane.org> wrote: >>> Certain board configurations can make highspeed malfunction due to >>> timing issues. In these cases a way is needed to force the controller >>> and card into standard speed even if they otherwise appear to be capable >>> of highspeed. >>> >>> The sd-broken-highspeed property will let the sdhci driver know that >>> highspeed will not work. >>> >>> Signed-off-by: Zach Brown <zach.brown-acOepvfBmUk@public.gmane.org> >>> --- >>> Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt >>> index 8a37782..59332ea 100644 >>> --- a/Documentation/devicetree/bindings/mmc/mmc.txt >>> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt >>> @@ -52,6 +52,8 @@ Optional properties: >>> - no-sdio: controller is limited to send sdio cmd during initialization >>> - no-sd: controller is limited to send sd cmd during initialization >>> - no-mmc: controller is limited to send mmc cmd during initialization >>> +- sd-broken-highspeed: Highspeed is broken, even if the controller and card >>> + themselves claim they support highspeed. >> >> Regarding a broken card, that is managed via the card quirks and not in DT. >> >> If this is about a controller limitation, we already have the option >> to describe what it supports, so we don't need an option to tell what >> it *not* supports. >> >> For example "cap-sd-highspeed" tells whether the controller supports >> SD high-speed, please use that instead. > > If a controller has a capability register and it lies (perhaps the > board has limitations that the SoC does not), then you may need to > disable a feature. I understand, although the SDHCI capabilities register is broken for most SDHCI variants. In principle, we would more or less have to add a *-broken binding for each bit in that register. I don't like that! Maybe a better option is to add a "sdhci-cap-broken" or perhaps "sdhci-cap-speed-modes-broken", which tells the driver to not rely on the capabilities register and instead find out what *is* supported by looking at the other mmc generic DT bindings. What do you think of that? Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed 2016-10-06 8:03 ` Ulf Hansson (?) @ 2016-10-17 21:49 ` Zach Brown -1 siblings, 0 replies; 19+ messages in thread From: Zach Brown @ 2016-10-17 21:49 UTC (permalink / raw) To: Ulf Hansson Cc: Rob Herring, Adrian Hunter, Mark Rutland, linux-mmc, devicetree, linux-kernel On Thu, Oct 06, 2016 at 10:03:56AM +0200, Ulf Hansson wrote: > On 5 October 2016 at 22:03, Rob Herring <robh+dt@kernel.org> wrote: > > On Wed, Oct 5, 2016 at 1:33 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote: > >> On 23 September 2016 at 22:01, Zach Brown <zach.brown@ni.com> wrote: > >>> Certain board configurations can make highspeed malfunction due to > >>> timing issues. In these cases a way is needed to force the controller > >>> and card into standard speed even if they otherwise appear to be capable > >>> of highspeed. > >>> > >>> The sd-broken-highspeed property will let the sdhci driver know that > >>> highspeed will not work. > >>> > >>> Signed-off-by: Zach Brown <zach.brown@ni.com> > >>> --- > >>> Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++ > >>> 1 file changed, 2 insertions(+) > >>> > >>> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt > >>> index 8a37782..59332ea 100644 > >>> --- a/Documentation/devicetree/bindings/mmc/mmc.txt > >>> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt > >>> @@ -52,6 +52,8 @@ Optional properties: > >>> - no-sdio: controller is limited to send sdio cmd during initialization > >>> - no-sd: controller is limited to send sd cmd during initialization > >>> - no-mmc: controller is limited to send mmc cmd during initialization > >>> +- sd-broken-highspeed: Highspeed is broken, even if the controller and card > >>> + themselves claim they support highspeed. > >> > >> Regarding a broken card, that is managed via the card quirks and not in DT. > >> > >> If this is about a controller limitation, we already have the option > >> to describe what it supports, so we don't need an option to tell what > >> it *not* supports. > >> > >> For example "cap-sd-highspeed" tells whether the controller supports > >> SD high-speed, please use that instead. > > > > If a controller has a capability register and it lies (perhaps the > > board has limitations that the SoC does not), then you may need to > > disable a feature. > > I understand, although the SDHCI capabilities register is broken for > most SDHCI variants. In principle, we would more or less have to add a > *-broken binding for each bit in that register. I don't like that! > > Maybe a better option is to add a "sdhci-cap-broken" or perhaps > "sdhci-cap-speed-modes-broken", which tells the driver to not rely on > the capabilities register and instead find out what *is* supported by > looking at the other mmc generic DT bindings. > > What do you think of that? > > Kind regards > Uffe "sdhci-cap-broken" seems too aggressive. There might only be one capability that the register incorrectly advertises. "sdhci-cap-speed-modes-broken" makes more sense and I will re-create this patch set using that idea. ^ permalink raw reply [flat|nested] 19+ messages in thread
* [RFC 2/2] sdhci: Prevent SD from doing highspeed timing when sd-broken-highspeed property is set 2016-09-23 20:01 ` Zach Brown (?) (?) @ 2016-09-23 20:01 ` Zach Brown 2016-10-06 6:39 ` Adrian Hunter -1 siblings, 1 reply; 19+ messages in thread From: Zach Brown @ 2016-09-23 20:01 UTC (permalink / raw) To: ulf.hansson Cc: adrian.hunter, robh+dt, mark.rutland, linux-mmc, devicetree, linux-kernel, zach.brown From: Chen Yee Chew <chen.yee.chew@ni.com> When the sd-broken-highspeed property is set the sdhci driver will not go into highspeed mode even if the controller and card appear to otherwise support highspeed mode. This is useful in cases where the controller and card support highspeed, but the board configuration or some other issue make highspeed impossible. Signed-off-by: Chen Yee Chew <chen.yee.chew@ni.com> Reviewed-by: Keng Soon Cheah <keng.soon.cheah@ni.com> Reviewed-by: Joe Hershberger <joe.hershberger@ni.com> Signed-off-by: Zach Brown <zach.brown@ni.com> --- drivers/mmc/host/sdhci-pltfm.c | 3 +++ drivers/mmc/host/sdhci.c | 3 ++- drivers/mmc/host/sdhci.h | 2 ++ 3 files changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c index ad49bfa..7482706 100644 --- a/drivers/mmc/host/sdhci-pltfm.c +++ b/drivers/mmc/host/sdhci-pltfm.c @@ -87,6 +87,9 @@ void sdhci_get_of_property(struct platform_device *pdev) if (of_get_property(np, "broken-cd", NULL)) host->quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION; + if (of_get_property(np, "sd-broken-highspeed", NULL)) + host->quirks2 |= SDHCI_QUIRK2_BROKEN_HISPD; + if (of_get_property(np, "no-1-8-v", NULL)) host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V; diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 4805566..4b0969c 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -3274,7 +3274,8 @@ int sdhci_setup_host(struct sdhci_host *host) if (host->quirks2 & SDHCI_QUIRK2_HOST_NO_CMD23) mmc->caps &= ~MMC_CAP_CMD23; - if (host->caps & SDHCI_CAN_DO_HISPD) + if ((host->caps & SDHCI_CAN_DO_HISPD) && + !(host->quirks2 & SDHCI_QUIRK2_BROKEN_HISPD)) mmc->caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED; if ((host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION) && diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h index c722cd2..3d0fdda 100644 --- a/drivers/mmc/host/sdhci.h +++ b/drivers/mmc/host/sdhci.h @@ -424,6 +424,8 @@ struct sdhci_host { #define SDHCI_QUIRK2_ACMD23_BROKEN (1<<14) /* Broken Clock divider zero in controller */ #define SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN (1<<15) +/* Highspeed is broken even if it appears otherwise */ +#define SDHCI_QUIRK2_BROKEN_HISPD (1<<16) int irq; /* Device IRQ */ void __iomem *ioaddr; /* Mapped address */ -- 2.7.4 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [RFC 2/2] sdhci: Prevent SD from doing highspeed timing when sd-broken-highspeed property is set @ 2016-10-06 6:39 ` Adrian Hunter 0 siblings, 0 replies; 19+ messages in thread From: Adrian Hunter @ 2016-10-06 6:39 UTC (permalink / raw) To: Zach Brown, ulf.hansson Cc: robh+dt, mark.rutland, linux-mmc, devicetree, linux-kernel On 23/09/16 23:01, Zach Brown wrote: > From: Chen Yee Chew <chen.yee.chew@ni.com> > > When the sd-broken-highspeed property is set the sdhci driver will not > go into highspeed mode even if the controller and card appear to > otherwise support highspeed mode. > > This is useful in cases where the controller and card support highspeed, > but the board configuration or some other issue make highspeed > impossible. > > Signed-off-by: Chen Yee Chew <chen.yee.chew@ni.com> > Reviewed-by: Keng Soon Cheah <keng.soon.cheah@ni.com> > Reviewed-by: Joe Hershberger <joe.hershberger@ni.com> > Signed-off-by: Zach Brown <zach.brown@ni.com> > --- > drivers/mmc/host/sdhci-pltfm.c | 3 +++ > drivers/mmc/host/sdhci.c | 3 ++- > drivers/mmc/host/sdhci.h | 2 ++ > 3 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c > index ad49bfa..7482706 100644 > --- a/drivers/mmc/host/sdhci-pltfm.c > +++ b/drivers/mmc/host/sdhci-pltfm.c > @@ -87,6 +87,9 @@ void sdhci_get_of_property(struct platform_device *pdev) > if (of_get_property(np, "broken-cd", NULL)) > host->quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION; > > + if (of_get_property(np, "sd-broken-highspeed", NULL)) > + host->quirks2 |= SDHCI_QUIRK2_BROKEN_HISPD; > + We don't really want new quirks. > if (of_get_property(np, "no-1-8-v", NULL)) > host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V; > > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c > index 4805566..4b0969c 100644 > --- a/drivers/mmc/host/sdhci.c > +++ b/drivers/mmc/host/sdhci.c > @@ -3274,7 +3274,8 @@ int sdhci_setup_host(struct sdhci_host *host) > if (host->quirks2 & SDHCI_QUIRK2_HOST_NO_CMD23) > mmc->caps &= ~MMC_CAP_CMD23; > > - if (host->caps & SDHCI_CAN_DO_HISPD) > + if ((host->caps & SDHCI_CAN_DO_HISPD) && > + !(host->quirks2 & SDHCI_QUIRK2_BROKEN_HISPD)) Is there any reason this can't just be: if ((host->caps & SDHCI_CAN_DO_HISPD) && !(of_property_read_bool(mmc_dev(mmc)->of_node, "broken-highspeed"))) AFAICT it does the right thing whether or not OF is configured or of_node is null. > mmc->caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED; > > if ((host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION) && > diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h > index c722cd2..3d0fdda 100644 > --- a/drivers/mmc/host/sdhci.h > +++ b/drivers/mmc/host/sdhci.h > @@ -424,6 +424,8 @@ struct sdhci_host { > #define SDHCI_QUIRK2_ACMD23_BROKEN (1<<14) > /* Broken Clock divider zero in controller */ > #define SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN (1<<15) > +/* Highspeed is broken even if it appears otherwise */ > +#define SDHCI_QUIRK2_BROKEN_HISPD (1<<16) > > int irq; /* Device IRQ */ > void __iomem *ioaddr; /* Mapped address */ > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC 2/2] sdhci: Prevent SD from doing highspeed timing when sd-broken-highspeed property is set @ 2016-10-06 6:39 ` Adrian Hunter 0 siblings, 0 replies; 19+ messages in thread From: Adrian Hunter @ 2016-10-06 6:39 UTC (permalink / raw) To: Zach Brown, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8, linux-mmc-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel-u79uwXL29TY76Z2rM5mHXA On 23/09/16 23:01, Zach Brown wrote: > From: Chen Yee Chew <chen.yee.chew-acOepvfBmUk@public.gmane.org> > > When the sd-broken-highspeed property is set the sdhci driver will not > go into highspeed mode even if the controller and card appear to > otherwise support highspeed mode. > > This is useful in cases where the controller and card support highspeed, > but the board configuration or some other issue make highspeed > impossible. > > Signed-off-by: Chen Yee Chew <chen.yee.chew-acOepvfBmUk@public.gmane.org> > Reviewed-by: Keng Soon Cheah <keng.soon.cheah-acOepvfBmUk@public.gmane.org> > Reviewed-by: Joe Hershberger <joe.hershberger-acOepvfBmUk@public.gmane.org> > Signed-off-by: Zach Brown <zach.brown-acOepvfBmUk@public.gmane.org> > --- > drivers/mmc/host/sdhci-pltfm.c | 3 +++ > drivers/mmc/host/sdhci.c | 3 ++- > drivers/mmc/host/sdhci.h | 2 ++ > 3 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c > index ad49bfa..7482706 100644 > --- a/drivers/mmc/host/sdhci-pltfm.c > +++ b/drivers/mmc/host/sdhci-pltfm.c > @@ -87,6 +87,9 @@ void sdhci_get_of_property(struct platform_device *pdev) > if (of_get_property(np, "broken-cd", NULL)) > host->quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION; > > + if (of_get_property(np, "sd-broken-highspeed", NULL)) > + host->quirks2 |= SDHCI_QUIRK2_BROKEN_HISPD; > + We don't really want new quirks. > if (of_get_property(np, "no-1-8-v", NULL)) > host->quirks2 |= SDHCI_QUIRK2_NO_1_8_V; > > diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c > index 4805566..4b0969c 100644 > --- a/drivers/mmc/host/sdhci.c > +++ b/drivers/mmc/host/sdhci.c > @@ -3274,7 +3274,8 @@ int sdhci_setup_host(struct sdhci_host *host) > if (host->quirks2 & SDHCI_QUIRK2_HOST_NO_CMD23) > mmc->caps &= ~MMC_CAP_CMD23; > > - if (host->caps & SDHCI_CAN_DO_HISPD) > + if ((host->caps & SDHCI_CAN_DO_HISPD) && > + !(host->quirks2 & SDHCI_QUIRK2_BROKEN_HISPD)) Is there any reason this can't just be: if ((host->caps & SDHCI_CAN_DO_HISPD) && !(of_property_read_bool(mmc_dev(mmc)->of_node, "broken-highspeed"))) AFAICT it does the right thing whether or not OF is configured or of_node is null. > mmc->caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED; > > if ((host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION) && > diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h > index c722cd2..3d0fdda 100644 > --- a/drivers/mmc/host/sdhci.h > +++ b/drivers/mmc/host/sdhci.h > @@ -424,6 +424,8 @@ struct sdhci_host { > #define SDHCI_QUIRK2_ACMD23_BROKEN (1<<14) > /* Broken Clock divider zero in controller */ > #define SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN (1<<15) > +/* Highspeed is broken even if it appears otherwise */ > +#define SDHCI_QUIRK2_BROKEN_HISPD (1<<16) > > int irq; /* Device IRQ */ > void __iomem *ioaddr; /* Mapped address */ > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2016-10-17 22:22 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-09-23 20:01 [RFC 0/2] Add device tree property and quirk for supporting sdhci Zach Brown 2016-09-23 20:01 ` Zach Brown 2016-09-23 20:01 ` [RFC 1/2] sdhci: Add device tree property sd-broken-highspeed Zach Brown 2016-10-03 17:37 ` Rob Herring 2016-10-03 17:37 ` Rob Herring 2016-10-05 18:33 ` Ulf Hansson 2016-10-05 20:03 ` Rob Herring 2016-10-05 21:22 ` Julia Cartwright 2016-10-05 21:22 ` Julia Cartwright 2016-10-06 1:34 ` Shawn Lin 2016-10-06 6:13 ` Adrian Hunter 2016-10-06 6:13 ` Adrian Hunter 2016-10-07 18:56 ` Zach Brown 2016-10-06 8:03 ` Ulf Hansson 2016-10-06 8:03 ` Ulf Hansson 2016-10-17 21:49 ` Zach Brown 2016-09-23 20:01 ` [RFC 2/2] sdhci: Prevent SD from doing highspeed timing when sd-broken-highspeed property is set Zach Brown 2016-10-06 6:39 ` Adrian Hunter 2016-10-06 6:39 ` Adrian Hunter
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.