Yuvaraj, On Thu, Aug 22, 2013 at 11:25 PM, Yuvaraj Cd <yuvaraj.lkml@xxxxxxxxx> wrote: >>> b.card-detect-delay >>> c.samsung,dw-mshc-ciu-div >>> d.samsung,dw-mshc-sdr-timing >>> e.samsung,dw-mshc-ddr-timing OK, so I don't know about card-detect-delay, but here's my belief about the others. Feel free to tell me I'm wrong, since I'm not an EE by training and also the stuff below has been cobbled together from lots of different docs. I also haven't experimented enough to know 100% that it's correct. I also know nothing about the actual signaling protocols of SD/MMC... Enough caveats? sdr-timing / ddr-timing: * First number (I think) allows you to drive data related lines at a phase offset from the clock line. So if you have crazy routing on your board and the data lines are much longer than the clock lines you might want to do this. This is not common, so usually you want 0 here. Note that some other docs I have disagree with this and claim that this number has to do with hold time requirements. * Second number allows you to sample signals from the card at a phase offset from the clock line. This number might depend on the card, but hopefully not much. It's supposed to depend more on the length of the lines (AKA depends on the board), though it might also depend on pullup values as well and somewhat on the card? This number needs to be tuned (like link training) when you operate a card at > 50MHz. * For ciu-div: With a ciu-div of 3 (really 3+1 = 4) you get phase offsets of 45 degrees. With a ciu-div of 1 (really 1+1 = 2) you get phase offsets of 90 degrees. WIth a ciu-div of 0 (really 0+1 = 1) you get no phase offsets (I would have guessed 180, but manual says otherwise) So ciu-div intimately affects the sdr-timing and ddr-timing. Thus if those are board-specific then so is ciu-div. --- All of the above suggests to me the following untested things: * If you happened to have a situation where you had a "ciu-div" of 3 and all of your sdr-timing/ddr-timing values were even, you could cut the input clock in half, change "ciu-div" to 1, and cut all your timings in half. I'd imagine that would save you power (better to slow clocks down higher in the clock tree?). It would be sorta nice if this was done automatically (assuming that you have full control of input clock). * I'm a little unclear exactly how the CLKDIV register interacts with all of the above. I guess I'd be under the assumption that the CLKDIV applies to the main clock, the sample clock, and the drive clock. ...but maybe I'm confused. I think you also get different results (in terms of how many ns the drive and sample are delayed) depending on whether the CLKDIV applies _after_ ciu-div or before. My guess is that it applies after. --- Anyway, not sure that helps a whole lot, but that's a summary of what I've come to understand. I'm happy to be enlightened. I'm still trying to figure how how these numbers were picked for our hardware and whether those numbers are actually right. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |