BUG 4.4rc-4: wrong eMMC signaling voltage reported

BUG 4.4rc-4: wrong eMMC signaling voltage reported

[Holger Schurig]

Hi,

I have an i.MX6Q based system that cannot provide 1.8V voltage towards
the eMMC. But Linux 4.4-rc4 reports 1.8V for the eMMC, but this is
impossible. Neither my hardware allows this, nor does the DT say it.

root@imx6q:/sys/kernel/debug# cat mmc1/ios
clock:		52000000 Hz
actual clock:	49500000 Hz
vdd:		21 (3.3 ~ 3.4 V)
bus mode:	2 (push-pull)
chip select:	0 (don't care)
power mode:	2 (on)
bus width:	3 (8 bits)
timing spec:	8 (mmc DDR52)
signal voltage:	0 (1.80 V)
driver type:	0 (driver type B)

My device tree however tells that I don't have 1.8V:

/* this is the built in eMMC */
&usdhc4 {
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_usdhc4>;
	bus-width = <8>;
	non-removable;
	vmmc-supply = <&reg_3p3v>;
	max-frequency = <198000000>;
	no-1-8-v;
	status = "okay";
};




Fun fact: for the SDCARD things are correctly reported:

root@imx6q:/sys/kernel/debug# cat mmc1/ios
clock:		36000000 Hz
actual clock:	33000000 Hz
vdd:		21 (3.3 ~ 3.4 V)
bus mode:	2 (push-pull)
chip select:	0 (don't care)
power mode:	2 (on)
bus width:	2 (4 bits)
timing spec:	2 (sd high-speed)
signal voltage:	0 (3.30 V)
driver type:	0 (driver type B)

And here my device tree excerpt:

/* this is the SDCARD slot */
&usdhc2 {
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_usdhc2>;
	cd-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
	wp-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
	vmmc-supply = <&reg_3p3v>;
	max-frequency = <36000000>;
	no-1-8-v;
	status = "okay";
};

Re: BUG 4.4rc-4: wrong eMMC signaling voltage reported

[Ulf Hansson]

On 9 December 2015 at 15:53, Holger Schurig <holgerschurig@gmail.com> wrote:
> Hi,
>
> I have an i.MX6Q based system that cannot provide 1.8V voltage towards
> the eMMC. But Linux 4.4-rc4 reports 1.8V for the eMMC, but this is
> impossible. Neither my hardware allows this, nor does the DT say it.
>
> root@imx6q:/sys/kernel/debug# cat mmc1/ios
> clock:          52000000 Hz
> actual clock:   49500000 Hz
> vdd:            21 (3.3 ~ 3.4 V)
> bus mode:       2 (push-pull)
> chip select:    0 (don't care)
> power mode:     2 (on)
> bus width:      3 (8 bits)
> timing spec:    8 (mmc DDR52)
> signal voltage: 0 (1.80 V)
> driver type:    0 (driver type B)
>
> My device tree however tells that I don't have 1.8V:
>
> /* this is the built in eMMC */
> &usdhc4 {
>         pinctrl-names = "default";
>         pinctrl-0 = <&pinctrl_usdhc4>;
>         bus-width = <8>;
>         non-removable;
>         vmmc-supply = <&reg_3p3v>;
>         max-frequency = <198000000>;
>         no-1-8-v;

The no-1-8-v is a somewhat broken DT binding. I advise people to not
use any more.
Depending on the sdhci variant it have different meanings.

I guess you are using the sdhci-esdhc-imx variant, which means
no-1-8-v will disable UHS modes for SD-cards (those requiring 1.8V
signal voltage). It has no impact on (e)MMC.

As the host driver announces support for MMC_CAP_1_8V_DDR, that's what
the mmc core will try to use. Actually the mmc core will first try
1.8V and if it fails, go for 3.3V.

Likely, sdhci_do_start_signal_voltage_switch() will success to write
the corresponding registers to change the signal voltage to 1.8V,
which makes the mmc core believe it was a success.

*If* your statement around that your HW don't support 1.8V signal
voltage, we should perhaps add new mmc cap as currently we don't have
a "MMC_CAP_3_3V_DDR". Although, you need to convince on that, because
my experience tells that quite many has misunderstood the HW design in
this regard.

Kind regards
Uffe

Re: BUG 4.4rc-4: wrong eMMC signaling voltage reported

[Holger Schurig]

> The no-1-8-v is a somewhat broken DT binding. I advise people to not
> use any more.
> Depending on the sdhci variant it have different meanings.
>
> I guess you are using the sdhci-esdhc-imx variant, which means
> no-1-8-v will disable UHS modes for SD-cards (those requiring 1.8V
> signal voltage). It has no impact on (e)MMC.

Correct, I'm on i.MX6 and using sdhci-esdhc-imx.


> As the host driver announces support for MMC_CAP_1_8V_DDR, that's what
> the mmc core will try to use. Actually the mmc core will first try
> 1.8V and if it fails, go for 3.3V.
>
> Likely, sdhci_do_start_signal_voltage_switch() will success to write
> the corresponding registers to change the signal voltage to 1.8V,
> which makes the mmc core believe it was a success.
>
> *If* your statement around that your HW don't support 1.8V signal
> voltage, we should perhaps add new mmc cap as currently we don't have
> a "MMC_CAP_3_3V_DDR". Although, you need to convince on that, because
> my experience tells that quite many has misunderstood the HW design in
> this regard.

The hardware guys told me that the eMMC chip get's its power from the
i.MX6, there are connections NVCC_SD1...NVCC_SD3 which are directly
connected to 3V3, not to some PMIC. When I read the docs correctly, this
means that the SDHCI related I/O lines of the i.MX6 are therefore tied
to 3.3V only, because of this NVCC_SDx power domain.

And on the eMMC schematic page, the signals VCC and VCCQ ("DQ Power") of
the eMMC are also tied directly to 3.3V.

Therefore I assume that the hardware itself cannot provide 1.8V and I
added this "knowledge" to the Device Tree.




Two questions:

* should I propose a patch that reads theno-1-8-v setting from DT and
removes the announcement of MMC_CAP_1_8V_DDR ?

* isn't MMC_CAP_3_3V_DDR superfluous, because it must any implementation
must support 3.3V (I'm not too much into the standard ...).

Re: BUG 4.4rc-4: wrong eMMC signaling voltage reported

[Ulf Hansson]

On 22 December 2015 at 09:33, Holger Schurig <holgerschurig@gmail.com> wrote:
>
>> The no-1-8-v is a somewhat broken DT binding. I advise people to not
>> use any more.
>> Depending on the sdhci variant it have different meanings.
>>
>> I guess you are using the sdhci-esdhc-imx variant, which means
>> no-1-8-v will disable UHS modes for SD-cards (those requiring 1.8V
>> signal voltage). It has no impact on (e)MMC.
>
> Correct, I'm on i.MX6 and using sdhci-esdhc-imx.
>
>
>> As the host driver announces support for MMC_CAP_1_8V_DDR, that's what
>> the mmc core will try to use. Actually the mmc core will first try
>> 1.8V and if it fails, go for 3.3V.
>>
>> Likely, sdhci_do_start_signal_voltage_switch() will success to write
>> the corresponding registers to change the signal voltage to 1.8V,
>> which makes the mmc core believe it was a success.
>>
>> *If* your statement around that your HW don't support 1.8V signal
>> voltage, we should perhaps add new mmc cap as currently we don't have
>> a "MMC_CAP_3_3V_DDR". Although, you need to convince on that, because
>> my experience tells that quite many has misunderstood the HW design in
>> this regard.
>
> The hardware guys told me that the eMMC chip get's its power from the
> i.MX6, there are connections NVCC_SD1...NVCC_SD3 which are directly
> connected to 3V3, not to some PMIC. When I read the docs correctly, this
> means that the SDHCI related I/O lines of the i.MX6 are therefore tied
> to 3.3V only, because of this NVCC_SDx power domain.
>
> And on the eMMC schematic page, the signals VCC and VCCQ ("DQ Power") of
> the eMMC are also tied directly to 3.3V.

Thanks, I am convinced! :-)

>
> Therefore I assume that the hardware itself cannot provide 1.8V and I
> added this "knowledge" to the Device Tree.

The problem with the "no-1-8-v" binding is that it's describing what
the hardware *can't* do. It thus becomes easy to abuse it.

I suggest we stop using it, we should mark it deprecated.

>
>
>
>
> Two questions:
>
> * should I propose a patch that reads theno-1-8-v setting from DT and
> removes the announcement of MMC_CAP_1_8V_DDR ?

No.

>
> * isn't MMC_CAP_3_3V_DDR superfluous, because it must any implementation
> must support 3.3V (I'm not too much into the standard ...).

For eMMC it's acceptable to support any of the 3.3V or 1.8V as the
only supported signal voltage.

However, for the old MMC standard this isn't the case and that also
true for UHS SD cards.

So, I suggest we add this new cap and a corresponding DT binding that
we parse in the mmc_of_parse() function.

Whether you should drop the announcement of MMC_CAP_1_8V_DDR, I don't
know as it seems like it would affect more than imx6. Something more
clever is needed there I think.

Kind regards
Uffe

Re: BUG 4.4rc-4: wrong eMMC signaling voltage reported

[Fabio Estevam]

Hi Ulf and Holger,

On Thu, Dec 17, 2015 at 2:10 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:

> The no-1-8-v is a somewhat broken DT binding. I advise people to not
> use any more.
> Depending on the sdhci variant it have different meanings.
>
> I guess you are using the sdhci-esdhc-imx variant, which means
> no-1-8-v will disable UHS modes for SD-cards (those requiring 1.8V
> signal voltage). It has no impact on (e)MMC.
>
> As the host driver announces support for MMC_CAP_1_8V_DDR, that's what
> the mmc core will try to use. Actually the mmc core will first try
> 1.8V and if it fails, go for 3.3V.
>
> Likely, sdhci_do_start_signal_voltage_switch() will success to write
> the corresponding registers to change the signal voltage to 1.8V,
> which makes the mmc core believe it was a success.
>
> *If* your statement around that your HW don't support 1.8V signal
> voltage, we should perhaps add new mmc cap as currently we don't have
> a "MMC_CAP_3_3V_DDR". Although, you need to convince on that, because
> my experience tells that quite many has misunderstood the HW design in
> this regard.

Yes, I have added a 'MMC_CAP_3_3V_ONLY_DDR' in this proposal to fix
the same issue as Holger describes:
http://www.spinics.net/lists/linux-mmc/msg32285.html

,but it seems you were not happy with such approach at that time.
Unfortunately, I was not able to rework it.

Regards,

Fabio Estevam

Re: BUG 4.4rc-4: wrong eMMC signaling voltage reported

[Ulf Hansson]

On 22 December 2015 at 10:39, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Ulf and Holger,
>
> On Thu, Dec 17, 2015 at 2:10 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
>> The no-1-8-v is a somewhat broken DT binding. I advise people to not
>> use any more.
>> Depending on the sdhci variant it have different meanings.
>>
>> I guess you are using the sdhci-esdhc-imx variant, which means
>> no-1-8-v will disable UHS modes for SD-cards (those requiring 1.8V
>> signal voltage). It has no impact on (e)MMC.
>>
>> As the host driver announces support for MMC_CAP_1_8V_DDR, that's what
>> the mmc core will try to use. Actually the mmc core will first try
>> 1.8V and if it fails, go for 3.3V.
>>
>> Likely, sdhci_do_start_signal_voltage_switch() will success to write
>> the corresponding registers to change the signal voltage to 1.8V,
>> which makes the mmc core believe it was a success.
>>
>> *If* your statement around that your HW don't support 1.8V signal
>> voltage, we should perhaps add new mmc cap as currently we don't have
>> a "MMC_CAP_3_3V_DDR". Although, you need to convince on that, because
>> my experience tells that quite many has misunderstood the HW design in
>> this regard.
>
> Yes, I have added a 'MMC_CAP_3_3V_ONLY_DDR' in this proposal to fix
> the same issue as Holger describes:
> http://www.spinics.net/lists/linux-mmc/msg32285.html
>
> ,but it seems you were not happy with such approach at that time.
> Unfortunately, I was not able to rework it.

Yes, I had vague memory of this discussion. Thanks for pointing it out.

So, I think I am reaching the same consensus again. We need to move
away from using the no-1.8-v, and thus not add any new interpretation
of that binding.

I think what I suggested as the solution here should work, right!?

I understand the problem with keeping DTB backwards compatible, don't
you think sdhci-esdhc-imx can handle that internally via using a
MMC_CAP_3_3V_DDR?

Kind regards
Uffe