From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751949AbcELDEo (ORCPT ); Wed, 11 May 2016 23:04:44 -0400 Received: from mr213139.mail.yeah.net ([223.252.213.139]:14218 "EHLO mr213139.mail.yeah.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751530AbcELDEm (ORCPT ); Wed, 11 May 2016 23:04:42 -0400 Subject: Re: [PATCH 2/2] dt-bindings: rockchip-dw-mshc: add rockchip,default-drv-phase To: Doug Anderson , Shawn Lin References: <1462527648-24443-1-git-send-email-shawn.lin@rock-chips.com> <1462527673-24711-1-git-send-email-shawn.lin@rock-chips.com> <1f2f43c7-2672-e448-eddb-2d613bb8dc48@rock-chips.com> <2994d365-2cf2-0990-6c10-2abeebb42eef@rock-chips.com> Cc: Jaehoon Chung , Ulf Hansson , Rob Herring , "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Brian Norris , Heiko Stuebner , "open list:ARM/Rockchip SoC..." , "devicetree@vger.kernel.org" From: Shawn Lin Message-ID: Date: Thu, 12 May 2016 11:03:55 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-HM-Spam-Status: e1koWUFPN1dZCBgUCR5ZQVZKVUNNSEtLS0pOT09CTklIQkhXWQkOFx4IWU FZKCs9JDU#Li8pOjckMjUkMz46Pz4pQUtVS0A2IyQiPigkMjUkMz46Pz4pQUtVS0ArLykkNTQkMj UkMz46Pz4pQUtVS0A4NC41LykiJDg1QUtVS0ApPjwyNDUkOigyOkFLVUtAKyk0LTI1OD4kPS4xMj o1QUtVS0A*IjU6NjI4JDIrJDU0JDI1JDM#Oj8#KUFLVUtANi43LzIkKTgrLyQ*Mj09Pik#NS8kMj UkMz46Pz4pQUlVS0AyKyROJDYyNS4vPiQ4NS8kSyRKS0FLVUtAMiskSiQ2MjUuLz4kODUvJEskSk tBS1VLQDIrJC80PzoiJDg1LyRLJEpLS0FLVUtAMiskSiQzNC4pJDg1LyRLJEpLS0FLVUtAMiskSE skNjI1Li8#JDg1LyRLJE5LQUtVS0AoLjkxPjgvJE4kNjI1Li8#JDg1LyRLJEpLQUtVS0AoLjkxPj gvJC80PzoiJDg1LyRLJEpLS0FLVUtAKC45MT44LyRKJDM0LikkODUvJEskSktLQUtVS0AoOTEkNz 41JE9LJCNBS1VLS0pLQC8#Iy8kNz41JEpJQ0skI0FLVUtLSktAODUvJDMvNjckNz41JE4wJEpLME FLVUtLSktAKT44PjItPikkODUvJE4kI0FLVUtLSktAIzY6Mjc#KSQ1Ljc3QUtVS0tKS0A*PjcyLT 4pJDc#NSRLQUtVS0tKS0A3OjU8JD41QUtVS0tKS0A9NSQuKTckMy8vKygkMzcxJEtDS0pLQ0FLVU tAPTUkNjoiJE9KQiQzNzEkSiRLQ0tIS09BS1VISEA9KyQpPiQ9LCQzNzEkS0NLSEtNQVZMVU5AKC 45JD5BSlVOTkA9NSQ9KT4#JDM3MSRLTEtOS09BSlVMTlkG X-HM-Sender-Digest: e1kSHx4VD1lBWUc6Pio6Djo5HTo1M04fPiwQEz4jShkaCjNVSlVKT01I S0lJSUxNTUlLVTMWGhIXVQgTGgwVVRcSFTsQHgkVHhdWDgsIDwkeGhZVFAkcRVlXWQweGVlBHRoX CB5XWQgBWUFKS09KQjdXWRILWUFZTkNVSUlVTFVKSk9ZBg++ X-HM-Tid: 0a54a2ec4d597d8b916231c1e6d Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2016/5/12 5:42, Doug Anderson 写道: > Shawn, > > On Wed, May 11, 2016 at 1:25 AM, Shawn Lin wrote: >> On 2016/5/11 11:50, Doug Anderson wrote: >>> >>> Hi, >>> >>> On Tue, May 10, 2016 at 7:50 PM, Shawn Lin >>> 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: > > --- > > 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >