BUG 4.4rc-4: wrong eMMC signaling voltage reported

DISCUSSION Holger Schurig 3 participants 6 messages Dec 9, 2015 – Dec 22, 2015 MMC, SD and SDIO

Share & tools

Holger Schurig

author

2015-12-09 14:53 UTC #0 lore raw

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";
};

Ulf Hansson

2015-12-17 16:10 UTC #1 lore raw

Quoted 21 lines · 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 */

Quoted 8 lines

&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

Holger Schurig

author

2015-12-22 08:33 UTC #2 lore raw

Quoted 8 lines

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.

Quoted 8 lines

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.

Quoted 5 lines

*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 ...).

Ulf Hansson

2015-12-22 09:18 UTC #3 lore raw

Quoted 26 lines · Holger Schurig

Quoted 8 lines
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.
Quoted 8 lines
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.
Quoted 5 lines
*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.

Quoted 8 lines

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! :-)

Quoted 3 lines

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.

Quoted 8 lines

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.

Quoted 3 lines

* 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

Fabio Estevam

2015-12-22 09:39 UTC #4 lore raw

In reply to Ulf Hansson

Hi Ulf and Holger,

Quoted 16 lines · Ulf Hansson

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.

Quoted 5 lines

*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

Ulf Hansson

2015-12-22 10:28 UTC #5 lore raw

Quoted 26 lines · Fabio Estevam

Hi Ulf and Holger,
Quoted 16 lines · Ulf Hansson
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.
Quoted 5 lines
*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.

Quoted 6 lines

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