RE: power class selection fails on 3.5-rc1

["Subhash Jadavani" <subhashj@codeaurora.org>]

> -----Original Message-----
> From: Girish K S [mailto:girish.shivananjappa@linaro.org]
> Sent: Friday, June 08, 2012 5:16 PM
> To: Subhash Jadavani
> Cc: Marc Dietrich; Ulf Hansson; saugata.das@linaro.org; linux-
> mmc@vger.kernel.org
> Subject: Re: power class selection fails on 3.5-rc1
> 
> On 7 June 2012 15:53, Subhash Jadavani <subhashj@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-owner@vger.kernel.org [mailto:linux-mmc-
> >> owner@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.das@linaro.org; linux-
> >> mmc@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-
> >> > > > mmc@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 majordomo@vger.kernel.org More majordomo info at
> >> http://vger.kernel.org/majordomo-info.html
> >