public inbox for linux-mmc@vger.kernel.org
 help / color / mirror / Atom feed
* mmc: UHS Voltage switch and operating frequency question
@ 2017-07-31 16:20 Jerome Brunet
  2017-08-01  0:38 ` Shawn Lin
  0 siblings, 1 reply; 6+ messages in thread
From: Jerome Brunet @ 2017-07-31 16:20 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: Kevin Hilman, linux-mmc@vger.kernel.org,
	open list:ARM/Amlogic Meson...

Hi Ulf,

I am working on adding signal voltage switch callback to the meson mmc driver.
While testing, I noticed that a few cards fail to exit the busy state after the
voltage switch.

After tinkering with the driver a bit, I noticed that increasing the clock
frequency from 400kHz to 1MHz solve the problem. Strange, isn't it ?

I'm don't know MMC that much but is it possible that some card require a minimum
operating frequency to enter UHS mode ?

The simplified spec (Part 1 - Physical Layer) says that before CMD11, we should
have had CMD41 (Init Command) . After CMD41, the card should be operating at
Default Speed or SDR12. 

I believe that in both case, the frequency is "up to 25Mhz" ? This would be the
maximum, but is there a minimum ? 400kHz seems pretty low compared to 25Mhz ...

I hope you will able to shed light on this :)

Best Regards
jerome

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: mmc: UHS Voltage switch and operating frequency question
  2017-07-31 16:20 mmc: UHS Voltage switch and operating frequency question Jerome Brunet
@ 2017-08-01  0:38 ` Shawn Lin
  2017-08-01 16:56   ` Jerome Brunet
  0 siblings, 1 reply; 6+ messages in thread
From: Shawn Lin @ 2017-08-01  0:38 UTC (permalink / raw)
  To: Jerome Brunet
  Cc: Ulf Hansson, shawn.lin, Kevin Hilman, linux-mmc@vger.kernel.org,
	open list:ARM/Amlogic Meson...


On 2017/8/1 0:20, Jerome Brunet wrote:
> Hi Ulf,
> 
> I am working on adding signal voltage switch callback to the meson mmc driver.
> While testing, I noticed that a few cards fail to exit the busy state after the
> voltage switch.
> 
> After tinkering with the driver a bit, I noticed that increasing the clock
> frequency from 400kHz to 1MHz solve the problem. Strange, isn't it ?

AFAICT, most of the internal circuit of card is running against the
input clock from host. So if you increase your clock, cards will finish
thier logic switch faster. Note that the spec does state that 400KHz is
the max freq for indentification mode. But the fact is that almost all
cards could accept higher frequecncy.

For you issue, please try to hack mmc_set_uhs_voltage to increase the
delay there to see if that could solve your problem.

> 
> I'm don't know MMC that much but is it possible that some card require a minimum
> operating frequency to enter UHS mode ?
> 

We shoule never give a hypothesis beyond the scope of spec.


> The simplified spec (Part 1 - Physical Layer) says that before CMD11, we should
> have had CMD41 (Init Command) . After CMD41, the card should be operating at
> Default Speed or SDR12.
> 
> I believe that in both case, the frequency is "up to 25Mhz" ? This would be the
> maximum, but is there a minimum ? 400kHz seems pretty low compared to 25Mhz ...
> 

400KHz is good for work unless your IP has limitation for that.

> I hope you will able to shed light on this :)
> 
> Best Regards
> jerome
> --
> 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
> 
> 
> 


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: mmc: UHS Voltage switch and operating frequency question
  2017-08-01  0:38 ` Shawn Lin
@ 2017-08-01 16:56   ` Jerome Brunet
  2017-08-02  2:54     ` Shawn Lin
  0 siblings, 1 reply; 6+ messages in thread
From: Jerome Brunet @ 2017-08-01 16:56 UTC (permalink / raw)
  To: Shawn Lin
  Cc: Ulf Hansson, Kevin Hilman, linux-mmc@vger.kernel.org,
	open list:ARM/Amlogic Meson...

On Tue, 2017-08-01 at 08:38 +0800, Shawn Lin wrote:
> On 2017/8/1 0:20, Jerome Brunet wrote:
> > Hi Ulf,
> > 
> > I am working on adding signal voltage switch callback to the meson mmc
> > driver.
> > While testing, I noticed that a few cards fail to exit the busy state after
> > the
> > voltage switch.
> > 
> > After tinkering with the driver a bit, I noticed that increasing the clock
> > frequency from 400kHz to 1MHz solve the problem. Strange, isn't it ?
> 

