<Girish / Saugata needs to comment on one point> Comments inline: > -----Original Message----- > From: Ulf Hansson [mailto:ulf.hansson@xxxxxxxxxxxxxx] > Sent: Tuesday, June 05, 2012 6:06 PM > To: Marc Dietrich; Subhash Jadavani > Cc: linux-mmc@xxxxxxxxxxxxxxx > Subject: Re: power class selection fails on 3.5-rc1 > > Hi Marc, > > Maybe we can have some input from Subhash on this matter. I believe a revert > can be feasible until a working solution exist. > > Kind regards > Ulf Hansson > > 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- > > mmc@xxxxxxxxxxxxxxx/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 check analyze more from logs and the above EXT_CSD fields for Toshiba card. EXT_CSD[203] => PWR_CL_26_360 => 0x33 EXT_CSD[202] => PWR_CL_52_360 => 0x33 EXT_CSD[201] => PWR_CL_26_195 => 0x77 EXT_CSD[200] => PWR_CL_52_195 => 0x77 >> [ 3.842382] mmc1: clock 48000000Hz busmode 2 powermode 2 cs 0 Vdd 20 width 0 timing 1 Logs shows that clock = 48MHz, bus_width = 8-Bit, SDR mode, VDD = High voltage range. This would mean power class for this configuration will be in higher nibble of PWR_CL_52_360 field (EXT_CSD[202]) which is 0x3. >> [ 3.842390] mmc1: starting CMD6 arg 03bb0301 flags 0000049d "arg" field from this logs show that we are trying to set the POWER_CLASS (EXT_CSD[187]) field to value 0x3 which is resulting in switch error which ideally shouldn't. 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. diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c index 2d4a4b7..b26913a 100644 --- a/drivers/mmc/core/mmc.c +++ b/drivers/mmc/core/mmc.c @@ -713,7 +713,7 @@ static int mmc_select_powerclass(struct mmc_card *card, if (pwrclass_val > 0) { err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_POWER_CLASS, - pwrclass_val, + 0x7, card->ext_csd.generic_cmd6_time); } > > > > I hope this problem can be fixed or if it can't, I hope that commit > > 3d93576e > > (mmc: core: skip card initialization if power class selection fails) > > is reverted until the issues are sorted out. 3d93576e is really not the issue here. Reverting that patch is just a bad workaround to the problem. We should actually try to find why exactly setting the POWER_CLASS field is failing? Originally, Girish had added power class selection base patch. I am not sure whether he ever got a change to test eMMC cards which expose the non-zero values in PWR_CL_* fields. Girish, Can you please comment on what type of testing was done at that time? > > > > Greetings, > > > > Marc -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
