ARM: tegra: beaver: allow SD card voltage to be changed

This allows to switch the card signal voltage level to 1.8V, which is needed for any ultra high speed modes to work.

Signed-off-by Lucas Stach <[email protected]>

---
This needs the SDMMC memcomp pad calibration patches I just sent out to be applied, otherwise the card voltage change will fail with a message in the kernel log and a fall back to high speed operation.

---
?arch/arm/boot/dts/tegra30-beaver.dts | 3 ++-
?1 file changed, 2 insertions(+), 1 deletion(-)

arch/arm/boot/dts/tegra30-beaver.dts +0 -0

index 1daed40..6b237f2 100644
@@ -1848,7 +1848,7 @@

?
? ldo5_reg: ldo5 {
? regulator-name =
"vddio_sdmmc,avdd_vdac";

arch/arm/boot/dts/tegra30-beaver.dts +0 -1

-					regulator-min-microvolt =

<3300000>;

arch/arm/boot/dts/tegra30-beaver.dts +1 -0

+					regulator-min-microvolt =

<1800000>;
? regulator-max-microvolt =
<3300000>;
? regulator-always-on;
? };

arch/arm/boot/dts/tegra30-beaver.dts +0 -0

@@ -1919,6 +1919,7 @@

?
? sdhci at 78000000 {
? status = "okay";

arch/arm/boot/dts/tegra30-beaver.dts +1 -0

+		vqmmc-supply = <&ldo5_reg>;

? cd-gpios = <&gpio TEGRA_GPIO(I, 5) GPIO_ACTIVE_LOW>;
? wp-gpios = <&gpio TEGRA_GPIO(T, 3)
GPIO_ACTIVE_HIGH>;
? power-gpios = <&gpio TEGRA_GPIO(D, 7)
GPIO_ACTIVE_HIGH>;

Am Montag, den 29.02.2016, 22:01 +0100 schrieb Lucas Stach:

Quoted 9 lines

This allows to switch the card signal voltage level to 1.8V, which is needed for any ultra high speed modes to work.

Signed-off-by Lucas Stach <[email protected]>

---
This needs the SDMMC memcomp pad calibration patches I just sent out to be applied, otherwise the card voltage change will fail with a message in the kernel log and a fall back to high speed operation.

The patches this one depends on have been applied for some time now. Please pick up this patch.

Quoted 12 lines

Am Montag, den 29.02.2016, 22:01 +0100 schrieb Lucas Stach:

Quoted 10 lines

This allows to switch the card signal voltage level to 1.8V, which is needed for any ultra high speed modes to work.

Signed-off-by Lucas Stach <[email protected]>

---
This needs the SDMMC memcomp pad calibration patches I just sent out to be applied, otherwise the card voltage change will fail with a message in the kernel log and a fall back to high speed operation.

Quoted 3 lines

The patches this one depends on have been applied for some time now.
Please pick up this patch.

My understanding is that UHS modes currently cause problems on Beaver.
What I don't understand about that is how it will even try those modes
if the voltage regulator can't be set to 1.8 V? Shouldn't that actively
prevent those modes from even being attempted?

* PGP Signed by an unknown key

Quoted 11 lines · Lucas Stach

Am Montag, den 29.02.2016, 22:01 +0100 schrieb Lucas Stach:

Quoted 9 lines

This allows to switch the card signal voltage level to 1.8V, which is needed for any ultra high speed modes to work.

Signed-off-by Lucas Stach <[email protected]>

---
This needs the SDMMC memcomp pad calibration patches I just sent out to be applied, otherwise the card voltage change will fail with a message in the kernel log and a fall back to high speed operation.

Quoted 2 lines

The patches this one depends on have been applied for some time now. Please pick up this patch.

My understanding is that UHS modes currently cause problems on Beaver. What I don't understand about that is how it will even try those modes if the voltage regulator can't be set to 1.8 V? Shouldn't that actively prevent those modes from even being attempted?

Quoted 14 lines · Thierry Reding

* PGP Signed by an unknown key

Quoted 11 lines · Lucas Stach

Am Montag, den 29.02.2016, 22:01 +0100 schrieb Lucas Stach:

Quoted 9 lines

This allows to switch the card signal voltage level to 1.8V, which is needed for any ultra high speed modes to work.

Signed-off-by Lucas Stach <[email protected]>

---
This needs the SDMMC memcomp pad calibration patches I just sent out to be applied, otherwise the card voltage change will fail with a message in the kernel log and a fall back to high speed operation.

Quoted 7 lines

Quoted 2 lines

The patches this one depends on have been applied for some time now. Please pick up this patch.

My understanding is that UHS modes currently cause problems on Beaver. What I don't understand about that is how it will even try those modes if the voltage regulator can't be set to 1.8 V? Shouldn't that actively prevent those modes from even being attempted?

Looking at the sdhci code, if the regulator is missing then we still attempt to place the controller is 1.8V mode ...

static int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
struct mmc_ios *ios)
{

...