Thanks for your reply Shawn !

> AFAICT, most of the internal circuit of card is running against the
> input clock from host. So if you increase your clock, cards will finish
> thier logic switch faster.

Yeah that would be my understanding as well

>  Note that the spec does state that 400KHz is
> the max freq for indentification mode. But the fact is that almost all
> cards could accept higher frequecncy.

Agreed. but I'm not talking about the frequency used during identification.
The step I'm referring to is after CMD41, during CMD11. After CMD11, the spec
says that the frequency is up to "default speed or SDR12" so 25Mhz. 

If id mode is limited to 400kHz, it is clearly a different stage.

> 
> For you issue, please try to hack mmc_set_uhs_voltage to increase the
> delay there to see if that could solve your problem.
> 

Ohhh believe me, I did :) however these 2 cards are quite stubborn 

> > 
> > I'm don't know MMC that much but is it possible that some card require a
> > minimum
> > operating frequency to enter UHS mode ?
> > 
> 
> We shoule never give a hypothesis beyond the scope of spec.
I don't get what you mean ? 

> 
> > The simplified spec (Part 1 - Physical Layer) says that before CMD11, we
> > should
> > have had CMD41 (Init Command) . After CMD41, the card should be operating at
> > Default Speed or SDR12.
> > 
> > I believe that in both case, the frequency is "up to 25Mhz" ? This would be
> > the
> > maximum, but is there a minimum ? 400kHz seems pretty low compared to 25Mhz
> > ...
> > 
> 
> 400KHz is good for work unless your IP has limitation for that.
Ip seems to be fine at 400KHz with every other cards, including uhs ones.
The 2 "annoying" cards switch to UHS mode fine on a laptop.

It the combination of the ip and the cards which seems broken, whatever the
delays I put here and there.

For a reason I don't understand, increasing the minimal frequency from 400Khz to
1MHz make these cards work very nicely.

> 
> > I hope you will able to shed light on this :)
> > 
> > Best Regards
> > jerome
> > --
> > 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
> > 
> > 
> > 
> 
> 


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: mmc: UHS Voltage switch and operating frequency question
  2017-08-01 16:56   ` Jerome Brunet
@ 2017-08-02  2:54     ` Shawn Lin
  2017-08-02  9:20       ` Jerome Brunet
  0 siblings, 1 reply; 6+ messages in thread
From: Shawn Lin @ 2017-08-02  2:54 UTC (permalink / raw)
  To: Jerome Brunet
  Cc: shawn.lin, Ulf Hansson, Kevin Hilman, linux-mmc@vger.kernel.org,
	open list:ARM/Amlogic Meson...

On 2017/8/2 0:56, Jerome Brunet wrote:
> On Tue, 2017-08-01 at 08:38 +0800, Shawn Lin wrote:
>> On 2017/8/1 0:20, Jerome Brunet wrote:
>>> Hi Ulf,
>>>
>>> I am working on adding signal voltage switch callback to the meson mmc
>>> driver.
>>> While testing, I noticed that a few cards fail to exit the busy state after
>>> the
>>> voltage switch.
>>>
>>> After tinkering with the driver a bit, I noticed that increasing the clock
>>> frequency from 400kHz to 1MHz solve the problem. Strange, isn't it ?
>>
> 
> Thanks for your reply Shawn !
> 
>> AFAICT, most of the internal circuit of card is running against the
>> input clock from host. So if you increase your clock, cards will finish
>> thier logic switch faster.
> 
> Yeah that would be my understanding as well
> 
>>   Note that the spec does state that 400KHz is
>> the max freq for indentification mode. But the fact is that almost all
>> cards could accept higher frequecncy.
> 
> Agreed. but I'm not talking about the frequency used during identification.
> The step I'm referring to is after CMD41, during CMD11. After CMD11, the spec

I also notice you said "a few cards fail to exit teh busy state after
the voltage switch". That implies that card didn't finish voltage switch
at all, so it shouldn't argue for increasing the clk as the spec only
say "cmd11 invlokes voltage switching squence. If it is *completed*, the
card enters SDR12(default)." and "Completion of voltage switch sequence
is checked by high level of DAT[3:0]"

So these two cards are probably still in id mode or some un-documented
state, I guess. No hints for that per the spec but you should try to
make sure the behaviour of your contrller follows the whole requirement
of SD spec "4.2.4.2 Timing to Switch Signal Voltage".... especially
to see if your 1.8v is stable within 5ms...


> says that the frequency is up to "default speed or SDR12" so 25Mhz >
> If id mode is limited to 400kHz, it is clearly a different stage.
> 
>>
>> For you issue, please try to hack mmc_set_uhs_voltage to increase the
>> delay there to see if that could solve your problem.
>>
> 
> Ohhh believe me, I did :) however these 2 cards are quite stubborn
> 
>>>
>>> I'm don't know MMC that much but is it possible that some card require a
>>> minimum
>>> operating frequency to enter UHS mode ?
>>>
>>
>> We shoule never give a hypothesis beyond the scope of spec.
> I don't get what you mean ?
> 
>>
>>> The simplified spec (Part 1 - Physical Layer) says that before CMD11, we
>>> should
>>> have had CMD41 (Init Command) . After CMD41, the card should be operating at
>>> Default Speed or SDR12.
>>>
>>> I believe that in both case, the frequency is "up to 25Mhz" ? This would be
>>> the
>>> maximum, but is there a minimum ? 400kHz seems pretty low compared to 25Mhz
>>> ...
>>>
>>
>> 400KHz is good for work unless your IP has limitation for that.
> Ip seems to be fine at 400KHz with every other cards, including uhs ones.
> The 2 "annoying" cards switch to UHS mode fine on a laptop.
> 
> It the combination of the ip and the cards which seems broken, whatever the
> delays I put here and there.
> 
> For a reason I don't understand, increasing the minimal frequency from 400Khz to
> 1MHz make these cards work very nicely.
> 
>>
>>> I hope you will able to shed light on this :)
>>>
>>> Best Regards
>>> jerome
>>> --
>>> 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
>>>
>>>
>>>
>>
>>
> 
> 
> 
> 


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: mmc: UHS Voltage switch and operating frequency question
  2017-08-02  2:54     ` Shawn Lin
@ 2017-08-02  9:20       ` Jerome Brunet
  2017-08-02 10:07         ` Shawn Lin
  0 siblings, 1 reply; 6+ messages in thread
From: Jerome Brunet @ 2017-08-02  9:20 UTC (permalink / raw)
  To: Shawn Lin
  Cc: Ulf Hansson, Kevin Hilman, linux-mmc@vger.kernel.org,
	open list:ARM/Amlogic Meson...

On Wed, 2017-08-02 at 10:54 +0800, Shawn Lin wrote:
> On 2017/8/2 0:56, Jerome Brunet wrote:
> > On Tue, 2017-08-01 at 08:38 +0800, Shawn Lin wrote:
> > > On 2017/8/1 0:20, Jerome Brunet wrote:
> > > > Hi Ulf,
> > > > 
> > > > I am working on adding signal voltage switch callback to the meson mmc
> > > > driver.
> > > > While testing, I noticed that a few cards fail to exit the busy state
> > > > after
> > > > the
> > > > voltage switch.
> > > > 
> > > > After tinkering with the driver a bit, I noticed that increasing the
> > > > clock
> > > > frequency from 400kHz to 1MHz solve the problem. Strange, isn't it ?
> > 
> > Thanks for your reply Shawn !
> > 
> > > AFAICT, most of the internal circuit of card is running against the
> > > input clock from host. So if you increase your clock, cards will finish
> > > thier logic switch faster.
> > 
> > Yeah that would be my understanding as well
> > 
> > >   Note that the spec does state that 400KHz is
> > > the max freq for indentification mode. But the fact is that almost all
> > > cards could accept higher frequecncy.
> > 
> > Agreed. but I'm not talking about the frequency used during identification.
> > The step I'm referring to is after CMD41, during CMD11. After CMD11, the
> > spec
> 
> I also notice you said "a few cards fail to exit teh busy state after
> the voltage switch". That implies that card didn't finish voltage switch
> at all, so it shouldn't argue for increasing the clk as the spec only
> say "cmd11 invlokes voltage switching squence. If it is *completed*, the
> card enters SDR12(default)." and "Completion of voltage switch sequence
> is checked by high level of DAT[3:0]"

I understand increasing the frequency does not make much sense, but it makes it
works. I'm trying to understand why ... hopefully it will lead to a real
solution.

> 
> So these two cards are probably still in id mode or some un-documented
> state, I guess. No hints for that per the spec but you should try to
> make sure the behaviour of your contrller follows the whole requirement
> of SD spec "4.2.4.2 Timing to Switch Signal Voltage".... especially
> to see if your 1.8v is stable within 5ms...

Unfortunately section "4.2.4.2 Timing to Switch Signal Voltage" is blank in the
simplified (freely available) spec. I could not get my hands on the full spec
yet.

