linux-kernel - Re: [PATCH 2/2] clk: rockchip: fix the rk3399 sdmmc sample shift

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]

Date:	Fri, 13 May 2016 15:46:54 +0800
From:	Shawn Lin <shawn.lin@...k-chips.com>
To:	Doug Anderson <dianders@...omium.org>
Cc:	shawn.lin@...k-chips.com, Brian Norris <briannorris@...omium.org>,
	Heiko Stuebner <heiko@...ech.de>,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Xing Zheng <zhengxing@...k-chips.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	linux-clk <linux-clk@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 2/2] clk: rockchip: fix the rk3399 sdmmc sample shift

在 2016/5/13 12:36, Doug Anderson 写道:
> Shawn,
>
> On Thu, May 12, 2016 at 4:47 PM, Shawn Lin <shawn.lin@...k-chips.com> wrote:
>> 在 2016/5/13 7:10, Brian Norris 写道:
>>>
>>> On Thu, May 12, 2016 at 11:03:17AM -0700, Doug Anderson wrote:
>>>>
>>>> Just like every other Rockhip device, the MMC "_sample" clocks should
>>>> have a shift of 0, not a shift of 1.  The rk3399 TRM agrees.  Presumably
>>>> these values were set to 0 because of a typo.
>>>
>>>
>>> I'll semi-disagree about the TRM: the TRM doesn't seem to agree with
>>> itself, so it sometimes agrees with you and sometimes doesn't :)
>>>
>>> On page 79 of the 2nd (?) book, it looks like {SDMMC,SDIO}_CON{0,}[2:1]
>>> are {drv,sample}_degree. But on page 208 of the 1st book, those are put
>>> at bits [1:0].
>>>
>>
>>
>> Please refer to Mobile Strorage Host Controller section for anything
>> about sdmmc/sdio. So shift should be 1.
>>
>> Sometime I also get bothered to address it. Anyway, I will always keep
>> a eye on it from now on.....
>
> I still in general have mistrust for TRM docs for things like this.
> Have you verified that this was an intentional change for rk3399, or
> could it be a  typo?  Typically SoCs don't change this type of stuff
> for no reason.
>

Typically it doesn't, but the reality is that {SDMMC,SDIO}_CON{0,}[2:1]
for drv/sample_degree both. Obviously they want to make drv stuff the
same layout as sampe stuff...

> This should be possible to verify in one of two ways.  If the TRM has
> a typo and things truly _do_ start at 0 instead of 1, then:
>
> 1. There will be roughly mirrors of valid ranges.
> 2. Things won't match up if we change tuning to use 180 course offsets
> and the rest fine offsets.
>
> It would be ideal if you could confirm with the chip guys, but if you

I have checked it before Xing upstreamed the code, but as your question 
on the TRM, I check it with the  chip guys again.

So the answer is that drv/sample stuff should refer to  Mobile Strorage
Host Controller section, and it will fit the future Socs from now on.


> can't I'll try to do more tests tomorrow.



>
>
>


-- 
Best Regards
Shawn Lin