Re: eMMC boot problem: switch to bus width 8 ddr failed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Shawn,

On Fri, Jan 13, 2017 at 12:03 PM, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> wrote:

[...]

>
>> 2) root cause, in __mmc_switch, the process is   send CMD6 --> set DDR52
>> timing --> polling for busy.
>> For the DDR52 timing setting, we call set_ios(), in the set_ios, we first
>> set DDR_EN to config sdhc in ddr mode,
>> and then config the sd clock again.   Here it is, after CMD6 complete, we
>> find data0 still low, which means card
>> busy. At this time, if we set DDR_EN, there is a risk. For i.MX usdhc,
>> DDR_EN setting becomes active only when
>> the DATA and CMD line are idle. So, at this time for HW, DDR_EN do not
>> active, but software think DDR_EN already
>> active, and set the clock again to 49.5MHz, but actually the HW out put
>> the clock as 198MHz. So there is clock glitch.
>> This is the root cause--set DDR_EN when card is still busy.
>>
>
> Make sense. But it makes me more worried about the problem.
> Does it impact other controllers if changing timing settings when
> it's in busy state? It seems very likely possible. So I'm afraid
> that we now just break hs_ddr mode for your platform but on the
> contrary your case exposes this potention risk here. Thought?
>

Yes, i got the same concern as i replied in my last email.
Not sure if any other controllers exposes the same issue
since the kernel having this issue is quite new.

Regards
Dong Aisheng

>> The following method can fix this issue
>> a) change the HW behavior, DDR_EN setting becomes active at once no matter
>> what the state of the DATA and
>> CMD line are.   This can fix this issue, but our IC guys do not prefer
>> this, this method still not safe enough.
>>
>> b) add 1ms delay before DDR_EN to wait bus idle.  But we still not know
>> whether the time 1ms is appropriate. Better
>> to poll for busy before set DDR_EN.
>>
>> c) set DDR52 timing after CMD6 and pull for busy. This is what Shawn's
>> patch do.
>>
>> Hi Aisheng,
>> Correct me if anything wrong.
>>
>> My suggestion is that,  in __mmc_switch(), move the mmc_set_timing() after
>> the function mmc_poll_for_busy().
>>
>>
>> Best Regards
>> Haibo Chen
>>
>>
>>
>>>> if that can be done. So I will give Haibo/Dong etc a couple of more
>>>> days to investigate, before applying Shawn Lin's fix for the core.
>>>> Hope that approach is okay with all of you?
>>>>
>>>> Kind regards
>>>> Uffe
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Best Regards
>>> Shawn Lin
>>
>>
>
>
> --
> Best Regards
> Shawn Lin
>
> --
> 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
--
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



[Index of Archives]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux