linux-kernel - Re: [PATCH 2/2] dt-bindings: rockchip-dw-mshc: add rockchip,default-drv-phase

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e202f663-88d7-693b-a765-c130e68d1c2d@rock-chips.com>
Date:	Wed, 11 May 2016 10:50:17 +0800
From:	Shawn Lin <shawn.lin@...k-chips.com>
To:	Doug Anderson <dianders@...omium.org>
Cc:	shawn.lin@...k-chips.com, 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

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