| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <d4447e52-81de-0ab6-7bd9-016a59f915a5@kernel-upstream.org>
Date: Thu, 12 May 2016 11:03:55 +0800
From: Shawn Lin <shawn.lin@...nel-upstream.org>
To: Doug Anderson <dianders@...omium.org>,
Shawn Lin <shawn.lin@...k-chips.com>
Cc: Jaehoon Chung <jh80.chung@...sung.com>,
Ulf Hansson <ulf.hansson@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Brian Norris <briannorris@...omium.org>,
Heiko Stuebner <heiko@...ech.de>,
"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH 2/2] dt-bindings: rockchip-dw-mshc: add
rockchip,default-drv-phase
在 2016/5/12 5:42, Doug Anderson 写道:
> Shawn,
>
> On Wed, May 11, 2016 at 1:25 AM, Shawn Lin <shawn.lin@...k-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@...k-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@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Powered by blists - more mailing lists