Unsettled regulator was one of my first guesses. The regulator setup on my board
needs some time to settle when switch from 3.3v to 1.8v, around 70ms.
I made sure to delay the return of the host voltage_switch callback until the
voltage is stable at 1.8v.

This probably is a bit long but, at this stage, the clock is gated so the card
should not see the difference, right ?

So on return of "mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_180)", the
voltage should be stable at 1.8v and we will the get the 10ms (even if spec says
5ms apparently) before re-enabling the clock.


Again, Thanks for helping out Shawn !
Cheers
Jerome

> 
> 
> > says that the frequency is up to "default speed or SDR12" so 25Mhz >
> > If id mode is limited to 400kHz, it is clearly a different stage.
> > 
> > > 
> > > For you issue, please try to hack mmc_set_uhs_voltage to increase the
> > > delay there to see if that could solve your problem.
> > > 
> > 
> > Ohhh believe me, I did :) however these 2 cards are quite stubborn
> > 
> > > > 
> > > > I'm don't know MMC that much but is it possible that some card require a
> > > > minimum
> > > > operating frequency to enter UHS mode ?
> > > > 
> > > 
> > > We shoule never give a hypothesis beyond the scope of spec.
> > 
> > I don't get what you mean ?
> > 
> > > 
> > > > The simplified spec (Part 1 - Physical Layer) says that before CMD11, we
> > > > should
> > > > have had CMD41 (Init Command) . After CMD41, the card should be
> > > > operating at
> > > > Default Speed or SDR12.
> > > > 
> > > > I believe that in both case, the frequency is "up to 25Mhz" ? This would
> > > > be
> > > > the
> > > > maximum, but is there a minimum ? 400kHz seems pretty low compared to
> > > > 25Mhz
> > > > ...
> > > > 
> > > 
> > > 400KHz is good for work unless your IP has limitation for that.
> > 
> > Ip seems to be fine at 400KHz with every other cards, including uhs ones.
> > The 2 "annoying" cards switch to UHS mode fine on a laptop.
> > 
> > It the combination of the ip and the cards which seems broken, whatever the
> > delays I put here and there.
> > 
> > For a reason I don't understand, increasing the minimal frequency from
> > 400Khz to
> > 1MHz make these cards work very nicely.
> > 
> > > 
> > > > I hope you will able to shed light on this :)
> > > > 
> > > > Best Regards
> > > > jerome
> > > > --
> > > > 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
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> 
> 


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: mmc: UHS Voltage switch and operating frequency question
  2017-08-02  9:20       ` Jerome Brunet
@ 2017-08-02 10:07         ` Shawn Lin
  0 siblings, 0 replies; 6+ messages in thread
From: Shawn Lin @ 2017-08-02 10:07 UTC (permalink / raw)
  To: Jerome Brunet
  Cc: shawn.lin, Ulf Hansson, Kevin Hilman, linux-mmc@vger.kernel.org,
	open list:ARM/Amlogic Meson...


On 2017/8/2 17:20, Jerome Brunet wrote:
> On Wed, 2017-08-02 at 10:54 +0800, Shawn Lin wrote:
>> On 2017/8/2 0:56, Jerome Brunet wrote:
>>> On Tue, 2017-08-01 at 08:38 +0800, Shawn Lin wrote:
>>>> On 2017/8/1 0:20, Jerome Brunet wrote:
>>>>> Hi Ulf,
>>>>>
>>>>> I am working on adding signal voltage switch callback to the meson mmc
>>>>> driver.
>>>>> While testing, I noticed that a few cards fail to exit the busy state
>>>>> after
>>>>> the
>>>>> voltage switch.
>>>>>
>>>>> After tinkering with the driver a bit, I noticed that increasing the
>>>>> clock
>>>>> frequency from 400kHz to 1MHz solve the problem. Strange, isn't it ?
>>>
>>> Thanks for your reply Shawn !
>>>
>>>> AFAICT, most of the internal circuit of card is running against the
>>>> input clock from host. So if you increase your clock, cards will finish
>>>> thier logic switch faster.
>>>
>>> Yeah that would be my understanding as well
>>>
>>>>    Note that the spec does state that 400KHz is
>>>> the max freq for indentification mode. But the fact is that almost all
>>>> cards could accept higher frequecncy.
>>>
>>> Agreed. but I'm not talking about the frequency used during identification.
>>> The step I'm referring to is after CMD41, during CMD11. After CMD11, the
>>> spec
>>
>> I also notice you said "a few cards fail to exit teh busy state after
>> the voltage switch". That implies that card didn't finish voltage switch
>> at all, so it shouldn't argue for increasing the clk as the spec only
>> say "cmd11 invlokes voltage switching squence. If it is *completed*, the
>> card enters SDR12(default)." and "Completion of voltage switch sequence
>> is checked by high level of DAT[3:0]"
> 
> I understand increasing the frequency does not make much sense, but it makes it
> works. I'm trying to understand why ... hopefully it will lead to a real
> solution.
> 
>>
>> So these two cards are probably still in id mode or some un-documented
>> state, I guess. No hints for that per the spec but you should try to
>> make sure the behaviour of your contrller follows the whole requirement
>> of SD spec "4.2.4.2 Timing to Switch Signal Voltage".... especially
>> to see if your 1.8v is stable within 5ms...
> 
> Unfortunately section "4.2.4.2 Timing to Switch Signal Voltage" is blank in the
> simplified (freely available) spec. I could not get my hands on the full spec
> yet.
> 

