Hi Ulf,

On Tue, Jun 16, 2015 at 6:31 AM, Ulf Hansson <ulf.hans...@linaro.org> wrote:

> I had a closer look, should have done that before.
>
> I think we need to decide what "no-1-8-v" should be used for.
> Currently the DT documentation is unclear and depending on what SDHCI
> variant, the binding has different purpose. It's a mess!

Thanks for your feedback.

>
> sdhci-pltfm + sdhci-esdhc-imx use the "no-1-8-v" DT binding to enable
> the SDHCI_QUIRK2_NO_1_8_V. The sdhci driver uses this quirk to mask
> the bus speed modes for SD UHS cards.
>
> In this regards, consider the two below options.
>
> 1) We have DT bindings for SD UHS speed modes, which somehow makes the
> "no-1-8-v" binding redundant (or deprecated).
>
> 2) If you can model the VCCQ power supply as as a regulator, you could
> use regulator_is_supported_voltage() API to find out similar
> information used to set SDHCI_QUIRK2_NO_1_8_V. In fact, sdhci already
> does that to mask MMC_CAP2_HSX00_1_2V, unless 1.2V is supported.
>
> In a third case, sdhci-pxav3 use the "no-1-8-v" DT binding to mask
> SDHCI_CAN_VDD_180/SDHCI_CAN_VDD_330, which seems wrong, as it has
> nothing to do with the power to the card (VMMC). It's also used it to
> mask MMC_CAP_1_8V_DDR.
>
> The summary, is that I would rather see us to move away from using the
> "no-1-8-v" DT binding and use the proper SD UHS bus speed modes
> binding instead.

Makes sense indeed.

The challenge here is that we still need to keep the old dtb's working.

Motivation for this patch was a custom mx6sl board that works fine
with 3.14, but after upgrading the kernel to 4.0 the eMMC no longer
can mount the rootfs. This is a regression caused by commit
312449efd16bb06, which applies 1.8V to the eMMC card that can only
operate at 3.3V.

Same thing happens on imx6q-sabresd: we have 3.3V voltage being
supplied to the eMMC, but now we are operating it at 1.8V, even though
if we have 'no-1-8-v' property in the device tree.

While I understand the need for improvement that you clearly
described, I would also like that the old dtb's could still work
'as-is' with a modern kernel.

The path I propose here was the minimal invasive method I could come
up to allow the old dtb compatibility.

Thanks,

Fabio Estevam
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to