[PATCH 2/2] dt-bindings: rockchip-dw-mshc: add rockchip,default-drv-phase

Shawn Lin shawn.lin at rock-chips.com
Tue May 10 19:50:17 PDT 2016


On 2016/5/10 23:57, Doug Anderson wrote:
> (again, but not HTML)
>

------8<------------------

>
> I have less faith than you in the TRM.  The TRM is full of minor
> errors and is often wrong about the default state of things.  IMHO the
> only true way to find out is to boot up some SoCs and check.
>

Okay, I should not have too much confidence on my TRM maybe :).

Again, We SHOULD refer to the Mobile Storage Host section (Variable
Delay/Clock Generation) instead of CRU section, otherwise even you will
see inconsistent decription of mmc_clock->shift.



> As far as whether code touches these values:
>

---------8<-----------------

>>
>> maybe. But I think 180(downside) is the better.

NAK my previous comments here. Downside is better for SRD, but won't
work for DDR mode. When running in DDR mode, we should use 90 instead.

So let me elaborate a bit more here.
For DDR mode, one single clk cycle should sending two data bits outside
to the devices. We need a hold time for both. If 180 is used, the first
bit occurs around the downside area, which won't be sampled by devices
on the upside.  So on the upside, the devices will see a zero bit if you
actually send a one-bit, which makes the devices  generate CRC finally.


For this above, 180 for all SDR mode is ok, but 90 should be deployed
for DDR mode. So simply checking the timing to hardcode it should be
fine.

>
> I'm OK with using 180 always as long as SD cards continue to work OK.
> Best would be if someone could actually run a protocol analyzer for
> all the different speed modes.
>
>
>>> Also: I still haven't heard whether there is any downside to using 180
>>> degrees for modes that only require 90 degrees.  Does it cause
>>> problems to just always use 180 degrees?  If not, we could possibly
>>> use 180 degrees everywhere and just hardcode it?
>>
>>



-- 
Best Regards
Shawn Lin




More information about the Linux-rockchip mailing list