okay, the full spec seems confidential for SD association members.

> Unsettled regulator was one of my first guesses. The regulator setup on my board
> needs some time to settle when switch from 3.3v to 1.8v, around 70ms.
> I made sure to delay the return of the host voltage_switch callback until the
> voltage is stable at 1.8v.
> 
> This probably is a bit long but, at this stage, the clock is gated so the card
> should not see the difference, right ?
> 

No. I saw some failure cases for that, so that's why I asked you to
check this.

I can't share the full spec, but I think I could paste some bits.

Per section, 4.2.4.2:

"1.8v output of voltage regulator in card shall be stable within 5ms.
Host keeps SDCLK low at least 5ms. This means that 5ms is the maximum 
for the card and the minimum for the host. "

So that is mandatory for HW behaviour, not software relevant....



> So on return of "mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_180)", the
> voltage should be stable at 1.8v and we will the get the 10ms (even if spec says
> 5ms apparently) before re-enabling the clock.
> 
> 
> Again, Thanks for helping out Shawn !
> Cheers
> Jerome
> 
>>
>>
>>> says that the frequency is up to "default speed or SDR12" so 25Mhz >
>>> If id mode is limited to 400kHz, it is clearly a different stage.
>>>
>>>>
>>>> For you issue, please try to hack mmc_set_uhs_voltage to increase the
>>>> delay there to see if that could solve your problem.
>>>>
>>>
>>> Ohhh believe me, I did :) however these 2 cards are quite stubborn
>>>
>>>>>
>>>>> I'm don't know MMC that much but is it possible that some card require a
>>>>> minimum
>>>>> operating frequency to enter UHS mode ?
>>>>>
>>>>
>>>> We shoule never give a hypothesis beyond the scope of spec.
>>>
>>> I don't get what you mean ?
>>>
>>>>
>>>>> The simplified spec (Part 1 - Physical Layer) says that before CMD11, we
>>>>> should
>>>>> have had CMD41 (Init Command) . After CMD41, the card should be
>>>>> operating at
>>>>> Default Speed or SDR12.
>>>>>
>>>>> I believe that in both case, the frequency is "up to 25Mhz" ? This would
>>>>> be
>>>>> the
>>>>> maximum, but is there a minimum ? 400kHz seems pretty low compared to
>>>>> 25Mhz
>>>>> ...
>>>>>
>>>>
>>>> 400KHz is good for work unless your IP has limitation for that.
>>>
>>> Ip seems to be fine at 400KHz with every other cards, including uhs ones.
>>> The 2 "annoying" cards switch to UHS mode fine on a laptop.
>>>
>>> It the combination of the ip and the cards which seems broken, whatever the
>>> delays I put here and there.
>>>
>>> For a reason I don't understand, increasing the minimal frequency from
>>> 400Khz to
>>> 1MHz make these cards work very nicely.
>>>
>>>>
>>>>> I hope you will able to shed light on this :)
>>>>>
>>>>> Best Regards
>>>>> jerome
>>>>> --
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
> 
> 
> 
> 


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2017-08-02 10:07 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-07-31 16:20 mmc: UHS Voltage switch and operating frequency question Jerome Brunet
2017-08-01  0:38 ` Shawn Lin
2017-08-01 16:56   ` Jerome Brunet
2017-08-02  2:54     ` Shawn Lin
2017-08-02  9:20       ` Jerome Brunet
2017-08-02 10:07         ` Shawn Lin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox