> -----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 <subha...@codeaurora.org> 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 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. > >> > >> I tried 1 to 10 (as this is a 4.41 card) and none of them worked > > (including 7). > >> > >> > > > 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? > >> > >> sure, that would be the best solution... > >> > >> 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 > > -- 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
