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@xxxxxxxxxx> wrote:
On 23 September 2016 at 22:01, Zach Brown <zach.brown@xxxxxx> 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
The sd-broken-highspeed property will let the sdhci driver know that
highspeed will not work.
Signed-off-by: Zach Brown <zach.brown@xxxxxx>
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
@@ -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
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html