? 2016/5/12 5:42, Doug Anderson ??: > Shawn, > > On Wed, May 11, 2016 at 1:25 AM, Shawn Lin <shawn.lin at rock-chips.com> wrote: >> On 2016/5/11 11:50, Doug Anderson wrote: >>> >>> Hi, >>> >>> On Tue, May 10, 2016 at 7:50 PM, Shawn Lin <shawn.lin at rock-chips.com> >>> wrote: >>>>>> >>>>>> 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. >>> >>> >>> OK, I sent out a patch for 180 always. I can send v2 to use 90 for >>> DDR modes tomorrow. ...or feel free to post that yourself if you >>> want. >>> >>> We want 90 for all DDR modes? So MMC_TIMING_UHS_DDR50, >>> MMC_TIMING_MMC_DDR52, MMC_TIMING_MMC_HS400? (not that we support HS400 >>> in dw_mmc on Rockchip). >> >> >> Right. > > OK, so I dug into this more. I don't think it's actually quite that > simple. The Designware databook explicitly states that 'MMC DDR > 8-bit' should use 180, not 90. ...but that's probably explained by > the fact that "cclk_in" for MMC-DDR 8-bit is double what you'd expect. > You can see that in code: > > if (ios->bus_width == MMC_BUS_WIDTH_8 && > ios->timing == MMC_TIMING_MMC_DDR52) > cclkin = 2 * ios->clock * RK3288_CLKGEN_DIV; Yes, this requirment is from dw_mmc databook(v270a), table 10-5. But you can see that we didn't handle MMC_TIMING_UHS_SDR12. As recommended, MMC_TIMING_UHS_SDR12 mode need to 50M here to make the internal devider to be "1". Because Figure 10-3 (Clock Structure for Host Controller) assumes Soc only supplies 50M/100M/200M, these three frequency selection, to cclk_in. So SDR12 should be 50M/2 = 25M. But for Rockchip Socs, we have RK3288_CLKGEN_DIV before cclk_in that means we don't follow this table. For DDR52-8bit, it's a mandatory requirment to use 100M as cclk_in. > > --- > > tl;dr of all the below: > > * For SD: use 180 for SDR104 to get margin, use 90 elsewhere. > * For mmc, use 180 for DDR52 to meet timings, use 180 for HS200 to get > margin, use 90 elsewhere yes, see the comments blow. > > > The nice thing about this is, at least for rk3288, things don't change > much from today where we use 90 degrees for most SD cards. > > --- > > For new patch, see: <https://patchwork.kernel.org/patch/9075141/> > > --- > > Details: > > So assuming measurements I saw from an EE are correct, measured > "delay_o_ns" is ~ .5 ns for rk3399. With that, we can do some math. Soc specific. But it's a trivial margin. > Please correct any mistakes. Math is hard. Note that on all Rockchip > devices I've seen pins are limited to 150 MHz and when we choose 150 > MHz we end up at 148.5 MHz. Calculations aren't too different if we > use 150 for that case. > > > MMC_TIMING_MMC_DDR52: > min hold time = 2.5 ns > min data delay = 2.5 ns + .5 ns = 3 ns > with 100 MHz clock, 90 degree: 2.5 ns > with 100 MHz clock, 180 degree: 5.0 ns > > ...need 180 degree > When running in DDR52-8bit, 2 cycle of cclk_in is used for a single data bit internally. When shifting cclk_in_drv to 180, we can see: cclk_in ____ ____ ____ ____ ___ __| |____| |____| |____| |____| cclk_in_drv-180 ____ ____ ____ ____ ___ __| |____| |____| |____| |____| cclk_in_for_DDR52-8bit _________ _____ __| |_________| So cclk_in_drv shifts 180 from cclk_in, which means it's just in the 90 degrees of cclk_in_for_DDR52-8bit. That is what I'd expect that when running in DDR mode, the cclk_in_drv should be in the 90 degree of *Actual Internal CLK*, not cclk_in always. But fot SD DDR50-4bit, it just use cclk_in internlly, so 90 should be okay. So we were not in the same page of what the ref-clk is. But I think now we are in. Agree on all the calculation below. > -- > > SD DDR50: > min hold time = .8 ns > min data delay = .8 ns + .5 ns = 1.3 ns > with 50 MHz clock, 90 degree: 5 ns > with 50 MHz clock, 180 degree: 10 ns > > ...90 degree is good and 180 is massive overkill. Use 90. > > -- > > SD SDR104 (limited to 148.5 MHz on existing Rockchip parts): > min hold time = .8 ns > min data delay = .8 ns + .5 ns = 1.3 ns > with 148.5 MHz clock, 90 degree: 1.68 ns > with 148.5 MHz clock, 180 degree: 3.37 ns > > ...so 90 degrees would probably work OK, but 180 degrees gives more margin. > ...probably explains why existing rk3288 devices w/ 90 degree work OK. > > if we had 200 MHz clock, 90 degree: 1.25 ns > if we had 200 MHz clock, 180 degree: 2.50 ns > > -- > > SD SDR50: > min hold time = .8 ns > min data delay = .8 ns + .5 ns = 1.3 ns > with 100 MHz clock, 90 degree: 2.5 ns > with 100 MHz clock, 180 degree: 5.0 ns > > ...90 degree is great w/ plenty of margin > > -- > > SD SDR25: > min hold time = 2 ns > min data delay = 2 ns + .5 ns = 2.5 ns > with 50 MHz clock, 90 degree: 5 ns > with 50 MHz clock, 180 degree: 10 ns > > ...90 degree is good and 180 is massive overkill. Use 90. > > -- > > SD SDR12 (databook shows cclk_in as 50 MHz here we'll get 25 MHz): > min hold time = 5 ns > min data delay = 5 ns + .5 ns = 5.5 ns > with 25 MHz clock, 90 degree: 10 ns > with 25 MHz clock, 180 degree: 20 ns > > ...90 degree is good (databook suggests 180 for this mode due to cclk_in = 50) > > -- > > ID Mode > min hold time = 5 ns > min data delay = 5 ns + .5 ns = 5.5 ns > with 400 kHz clock, 90 degree: 625 ns > with 400 kHz clock, 180 degree: 1250 ns > > ...90 degree is good (databook suggests 180 for this mode due to > cclk_in = 50) > > -- > > MMC High speed: > min hold time = 2.5 ns > min data delay = 2.5 ns + .5 ns = 3 ns > with 50 MHz clock, 90 degree: 5 ns > with 50 MHz clock, 180 degree: 10 ns > > ...90 degree is good > > -- > > HS200: > min hold time (tIH from JEDEC spec): .8 ns > ...math all works out the same as SDR104. > > -- > > HS400: > we don't support it anyway > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
