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
--
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