         case MMC_SIGNAL_VOLTAGE_180:
                 if (!IS_ERR(mmc->supply.vqmmc)) {
                         ret = regulator_set_voltage(mmc->supply.vqmmc,
                                         1700000, 1950000);
                         if (ret) {
                                 pr_warn("%s: Switching to 1.8V signalling voltage failed\n",
                                         mmc_hostname(mmc));
                                 return -EIO;
                         }
                 }

                 /*
                  * Enable 1.8V Signal Enable in the Host Control2
                  * register
                  */
                 ctrl |= SDHCI_CTRL_VDD_180;
                 sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
 
                 /* Some controller need to do more when switching */
                 if (host->ops->voltage_switch)
                         host->ops->voltage_switch(host);
 
                 /* 1.8V regulator output should be stable within 5 ms */
                 ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
                 if (ctrl & SDHCI_CTRL_VDD_180)
                         return 0;
 
                 pr_warn("%s: 1.8V regulator output did not became stable\n",
                         mmc_hostname(mmc));
 
                 return -EAGAIN;

Ideally, the above *should* fail if the regulator is missing. However, what I have found, is that in my case, even though the regulator is missing, the above succeeds and the host thinks we are operating at 1.8V even though we are still at 3.3V! It seems that this does not happen with all SD cards that support UHS.

This patch resolves the problems I am seeing on beaver with SD card initialisation failing. I am surprised this is not causing problems for others?

Adding Adrian and Ulf ...

Quoted 71 lines · Jon Hunter

Quoted 14 lines · Thierry Reding

* PGP Signed by an unknown key

Quoted 11 lines · Lucas Stach

Am Montag, den 29.02.2016, 22:01 +0100 schrieb Lucas Stach:

Quoted 9 lines

This allows to switch the card signal voltage level to 1.8V, which is needed for any ultra high speed modes to work.

Signed-off-by Lucas Stach <[email protected]>

---
This needs the SDMMC memcomp pad calibration patches I just sent out to be applied, otherwise the card voltage change will fail with a message in the kernel log and a fall back to high speed operation.

Quoted 7 lines

Quoted 2 lines

The patches this one depends on have been applied for some time now. Please pick up this patch.

My understanding is that UHS modes currently cause problems on Beaver. What I don't understand about that is how it will even try those modes if the voltage regulator can't be set to 1.8 V? Shouldn't that actively prevent those modes from even being attempted?

Looking at the sdhci code, if the regulator is missing then we still attempt to place the controller is 1.8V mode ...

static int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
struct mmc_ios *ios)
{

...

         case MMC_SIGNAL_VOLTAGE_180:
                 if (!IS_ERR(mmc->supply.vqmmc)) {
                         ret = regulator_set_voltage(mmc->supply.vqmmc,
                                         1700000, 1950000);
                         if (ret) {
                                 pr_warn("%s: Switching to 1.8V signalling voltage failed\n",
                                         mmc_hostname(mmc));
                                 return -EIO;
                         }
                 }

                 /*
                  * Enable 1.8V Signal Enable in the Host Control2
                  * register
                  */
                 ctrl |= SDHCI_CTRL_VDD_180;
                 sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
 
                 /* Some controller need to do more when switching */
                 if (host->ops->voltage_switch)
                         host->ops->voltage_switch(host);
 
                 /* 1.8V regulator output should be stable within 5 ms */
                 ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
                 if (ctrl & SDHCI_CTRL_VDD_180)
                         return 0;
 
                 pr_warn("%s: 1.8V regulator output did not became stable\n",
                         mmc_hostname(mmc));
 
                 return -EAGAIN;

Ideally, the above *should* fail if the regulator is missing. However, what I have found, is that in my case, even though the regulator is missing, the above succeeds and the host thinks we are operating at 1.8V even though we are still at 3.3V! It seems that this does not happen with all SD cards that support UHS.

Quoted 3 lines

This patch resolves the problems I am seeing on beaver with SD card initialisation failing. I am surprised this is not causing problems for others?

Adrian, Ulf, per the above, I have found that on a Tegra30 beaver board, if we enable UHS-I modes for Tegra30 but the device-tree for the board is missing the regulator to select 1.8V mode operation, then the above code sequence may still return success (ie. SDHCI_CTRL_VDD_180 bit is set in SDHCI_HOST_CONTROL2) even though we have not changed the voltage. This leads to other problems later on during SD initialisation.

Would you expect that an SDHCI controller should fail to set the SDHCI_CTRL_VDD_180 bit in the SDHCI_HOST_CONTROL2 register if we did not change the voltage?

We want to ensure that Tegra devices do not attempt to switch the UHS-I modes if the regulator is not present and it is not clear to me if there is a problem with the Tegra SDHCI controller or how this should be handled.

Quoted 85 lines · Jon Hunter

Adding Adrian and Ulf ...

Quoted 71 lines · Jon Hunter

Quoted 14 lines · Thierry Reding

* PGP Signed by an unknown key

Quoted 11 lines · Lucas Stach

Am Montag, den 29.02.2016, 22:01 +0100 schrieb Lucas Stach:

Quoted 9 lines

This allows to switch the card signal voltage level to 1.8V, which is needed for any ultra high speed modes to work.

Signed-off-by Lucas Stach <[email protected]>

---
This needs the SDMMC memcomp pad calibration patches I just sent out to be applied, otherwise the card voltage change will fail with a message in the kernel log and a fall back to high speed operation.

Quoted 7 lines

Quoted 2 lines

The patches this one depends on have been applied for some time now. Please pick up this patch.

My understanding is that UHS modes currently cause problems on Beaver. What I don't understand about that is how it will even try those modes if the voltage regulator can't be set to 1.8 V? Shouldn't that actively prevent those modes from even being attempted?

Looking at the sdhci code, if the regulator is missing then we still attempt to place the controller is 1.8V mode ...

static int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
struct mmc_ios *ios)
{

...

         case MMC_SIGNAL_VOLTAGE_180:
                 if (!IS_ERR(mmc->supply.vqmmc)) {
                         ret = regulator_set_voltage(mmc->supply.vqmmc,
                                         1700000, 1950000);
                         if (ret) {
                                 pr_warn("%s: Switching to 1.8V signalling voltage failed\n",
                                         mmc_hostname(mmc));
                                 return -EIO;
                         }
                 }

                 /*
                  * Enable 1.8V Signal Enable in the Host Control2
                  * register
                  */
                 ctrl |= SDHCI_CTRL_VDD_180;
                 sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
 
                 /* Some controller need to do more when switching */
                 if (host->ops->voltage_switch)
                         host->ops->voltage_switch(host);
 
                 /* 1.8V regulator output should be stable within 5 ms */
                 ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
                 if (ctrl & SDHCI_CTRL_VDD_180)
                         return 0;
 
                 pr_warn("%s: 1.8V regulator output did not became stable\n",
                         mmc_hostname(mmc));
 
                 return -EAGAIN;

Ideally, the above *should* fail if the regulator is missing. However, what I have found, is that in my case, even though the regulator is missing, the above succeeds and the host thinks we are operating at 1.8V even though we are still at 3.3V! It seems that this does not happen with all SD cards that support UHS.

Quoted 3 lines

This patch resolves the problems I am seeing on beaver with SD card initialisation failing. I am surprised this is not causing problems for others?

Adrian, Ulf, per the above, I have found that on a Tegra30 beaver board, if we enable UHS-I modes for Tegra30 but the device-tree for the board is missing the regulator to select 1.8V mode operation, then the above code sequence may still return success (ie. SDHCI_CTRL_VDD_180 bit is set in SDHCI_HOST_CONTROL2) even though we have not changed the voltage. This leads to other problems later on during SD initialisation.

Quoted 3 lines

Would you expect that an SDHCI controller should fail to set the SDHCI_CTRL_VDD_180 bit in the SDHCI_HOST_CONTROL2 register if we did not change the voltage?

What is meant to happen is that sdhci should wait 5ms and then check SDHCI_CTRL_VDD_180 - which it used to do but then someone took the 5ms wait away.

In any case, if you are using a regulator there is no knowing what sdhci is meant to do.

Quoted 4 lines

We want to ensure that Tegra devices do not attempt to switch the UHS-I modes if the regulator is not present and it is not clear to me if there is a problem with the Tegra SDHCI controller or how this should be handled.

If the driver doesn't support UHS-I modes then it must remove the cap flags.

Quoted 90 lines · Adrian Hunter

Quoted 88 lines · Jon Hunter

Adding Adrian and Ulf ...

Quoted 71 lines · Jon Hunter

Quoted 14 lines · Thierry Reding

* PGP Signed by an unknown key

Quoted 11 lines · Lucas Stach

Am Montag, den 29.02.2016, 22:01 +0100 schrieb Lucas Stach:

Quoted 9 lines

This allows to switch the card signal voltage level to 1.8V, which is needed for any ultra high speed modes to work.

Signed-off-by Lucas Stach <[email protected]>

---
This needs the SDMMC memcomp pad calibration patches I just sent out to be applied, otherwise the card voltage change will fail with a message in the kernel log and a fall back to high speed operation.

Quoted 7 lines

Quoted 2 lines

The patches this one depends on have been applied for some time now. Please pick up this patch.

My understanding is that UHS modes currently cause problems on Beaver. What I don't understand about that is how it will even try those modes if the voltage regulator can't be set to 1.8 V? Shouldn't that actively prevent those modes from even being attempted?

Looking at the sdhci code, if the regulator is missing then we still attempt to place the controller is 1.8V mode ...

static int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
struct mmc_ios *ios)
{

...

         case MMC_SIGNAL_VOLTAGE_180:
                 if (!IS_ERR(mmc->supply.vqmmc)) {
                         ret = regulator_set_voltage(mmc->supply.vqmmc,
                                         1700000, 1950000);
                         if (ret) {
                                 pr_warn("%s: Switching to 1.8V signalling voltage failed\n",
                                         mmc_hostname(mmc));
                                 return -EIO;
                         }
                 }

                 /*
                  * Enable 1.8V Signal Enable in the Host Control2
                  * register
                  */
                 ctrl |= SDHCI_CTRL_VDD_180;
                 sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
 
                 /* Some controller need to do more when switching */
                 if (host->ops->voltage_switch)
                         host->ops->voltage_switch(host);
 
                 /* 1.8V regulator output should be stable within 5 ms */
                 ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
                 if (ctrl & SDHCI_CTRL_VDD_180)
                         return 0;
 
                 pr_warn("%s: 1.8V regulator output did not became stable\n",
                         mmc_hostname(mmc));
 
                 return -EAGAIN;

Ideally, the above *should* fail if the regulator is missing. However, what I have found, is that in my case, even though the regulator is missing, the above succeeds and the host thinks we are operating at 1.8V even though we are still at 3.3V! It seems that this does not happen with all SD cards that support UHS.

Quoted 3 lines

This patch resolves the problems I am seeing on beaver with SD card initialisation failing. I am surprised this is not causing problems for others?

Adrian, Ulf, per the above, I have found that on a Tegra30 beaver board, if we enable UHS-I modes for Tegra30 but the device-tree for the board is missing the regulator to select 1.8V mode operation, then the above code sequence may still return success (ie. SDHCI_CTRL_VDD_180 bit is set in SDHCI_HOST_CONTROL2) even though we have not changed the voltage. This leads to other problems later on during SD initialisation.

Would you expect that an SDHCI controller should fail to set the SDHCI_CTRL_VDD_180 bit in the SDHCI_HOST_CONTROL2 register if we did not change the voltage?

Quoted 3 lines

What is meant to happen is that sdhci should wait 5ms and then check SDHCI_CTRL_VDD_180 - which it used to do but then someone took the 5ms wait away.

Do you plan to add the 5ms delay again?

Quoted 3 lines

In any case, if you are using a regulator there is no knowing what sdhci is meant to do.

Ok, seems fragile.

Quoted 6 lines

Quoted 5 lines

We want to ensure that Tegra devices do not attempt to switch the UHS-I modes if the regulator is not present and it is not clear to me if there is a problem with the Tegra SDHCI controller or how this should be handled.

Quoted 1 line

If the driver doesn't support UHS-I modes then it must remove the cap flags.

So the controller itself supports UHS-I modes, but a given board may not have the regulator to support them. We need a way to determine if the board can support the UHS-I modes. Now we could check to see if the regulator is present in the Tegra SDHCI driver and if not remove the cap flags. However, I was not sure if this is applicable to other sdhci controllers and so there should be a generic solution for this?

Quoted 92 lines · Jon Hunter

Quoted 90 lines · Adrian Hunter

Quoted 88 lines · Jon Hunter

Adding Adrian and Ulf ...

Quoted 71 lines · Jon Hunter

Quoted 14 lines · Thierry Reding

* PGP Signed by an unknown key

Quoted 11 lines · Lucas Stach

Am Montag, den 29.02.2016, 22:01 +0100 schrieb Lucas Stach:

Quoted 9 lines

This allows to switch the card signal voltage level to 1.8V, which is needed for any ultra high speed modes to work.

Signed-off-by Lucas Stach <[email protected]>

---
This needs the SDMMC memcomp pad calibration patches I just sent out to be applied, otherwise the card voltage change will fail with a message in the kernel log and a fall back to high speed operation.

Quoted 7 lines

Quoted 2 lines

The patches this one depends on have been applied for some time now. Please pick up this patch.

My understanding is that UHS modes currently cause problems on Beaver. What I don't understand about that is how it will even try those modes if the voltage regulator can't be set to 1.8 V? Shouldn't that actively prevent those modes from even being attempted?

Looking at the sdhci code, if the regulator is missing then we still attempt to place the controller is 1.8V mode ...

static int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
struct mmc_ios *ios)
{

...

