[PATCH 1/2] mmc: Add support for Signal (vccq) Voltage Switching using Regulators
From: Philip Rakity
The SD Host Controller may require a regulator to support signal
and voltage switching. Curently we support voltage (vmmc) but not
signal changing via a regulator. Add this support.
If a regulator is supported and voltage switching to 1.8V is
supported then use the vmmc regulator to disable the voltage to
the core if 1.8 signal voltage switching fails.
Signed-off-by: Philip Rakity
---
drivers/mmc/host/sdhci.c | 88 ++---
include/linux/mmc/sdhci.h |3 +-
2 files changed, 69 insertions(+), 22 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 417851f..248f68b 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1584,6 +1584,7 @@ static int sdhci_do_start_signal_voltage_switch(struct
sdhci_host *host,
u8 pwr;
u16 clk, ctrl;
u32 present_state;
+ int ret;
/*
* Signal Voltage Switching is only applicable for Host Controllers
@@ -1604,6 +1605,15 @@ static int sdhci_do_start_signal_voltage_switch(struct
sdhci_host *host,
/* Wait for 5ms */
usleep_range(5000, 5500);
+ if (host->vmmcvccq) {
+ ret = regulator_set_voltage(host->vmmcvccq,
+ 330, 330);
+ if (ret) {
+ pr_info(DRIVER_NAME ": Switching to 3.3V "
+ "signalling voltage failed\n");
+ return -EIO;
+ }
+ }
/* 3.3V regulator output should be stable within 5 ms */
ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
@@ -1629,29 +1639,43 @@ static int sdhci_do_start_signal_voltage_switch(struct
sdhci_host *host,
* Enable 1.8V Signal Enable in the Host Control2
* register
*/
- ctrl |= SDHCI_CTRL_VDD_180;
- sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
-
- /* Wait for 5ms */
- usleep_range(5000, 5500);
-
- ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
- if (ctrl & SDHCI_CTRL_VDD_180) {
- /* Provide SDCLK again and wait for 1ms*/
- clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
- clk |= SDHCI_CLOCK_CARD_EN;
- sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
- usleep_range(1000, 1500);
+ ret = 0;
+ if (host->vmmcvccq) {
+ ret = regulator_set_voltage(host->vmmcvccq,
+ 180, 180);
+ }
- /*
-* If DAT[3:0] level is b, then the card
-* was successfully switched to 1.8V signaling.
-*/
- present_state = sdhci_readl(host,
+ if (!ret) {
+ ctrl |= SDHCI_CTRL_VDD_180;
+ sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
+
+ /* Wait for 5ms */
+ usleep_range(5000, 5500);
+
+ ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+ if (ctrl & SDHCI_CTRL_VDD_180) {
+ /* Provide SDCLK again */
+ /* and wait for 1ms*/
+ clk = sdhci_readw(host,
+ SDHCI_CLOCK_CONTROL);
+ clk |= SDHCI_CLOCK_CARD_EN;
+ sdhci_writew(host, clk,
+ SDHCI_CLOCK_CONTROL);
+ usleep_range(1000, 1500);
+
+ /*
+* If DAT[3:0] level is b,
+* then the card
+* was successfully switched
+* to 1.8V signaling.
+*/
+ present_state = sdhci_readl(host,
SDHCI_PRESENT_STATE);
- if ((present_state & SDHCI_DATA_LVL_MASK) ==
-SDHCI_DATA_LVL_MASK)
- return 0;
+ if ((present_state &
+ SDHCI_DATA_LVL_MASK) ==
[PATCH 2/2] mmc: only support voltage (vdd) that regulator agree's with
From: Philip Rakity
If we are using a regulator the SD Host Controller and the
regulator should agree about the voltages supported. Use
the common subset that is supported.
Signed-off-by: Philip Rakity
---
drivers/mmc/host/sdhci.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 248f68b..78be427 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2894,6 +2894,21 @@ int sdhci_add_host(struct sdhci_host *host)
* register is set. The actual current value is 4 times the register
* value.
*/
+ if (host->vmmc) {
+ ret = regulator_is_supported_voltage(host->vmmc, 330,
+ 330);
+ if ((ret <= 0) || (!(caps[0] & SDHCI_CAN_VDD_330)))
+ caps[0] &= ~SDHCI_CAN_VDD_330;
+ ret = regulator_is_supported_voltage(host->vmmc, 300,
+ 300);
+ if ((ret <= 0) || (!(caps[0] & SDHCI_CAN_VDD_300)))
+ caps[0] &= ~SDHCI_CAN_VDD_300;
+ ret = regulator_is_supported_voltage(host->vmmc, 180,
+ 180);
+ if ((ret <= 0) || (!(caps[0] & SDHCI_CAN_VDD_180)))
+ caps[0] &= ~SDHCI_CAN_VDD_180;
+ }
+
max_current_caps = sdhci_readl(host, SDHCI_MAX_CURRENT);
if (!max_current_caps && host->vmmc) {
u32 curr = regulator_get_current_limit(host->vmmc);
--
1.7.0.4
--
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
[PATCH] mmc: mxs-mmc: Add wp-inverted property
The write-protect GPIO is inverted on some boards. Handle such case.
Signed-off-by: Marek Vasut
Cc: Shawn Guo
Cc: Fabio Estevam
Cc: linux-mmc@vger.kernel.org
Cc: Chris Ball
Cc: Lothar Waßmann
---
drivers/mmc/host/mxs-mmc.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
index 34a9026..c6964e1 100644
--- a/drivers/mmc/host/mxs-mmc.c
+++ b/drivers/mmc/host/mxs-mmc.c
@@ -164,16 +164,23 @@ struct mxs_mmc_host {
spinlock_t lock;
int sdio_irq_en;
int wp_gpio;
+ int wp_inverted:1;
};
static int mxs_mmc_get_ro(struct mmc_host *mmc)
{
struct mxs_mmc_host *host = mmc_priv(mmc);
+ int ret;
if (!gpio_is_valid(host->wp_gpio))
return -EINVAL;
- return gpio_get_value(host->wp_gpio);
+ ret = gpio_get_value(host->wp_gpio);
+
+ if (host->wp_inverted)
+ ret = !ret;
+
+ return ret;
}
static int mxs_mmc_get_cd(struct mmc_host *mmc)
@@ -707,6 +714,7 @@ static int mxs_mmc_probe(struct platform_device *pdev)
struct pinctrl *pinctrl;
int ret = 0, irq_err, irq_dma;
dma_cap_mask_t mask;
+ enum of_gpio_flags flags;
iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dmares = platform_get_resource(pdev, IORESOURCE_DMA, 0);
@@ -785,7 +793,10 @@ static int mxs_mmc_probe(struct platform_device *pdev)
mmc->caps |= MMC_CAP_4_BIT_DATA;
else if (bus_width == 8)
mmc->caps |= MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA;
- host->wp_gpio = of_get_named_gpio(np, "wp-gpios", 0);
+ host->wp_gpio = of_get_named_gpio_flags(np, "wp-gpios", 0,
+ &flags);
+ if (flags & OF_GPIO_ACTIVE_LOW)
+ host->wp_inverted = 1;
} else {
if (pdata->flags & SLOTF_8_BIT_CAPABLE)
mmc->caps |= MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA;
--
1.7.10
--
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
Re: power class selection fails on 3.5-rc1
On Friday 08 June 2012 18:11:20 S, Venkatraman wrote: > On Mon, Jun 4, 2012 at 10:05 PM, Marc Dietrich wrote: > > Hi, > > > > somehow I hope this would go away by itself, but it didn't :-( I reported > > this problem some time ago (see: http://www.mail-archive.com/linux- > > m...@vger.kernel.org/msg13688.html ) but got no clear answer or fix. > > > > In addition to the information I posted on the thread above, I also dumped > > the contents of the ext_csd register file (where reg values are not > > zero): > > > > reg Sandisk Toshiba > > 241 10 0x0a50 0x32 > > 239 0 0x0051 0x33 > > 238 0 0x00119 0x77 > > 234 0 0x0030 0x1e > > 232 1 0x014 0x04 > > 231 21 0x1521 0x15 > > 230 150 0x9616 0x10 > > 229 150 0x9666 0x42 > > 228 1 0x017 0x07 > > 226 8 0x0816 0x10 > > 225 6 0x067 0x07 > > 224 4 0x048 0x08 > > 223 1 0x012 0x02 > > 222 8 0x0816 0x10 > > 221 16 0x101 0x01 > > 220 8 0x087 0x07 > > 219 7 0x077 0x07 > > 217 16 0x1017 0x11 > > 215 1 0x010 0x00 > > 214 218 0xda238 0xee > > 213 160 0xa0128 0x80 > > 210 10 0x0a0 0x00 > > 209 10 0x0a60 0x3c > > 208 10 0x0a0 0x00 > > 207 10 0x0a60 0x3c > > 206 10 0x0a0 0x00 > > 205 10 0x0a30 0x1e > > 203 0 0x0051 0x33 > > 202 0 0x0051 0x33 > > 201 0 0x00119 0x77 > > 200 0 0x00119 0x77 > > 196 3 0x037 0x07 > > 194 2 0x022 0x02 > > 192 5 0x055 0x05 > > 185 1 0x011 0x01 > > 181 0 0x001 0x01 > > 179 0 0x001 0x01 > > 175 0 0x001 0x01 > > 169 1 0x010 0x00 > > 168 0 0x002 0x02 > > 160 3 0x033 0x03 > > 158 0 0x003 0x03 > > 157 237 0xed186 0xba > > > > The second and the third column is from a device with a Sandisk eMCC which > > works fine, while the last two columns are from a Toshiba eMMC which shows > > the error. Looking into it, I found that only the Toshiba eMMC specifies > > a powerclass in registers 203-200 while Sandisk does not, so the > > powerclass is not changed in the latter case and the problem cannot be > > triggered there. > > > > I also attached a boot log with mmc debug enabled. I think there is not > > much I can do else. Either this eMMC is just bogus and needs blacklisting > > or there is some problem in the driver code. > > I am a bit rusty here, so bear with me. > According to the ext_csd, the power class value that should be sent to > the card was 0x7. (Upper nibble of ext_csd[201]). The card runs on 48 MHz, which means the 52 MHz value is choosen. The card is also a "dual-voltage" one (reg 196 = 7), which confuses me which value to select. But vdd reports 0x20 (3.2 - 3.3 V) so register 202 is the one to choose (contains 0x33) or "3" for a nibble. But as I said before, neither 3 or 7 works. Marc -- 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
Re: power class selection fails on 3.5-rc1
On 8 June 2012 18:11, S, Venkatraman wrote: > On Mon, Jun 4, 2012 at 10:05 PM, Marc Dietrich wrote: >> Hi, >> >> somehow I hope this would go away by itself, but it didn't :-( I reported >> this >> problem some time ago (see: http://www.mail-archive.com/linux- >> m...@vger.kernel.org/msg13688.html ) but got no clear answer or fix. >> >> In addition to the information I posted on the thread above, I also dumped >> the >> contents of the ext_csd register file (where reg values are not zero): >> >> reg Sandisk Toshiba >> 241 10 0x0a 50 0x32 >> 239 0 0x00 51 0x33 >> 238 0 0x00 119 0x77 >> 234 0 0x00 30 0x1e >> 232 1 0x01 4 0x04 >> 231 21 0x15 21 0x15 >> 230 150 0x96 16 0x10 >> 229 150 0x96 66 0x42 >> 228 1 0x01 7 0x07 >> 226 8 0x08 16 0x10 >> 225 6 0x06 7 0x07 >> 224 4 0x04 8 0x08 >> 223 1 0x01 2 0x02 >> 222 8 0x08 16 0x10 >> 221 16 0x10 1 0x01 >> 220 8 0x08 7 0x07 >> 219 7 0x07 7 0x07 >> 217 16 0x10 17 0x11 >> 215 1 0x01 0 0x00 >> 214 218 0xda 238 0xee >> 213 160 0xa0 128 0x80 >> 210 10 0x0a 0 0x00 >> 209 10 0x0a 60 0x3c >> 208 10 0x0a 0 0x00 >> 207 10 0x0a 60 0x3c >> 206 10 0x0a 0 0x00 >> 205 10 0x0a 30 0x1e >> 203 0 0x00 51 0x33 >> 202 0 0x00 51 0x33 >> 201 0 0x00 119 0x77 >> 200 0 0x00 119 0x77 >> 196 3 0x03 7 0x07 >> 194 2 0x02 2 0x02 >> 192 5 0x05 5 0x05 >> 185 1 0x01 1 0x01 >> 181 0 0x00 1 0x01 >> 179 0 0x00 1 0x01 >> 175 0 0x00 1 0x01 >> 169 1 0x01 0 0x00 >> 168 0 0x00 2 0x02 >> 160 3 0x03 3 0x03 >> 158 0 0x00 3 0x03 >> 157 237 0xed 186 0xba >> >> The second and the third column is from a device with a Sandisk eMCC which >> works fine, while the last two columns are from a Toshiba eMMC which shows >> the >> error. Looking into it, I found that only the Toshiba eMMC specifies a >> powerclass in registers 203-200 while Sandisk does not, so the powerclass is >> not changed in the latter case and the problem cannot be triggered there. >> >> I also attached a boot log with mmc debug enabled. I think there is not much >> I >> can do else. Either this eMMC is just bogus and needs blacklisting or there >> is >> some problem in the driver code. >> > I am a bit rusty here, so bear with me. > According to the ext_csd, the power class value that should be sent to > the card was 0x7. (Upper nibble of ext_csd[201]). > > What I saw in the attached debug Log: > [ 3.842390] mmc1: starting CMD6 arg 03bb0301 flags 049d > This means write 0x03 into 0xBB register, and not 0x7 which is what is needed. > > While Marc has tried all values from 0 to 10, this wouldn't be the > definite issue, but I am wondering is there is some other problem. > > Or have I got it all wrong ? > ~Venkat. i was forcing 0x7b (for 8 bit width) upper nibble and i get it correct as below i got [1.172784] mmc0: starting CMD6 arg 03bb0701 flags 049d [1.172799] mmc_host mmc0: Bus speed (slot 0) = 6600Hz (slot req 5200 [1.176925] mmc0: req done (CMD6): 0: 0900 may be something wrong > -- > 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 -- 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
RE: power class selection fails on 3.5-rc1
> -Original Message- > From: Girish K S [mailto:girish.shivananja...@linaro.org] > Sent: Friday, June 08, 2012 5:16 PM > To: Subhash Jadavani > Cc: Marc Dietrich; Ulf Hansson; saugata@linaro.org; linux- > m...@vger.kernel.org > Subject: Re: power class selection fails on 3.5-rc1 > > On 7 June 2012 15:53, Subhash Jadavani wrote: > >> > Just for experiment, can we hack the value set to POWER_CLASS field > >> > to > >> > 0x7 instead of 0x3? If this doesn't work, you may try other values > >> > (starting from 1 till 15) to see setting any of the non-zero value > > succeeds or > >> not. > >> > >> I tried 1 to 10 (as this is a 4.41 card) and none of them worked > > (including 7). > > > > Oh, that's not good. > > > > Girish / Saugata, > > Do you have any comments on this? Can you please comment on what type > > of testing was done when we had initially added this power class selection? > Today i tried om the eMMC 4.5 sample. Thanks Girish for trying this out. Does this particular eMMC4.5 sample is supporting HS200? If yes, then can you please undefine MMC_CAP2_HS200 and try? I guess Marc's card don't support HS200 so it will take different code path then yours. In HS200 case, device bus width is first selected and then power class selection field is written. Where as in Marc's case, if card doesn't support HS200, first power class is selected and then card bus width would be changed. Regards, Subhash > I forced the values from 1- 10 > I was able to successfully set the power class value without any error return > value. It failed for the for the value 0xf. > > > > Regards, > > Subhash > > > >> -Original Message- > >> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- > >> ow...@vger.kernel.org] On Behalf Of Marc Dietrich > >> Sent: Thursday, June 07, 2012 3:05 PM > >> To: Subhash Jadavani > >> Cc: 'Ulf Hansson'; Girish K S; saugata@linaro.org; linux- > >> m...@vger.kernel.org > >> Subject: Re: power class selection fails on 3.5-rc1 > >> > >> On Wednesday 06 June 2012 15:14:48 Subhash Jadavani wrote: > >> > > On 06/04/2012 06:35 PM, Marc Dietrich wrote: > >> > > > Hi, > >> > > > > >> > > > somehow I hope this would go away by itself, but it didn't :-( > >> > > > I reported this problem some time ago (see: > >> > > > http://www.mail-archive.com/linux- > >> > > > m...@vger.kernel.org/msg13688.html ) but got no clear answer or fix. > >> > > > > >> > > > In addition to the information I posted on the thread above, I > >> > > > also dumped the contents of the ext_csd register file (where > >> > > > reg values are not zero): > >> > > > > >> > > > reg Sandisk Toshiba > >> > > > 241 10 0x0a 50 0x32 > >> > > > 239 0 0x00 51 0x33 > >> > > > 238 0 0x00 119 0x77 > >> > > > 234 0 0x00 30 0x1e > >> > > > 232 1 0x01 4 0x04 > >> > > > 231 21 0x15 21 0x15 > >> > > > 230 150 0x96 16 0x10 > >> > > > 229 150 0x96 66 0x42 > >> > > > 228 1 0x01 7 0x07 > >> > > > 226 8 0x08 16 0x10 > >> > > > 225 6 0x06 7 0x07 > >> > > > 224 4 0x04 8 0x08 > >> > > > 223 1 0x01 2 0x02 > >> > > > 222 8 0x08 16 0x10 > >> > > > 221 16 0x10 1 0x01 > >> > > > 220 8 0x08 7 0x07 > >> > > > 219 7 0x07 7 0x07 > >> > > > 217 16 0x10 17 0x11 > >> > > > 215 1 0x01 0 0x00 > >> > > > 214 218 0xda 238 0xee > >> > > > 213 160 0xa0 128 0x80 > >> > > > 210 10 0x0a 0 0x00 > >> > > > 209 10 0x0a 60 0x3c > >> > > > 208 10 0x0a 0 0x00 > >> > > > 207 10 0x0a 60 0x3c > >> > > > 206 10 0x0a 0 0x00 > >> > > > 205 10 0x0a 30 0x1e > >> > > > 203 0 0x00 51 0x33 > >> > > > 202 0 0x00 51 0x33 > >> > > > 201 0 0x00 119 0x77 > >> > > > 200 0 0x00 119 0x77 > >> > > > 196 3 0x03 7 0x07 > >> > > > 194 2 0x02 2 0x02 > >> > > > 192 5 0x05 5 0x05 > >> > > > 185 1 0x01 1 0x01 > >> > > > 181 0 0x00 1 0x01 > >> > > > 179 0 0x00 1 0x01 > >> > > > 175 0 0x00 1 0x01 > >> > > > 169 1 0x01 0 0x00 > >> > > > 168 0 0x00 2 0x02 > >> > > > 160 3 0x03 3 0x03 > >> > > > 158 0 0x00 3 0x03 > >> > > > 157 237 0xed 186 0xba > >> > > > > >> > > > The second and the third column is from a device with a Sandisk > >> > > > eMCC which works fine, while the last two columns are from a > >> > > > Toshiba eMMC which shows the error. Looking into it, I found > >> > > > that only the Toshiba eMMC specifies a po
Re: power class selection fails on 3.5-rc1
On Mon, Jun 4, 2012 at 10:05 PM, Marc Dietrich wrote: > Hi, > > somehow I hope this would go away by itself, but it didn't :-( I reported this > problem some time ago (see: http://www.mail-archive.com/linux- > m...@vger.kernel.org/msg13688.html ) but got no clear answer or fix. > > In addition to the information I posted on the thread above, I also dumped the > contents of the ext_csd register file (where reg values are not zero): > > reg Sandisk Toshiba > 241 10 0x0a 50 0x32 > 239 0 0x00 51 0x33 > 238 0 0x00 119 0x77 > 234 0 0x00 30 0x1e > 232 1 0x01 4 0x04 > 231 21 0x15 21 0x15 > 230 150 0x96 16 0x10 > 229 150 0x96 66 0x42 > 228 1 0x01 7 0x07 > 226 8 0x08 16 0x10 > 225 6 0x06 7 0x07 > 224 4 0x04 8 0x08 > 223 1 0x01 2 0x02 > 222 8 0x08 16 0x10 > 221 16 0x10 1 0x01 > 220 8 0x08 7 0x07 > 219 7 0x07 7 0x07 > 217 16 0x10 17 0x11 > 215 1 0x01 0 0x00 > 214 218 0xda 238 0xee > 213 160 0xa0 128 0x80 > 210 10 0x0a 0 0x00 > 209 10 0x0a 60 0x3c > 208 10 0x0a 0 0x00 > 207 10 0x0a 60 0x3c > 206 10 0x0a 0 0x00 > 205 10 0x0a 30 0x1e > 203 0 0x00 51 0x33 > 202 0 0x00 51 0x33 > 201 0 0x00 119 0x77 > 200 0 0x00 119 0x77 > 196 3 0x03 7 0x07 > 194 2 0x02 2 0x02 > 192 5 0x05 5 0x05 > 185 1 0x01 1 0x01 > 181 0 0x00 1 0x01 > 179 0 0x00 1 0x01 > 175 0 0x00 1 0x01 > 169 1 0x01 0 0x00 > 168 0 0x00 2 0x02 > 160 3 0x03 3 0x03 > 158 0 0x00 3 0x03 > 157 237 0xed 186 0xba > > The second and the third column is from a device with a Sandisk eMCC which > works fine, while the last two columns are from a Toshiba eMMC which shows the > error. Looking into it, I found that only the Toshiba eMMC specifies a > powerclass in registers 203-200 while Sandisk does not, so the powerclass is > not changed in the latter case and the problem cannot be triggered there. > > I also attached a boot log with mmc debug enabled. I think there is not much I > can do else. Either this eMMC is just bogus and needs blacklisting or there is > some problem in the driver code. > I am a bit rusty here, so bear with me. According to the ext_csd, the power class value that should be sent to the card was 0x7. (Upper nibble of ext_csd[201]). What I saw in the attached debug Log: [3.842390] mmc1: starting CMD6 arg 03bb0301 flags 049d This means write 0x03 into 0xBB register, and not 0x7 which is what is needed. While Marc has tried all values from 0 to 10, this wouldn't be the definite issue, but I am wondering is there is some other problem. Or have I got it all wrong ? ~Venkat. -- 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
Re: power class selection fails on 3.5-rc1
On 7 June 2012 15:53, Subhash Jadavani wrote: >> > Just for experiment, can we hack the value set to POWER_CLASS field to >> > 0x7 instead of 0x3? If this doesn't work, you may try other values >> > (starting from 1 till 15) to see setting any of the non-zero value > succeeds or >> not. >> >> I tried 1 to 10 (as this is a 4.41 card) and none of them worked > (including 7). > > Oh, that's not good. > > Girish / Saugata, > Do you have any comments on this? Can you please comment on what type of > testing was done when we had initially added this power class selection? Today i tried om the eMMC 4.5 sample. I forced the values from 1- 10 I was able to successfully set the power class value without any error return value. It failed for the for the value 0xf. > > Regards, > Subhash > >> -Original Message- >> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- >> ow...@vger.kernel.org] On Behalf Of Marc Dietrich >> Sent: Thursday, June 07, 2012 3:05 PM >> To: Subhash Jadavani >> Cc: 'Ulf Hansson'; Girish K S; saugata@linaro.org; linux- >> m...@vger.kernel.org >> Subject: Re: power class selection fails on 3.5-rc1 >> >> On Wednesday 06 June 2012 15:14:48 Subhash Jadavani wrote: >> > > On 06/04/2012 06:35 PM, Marc Dietrich wrote: >> > > > Hi, >> > > > >> > > > somehow I hope this would go away by itself, but it didn't :-( I >> > > > reported this problem some time ago (see: >> > > > http://www.mail-archive.com/linux- >> > > > m...@vger.kernel.org/msg13688.html ) but got no clear answer or fix. >> > > > >> > > > In addition to the information I posted on the thread above, I >> > > > also dumped the contents of the ext_csd register file (where reg >> > > > values are not zero): >> > > > >> > > > reg Sandisk Toshiba >> > > > 241 10 0x0a 50 0x32 >> > > > 239 0 0x00 51 0x33 >> > > > 238 0 0x00 119 0x77 >> > > > 234 0 0x00 30 0x1e >> > > > 232 1 0x01 4 0x04 >> > > > 231 21 0x15 21 0x15 >> > > > 230 150 0x96 16 0x10 >> > > > 229 150 0x96 66 0x42 >> > > > 228 1 0x01 7 0x07 >> > > > 226 8 0x08 16 0x10 >> > > > 225 6 0x06 7 0x07 >> > > > 224 4 0x04 8 0x08 >> > > > 223 1 0x01 2 0x02 >> > > > 222 8 0x08 16 0x10 >> > > > 221 16 0x10 1 0x01 >> > > > 220 8 0x08 7 0x07 >> > > > 219 7 0x07 7 0x07 >> > > > 217 16 0x10 17 0x11 >> > > > 215 1 0x01 0 0x00 >> > > > 214 218 0xda 238 0xee >> > > > 213 160 0xa0 128 0x80 >> > > > 210 10 0x0a 0 0x00 >> > > > 209 10 0x0a 60 0x3c >> > > > 208 10 0x0a 0 0x00 >> > > > 207 10 0x0a 60 0x3c >> > > > 206 10 0x0a 0 0x00 >> > > > 205 10 0x0a 30 0x1e >> > > > 203 0 0x00 51 0x33 >> > > > 202 0 0x00 51 0x33 >> > > > 201 0 0x00 119 0x77 >> > > > 200 0 0x00 119 0x77 >> > > > 196 3 0x03 7 0x07 >> > > > 194 2 0x02 2 0x02 >> > > > 192 5 0x05 5 0x05 >> > > > 185 1 0x01 1 0x01 >> > > > 181 0 0x00 1 0x01 >> > > > 179 0 0x00 1 0x01 >> > > > 175 0 0x00 1 0x01 >> > > > 169 1 0x01 0 0x00 >> > > > 168 0 0x00 2 0x02 >> > > > 160 3 0x03 3 0x03 >> > > > 158 0 0x00 3 0x03 >> > > > 157 237 0xed 186 0xba >> > > > >> > > > The second and the third column is from a device with a Sandisk >> > > > eMCC which works fine, while the last two columns are from a >> > > > Toshiba eMMC which shows the error. Looking into it, I found that >> > > > only the Toshiba eMMC specifies a powerclass in registers 203-200 >> > > > while Sandisk does not, so the powerclass is not changed in the >> > > > latter case and the problem cannot be triggered there. >> > > > >> > > > I also attached a boot log with mmc debug enabled. I think there >> > > > is not much I can do else. Either this eMMC is just bogus and >> > > > needs blacklisting or there is some problem in the driver code. >> > >> > I checked the power class specification and MMC core driver handing, I >> > don't see any issue with it. As you mentioned the PWR_CL_* fields are >> > having non-zero values which means SWITCH (CMD6) will be sent to >> > change the POWER_CLASS and from the logs you have attached, this >> > switch command tries to set the POWER_CLASS to 3 which is resulting in >> > SWITCH_ERROR in card and that's why it fails. >> > >> > If the PWR_CL_* fields are 0s (that's the case with SanDisk eMMC as >> > you mentioned), SWITCH(cmd6) is not sent to the card. >> > >> > I was trying to che
Re: [PATCH v6 0/2] *** adding and exposing SANITIZE capability to the user space via a unique IOCTL ***
On Thu, Jun 7, 2012 at 8:08 PM, Yaniv Gardi wrote: > *** adding and exposing SANITIZE capability to the user space via a unique > IOCTL *** Well, is this really needed ? As I understand, SANITIZE is identical to REQ_SECURE + REQ_DISCARD. Mapping the device function to an existing attribute is more easy that creating the whole plumbing around SANITIZE, just because it exists. Apart from the IOCTL, it would be useful to find if any file systems want to use this, and it is any way more friendly than SECURE + DISCARD. > > changes patch v6: > fixed some code review comments > added timeout dependency for CMD6 when > issueing the sanitize command. > > changes patch v5: > added BUG_ON() where needed > > changes patch v4: > removed a few debug printouts > > changes patch v3: > split the patch into 2 commits - block and mmc/card > added capability MMC_CAP2_SANITIZE to mmc controller > > Yaniv Gardi (2): > block: ioctl support for sanitize in eMMC 4.5 > mmc: card: Adding support for sanitize in eMMC 4.5 > > block/blk-core.c | 18 +-- > block/blk-lib.c | 51 +++ > block/blk-merge.c | 6 > block/elevator.c | 41 - > block/ioctl.c | 9 + > drivers/mmc/card/block.c | 72 > drivers/mmc/card/queue.c | 10 +- > include/linux/blk_types.h | 5 ++- > include/linux/blkdev.h | 3 ++ > include/linux/fs.h | 1 + > include/linux/mmc/host.h | 1 + > kernel/trace/blktrace.c | 2 + > 12 files changed, 191 insertions(+), 28 deletions(-) > > -- > 1.7.6 > -- > Sent by a consultant of the Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum > -- > 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 -- 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
Re: [PATCH v2 0/1] block: Add test-iosched scheduler
On Thu, Jun 7, 2012 at 1:14 AM, Maya Erez wrote: > The test scheduler allows testing a block device by dispatching > specific requests according to the test case and declare PASS/FAIL > according to the requests completion error code > I can't get the point. Isn't this possible purely from userspace using IOCTLs ? Even otherwise, requiring to modify the scheduler for each test case is definitely not scalable. > Changes in v2: > - Export test-iosched functionality to allow definition of the block device > tests under the block device layer > - Add registration of block device tests utilities > > Maya Erez (1): > block: Add test-iosched scheduler > > Documentation/block/test-iosched.txt | 39 ++ > block/Kconfig.iosched | 8 + > block/Makefile | 1 + > block/blk-core.c | 3 +- > block/test-iosched.c | 1025 > ++ > include/linux/test-iosched.h | 218 +++ > 6 files changed, 1292 insertions(+), 2 deletions(-) > create mode 100644 Documentation/block/test-iosched.txt > create mode 100644 block/test-iosched.c > create mode 100644 include/linux/test-iosched.h > -- 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
RE: [PATCH v2 1/1] mmc: block: Add write packing control
Hi,
How can we check the effect?
Do you have any result?
Please check the several comment below.
Maya Erez wrote:
> The write packing control will ensure that read requests latency is
> not increased due to long write packed commands.
>
> The trigger for enabling the write packing is managing to pack several
> write requests. The number of potential packed requests that will trigger
> the packing can be configured via sysfs by writing the required value to:
> /sys/block//num_wr_reqs_to_start_packing.
> The trigger for disabling the write packing is fetching a read request.
>
> ---
> Documentation/mmc/mmc-dev-attrs.txt | 17 ++
> drivers/mmc/card/block.c| 100
> ++-
> drivers/mmc/card/queue.c|8 +++
> drivers/mmc/card/queue.h|3 +
> include/linux/mmc/host.h|1 +
> 5 files changed, 128 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/mmc/mmc-dev-attrs.txt
> b/Documentation/mmc/mmc-dev-attrs.txt
> index 22ae844..08f7312 100644
> --- a/Documentation/mmc/mmc-dev-attrs.txt
> +++ b/Documentation/mmc/mmc-dev-attrs.txt
> @@ -8,6 +8,23 @@ The following attributes are read/write.
>
> force_roEnforce read-only access even if write protect
> switch is off.
>
> + num_wr_reqs_to_start_packingThis attribute is used to determine
> + the trigger for activating the write packing, in case the write
> + packing control feature is enabled.
> +
> + When the MMC manages to reach a point where num_wr_reqs_to_start_packing
> + write requests could be packed, it enables the write packing feature.
> + This allows us to start the write packing only when it is beneficial
> + and has minimum affect on the read latency.
> +
> + The number of potential packed requests that will trigger the packing
> + can be configured via sysfs by writing the required value to:
> + /sys/block//num_wr_reqs_to_start_packing.
> +
> + The default value of num_wr_reqs_to_start_packing was determined by
> + running parallel lmdd write and lmdd read operations and calculating
> + the max number of packed writes requests.
> +
> SD and MMC Device Attributes
>
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index 2785fd4..ef192fb 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -114,6 +114,7 @@ struct mmc_blk_data {
> struct device_attribute force_ro;
> struct device_attribute power_ro_lock;
> int area_type;
> + struct device_attribute num_wr_reqs_to_start_packing;
> };
>
> static DEFINE_MUTEX(open_lock);
> @@ -281,6 +282,38 @@ out:
> return ret;
> }
>
> +static ssize_t
> +num_wr_reqs_to_start_packing_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct mmc_blk_data *md = mmc_blk_get(dev_to_disk(dev));
> + int num_wr_reqs_to_start_packing;
> + int ret;
> +
> + num_wr_reqs_to_start_packing = md->queue.num_wr_reqs_to_start_packing;
> +
> + ret = snprintf(buf, PAGE_SIZE, "%d\n", num_wr_reqs_to_start_packing);
> +
> + mmc_blk_put(md);
> + return ret;
> +}
> +
> +static ssize_t
> +num_wr_reqs_to_start_packing_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + int value;
> + struct mmc_blk_data *md = mmc_blk_get(dev_to_disk(dev));
> +
> + sscanf(buf, "%d", &value);
> + if (value >= 0)
> + md->queue.num_wr_reqs_to_start_packing = value;
> +
> + mmc_blk_put(md);
> + return count;
> +}
> +
> static int mmc_blk_open(struct block_device *bdev, fmode_t mode)
> {
> struct mmc_blk_data *md = mmc_blk_get(bdev->bd_disk);
> @@ -1313,6 +1346,48 @@ static void mmc_blk_rw_rq_prep(struct mmc_queue_req
> *mqrq,
> mmc_queue_bounce_pre(mqrq);
> }
>
> +static void mmc_blk_write_packing_control(struct mmc_queue *mq,
> + struct request *req)
> +{
> + struct mmc_host *host = mq->card->host;
> + int data_dir;
> +
> + if (!(host->caps2 & MMC_CAP2_PACKED_WR))
> + return;
> +
> + /*
> + * In case the packing control is not supported by the host, it should
> + * not have an effect on the write packing. Therefore we have to enable
> + * the write packing
> + */
> + if (!(host->caps2 & MMC_CAP2_PACKED_WR_CONTROL)) {
> + mq->wr_packing_enabled = true;
> + return;
> + }
> +
> + if (!req || (req && (req->cmd_flags & REQ_FLUSH))) {
> + if (mq->num_of_potential_packed_wr_reqs >
> + mq->num_wr_reqs_to_start_packing)
> + mq->wr_packing_enabled = true;
> + return;
> + }
> +
> + data_dir = rq_data_dir(req);
> +
> + if (data_dir == READ)
Re: [CFT 02/11] mmc: omap_hsmmc: add DMA engine support
On Thu, Jun 7, 2012 at 1:06 PM, Russell King wrote: > Add DMA engine support to the OMAP HSMMC driver. This supplements the > private DMA API implementation contained within this driver, and the > driver can be switched at build time between using DMA engine and the > private DMA API. > > Tested-by: Grazvydas Ignotas > Signed-off-by: Russell King Looks good: Acked-by: Linus Walleij Thanks, Linus Walleij -- 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
Re: [CFT 04/11] mmc: omap: add DMA engine support
On Thu, Jun 7, 2012 at 1:07 PM, Russell King wrote: > Add DMA engine support to the OMAP driver. This supplements the > private DMA API implementation contained within this driver, and the > driver can be switched at build time between using DMA engine and the > private DMA API. > > Signed-off-by: Russell King This looks good as well: Acked-by: Linus Walleij Thanks, Linus Walleij -- 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
