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