         case MMC_SIGNAL_VOLTAGE_180:
                 if (!IS_ERR(mmc->supply.vqmmc)) {
                         ret = regulator_set_voltage(mmc->supply.vqmmc,
                                         1700000, 1950000);
                         if (ret) {
                                 pr_warn("%s: Switching to 1.8V signalling voltage failed\n",
                                         mmc_hostname(mmc));
                                 return -EIO;
                         }
                 }

                 /*
                  * Enable 1.8V Signal Enable in the Host Control2
                  * register
                  */
                 ctrl |= SDHCI_CTRL_VDD_180;
                 sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
 
                 /* Some controller need to do more when switching */
                 if (host->ops->voltage_switch)
                         host->ops->voltage_switch(host);
 
                 /* 1.8V regulator output should be stable within 5 ms */
                 ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
                 if (ctrl & SDHCI_CTRL_VDD_180)
                         return 0;
 
                 pr_warn("%s: 1.8V regulator output did not became stable\n",
                         mmc_hostname(mmc));
 
                 return -EAGAIN;

Ideally, the above *should* fail if the regulator is missing. However, what I have found, is that in my case, even though the regulator is missing, the above succeeds and the host thinks we are operating at 1.8V even though we are still at 3.3V! It seems that this does not happen with all SD cards that support UHS.

Quoted 3 lines

This patch resolves the problems I am seeing on beaver with SD card initialisation failing. I am surprised this is not causing problems for others?

Adrian, Ulf, per the above, I have found that on a Tegra30 beaver board, if we enable UHS-I modes for Tegra30 but the device-tree for the board is missing the regulator to select 1.8V mode operation, then the above code sequence may still return success (ie. SDHCI_CTRL_VDD_180 bit is set in SDHCI_HOST_CONTROL2) even though we have not changed the voltage. This leads to other problems later on during SD initialisation.

Would you expect that an SDHCI controller should fail to set the SDHCI_CTRL_VDD_180 bit in the SDHCI_HOST_CONTROL2 register if we did not change the voltage?

Quoted 5 lines

Quoted 3 lines

What is meant to happen is that sdhci should wait 5ms and then check SDHCI_CTRL_VDD_180 - which it used to do but then someone took the 5ms wait away.

Do you plan to add the 5ms delay again?

I guess the assumption is the card will fail to switch voltage, so the check is unnecessary.

Quoted 1 line

Quoted 4 lines

Quoted 2 lines

In any case, if you are using a regulator there is no knowing what sdhci is meant to do.

Ok, seems fragile.

In what way.

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

We want to ensure that Tegra devices do not attempt to switch the UHS-I modes if the regulator is not present and it is not clear to me if there is a problem with the Tegra SDHCI controller or how this should be handled.

Quoted 8 lines

Quoted 1 line

If the driver doesn't support UHS-I modes then it must remove the cap flags.

So the controller itself supports UHS-I modes, but a given board may not have the regulator to support them. We need a way to determine if the board can support the UHS-I modes. Now we could check to see if the regulator is present in the Tegra SDHCI driver and if not remove the cap flags. However, I was not sure if this is applicable to other sdhci controllers and so there should be a generic solution for this?

There is SDHCI_QUIRK2_NO_1_8_V but it doesn't cover the eMMC 1.8V DDR52 case at present. Dong Aisheng wanted to plug that gap but I wanted to get rid of SDHCI_QUIRK2_NO_1_8_V:

	http://marc.info/?l=linux-mmc&m=146132847206423&w=2

Quoted 11 lines

Quoted 6 lines

So the controller itself supports UHS-I modes, but a given board may not have the regulator to support them. We need a way to determine if the board can support the UHS-I modes. Now we could check to see if the regulator is present in the Tegra SDHCI driver and if not remove the cap flags. However, I was not sure if this is applicable to other sdhci controllers and so there should be a generic solution for this?

There is SDHCI_QUIRK2_NO_1_8_V but it doesn't cover the eMMC 1.8V DDR52 case at present. Dong Aisheng wanted to plug that gap but I wanted to get rid of SDHCI_QUIRK2_NO_1_8_V:

Quoted 1 line

	http://marc.info/?l=linux-mmc&m=146132847206423&w=2

Ok, that would require the tegra sdhci driver to set this quirk for a board, which is do-able, I guess. However, given the above I am not sure what path you are suggesting we take to resolve this? Does not sound like we should be looking at using SDHCI_QUIRK2_NO_1_8_V anyway.

Hi Adrian,

On 14/06/16 15:19, Jon Hunter wrote:

...

Quoted 13 lines

Quoted 12 lines

Quoted 6 lines

So the controller itself supports UHS-I modes, but a given board may not have the regulator to support them. We need a way to determine if the board can support the UHS-I modes. Now we could check to see if the regulator is present in the Tegra SDHCI driver and if not remove the cap flags. However, I was not sure if this is applicable to other sdhci controllers and so there should be a generic solution for this?

There is SDHCI_QUIRK2_NO_1_8_V but it doesn't cover the eMMC 1.8V DDR52 case at present. Dong Aisheng wanted to plug that gap but I wanted to get rid of SDHCI_QUIRK2_NO_1_8_V:

	http://marc.info/?l=linux-mmc&m=146132847206423&w=2

Quoted 4 lines

Ok, that would require the tegra sdhci driver to set this quirk for a board, which is do-able, I guess. However, given the above I am not sure what path you are suggesting we take to resolve this? Does not sound like we should be looking at using SDHCI_QUIRK2_NO_1_8_V anyway.

Any feedback here? Are you still planning to get rid of SDHCI_QUIRK2_NO_1_8_V or should we use this?

This allows to switch the card signal voltage level to 1.8V, which is needed for any ultra high speed modes to work.

Signed-off-by Lucas Stach <[email protected]>

---
This needs the SDMMC memcomp pad calibration patches I just sent out to be applied, otherwise the card voltage change will fail with a message in the kernel log and a fall back to high speed operation.

---
 arch/arm/boot/dts/tegra30-beaver.dts | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

arch/arm/boot/dts/tegra30-beaver.dts +0 -0

index 1daed40..6b237f2 100644

arch/arm/boot/dts/tegra30-beaver.dts +1 -1

-					regulator-min-microvolt = <3300000>;
+					regulator-min-microvolt = <1800000>;
 					regulator-max-microvolt = <3300000>;
 					regulator-always-on;
 				};

Quoted 19 lines · Lucas Stach

This allows to switch the card signal voltage level to 1.8V, which is needed for any ultra high speed modes to work.

Signed-off-by Lucas Stach <[email protected]>

---
This needs the SDMMC memcomp pad calibration patches I just sent out to be applied, otherwise the card voltage change will fail with a message in the kernel log and a fall back to high speed operation.

---
  arch/arm/boot/dts/tegra30-beaver.dts | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

arch/arm/boot/dts/tegra30-beaver.dts +0 -0

index 1daed40..6b237f2 100644
@@ -1848,7 +1848,7 @@
 

arch/arm/boot/dts/tegra30-beaver.dts line 1850

Quoted 2 lines

arch/arm/boot/dts/tegra30-beaver.dts +0 -0

  				ldo5_reg: ldo5 {
  					regulator-name = "vddio_sdmmc,avdd_vdac";

Stephen, looking at the schematics, I don't see that this is connected to the avdd_vdac (which appears to be unconnected) and so I am wondering if this name should be just "vddio_sdmmc"?