linux-kernel - Re: [PATCH] clk: rockchip: add pclk_vio

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:	Mon, 13 Jun 2016 20:49:39 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	Xing Zheng <zhengxing@...k-chips.com>
Cc:	Heiko Stübner <heiko@...ech.de>,
	elaine zhang <elaine.zhang@...k-chips.com>,
	Tao Huang <huangtao@...k-chips.com>,
	Brian Norris <briannorris@...omium.org>,
	Yakir Yang <ykk@...k-chips.com>,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	linux-clk <linux-clk@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] clk: rockchip: add pclk_vio_grf to critical clock on the RK3399

Hi,

On Mon, Jun 13, 2016 at 8:02 PM, Xing Zheng <zhengxing@...k-chips.com> wrote:
> Hi Doug,
>
> On 2016年06月14日 07:46, Doug Anderson wrote:
>>
>>
>> Even if it's not much power, it seems like we should still turn it off
>> and on in the right place.  Unless I'm mistaken it should be such a
>> simple patch provide the clock to the right driver and then get the
>> clock when appropriate.
>
> Yes, I talked with Yakir and we intent to enable/disable the pclk_vio_grf in
> video drivers,
> so this patch will be dropped.
>>>
>>> I will refer the latest TRM to update a new patch for always enable these
>>> GRFs.
>>
>> Does that mean you're going to make these all critical clocks?  That
>> doesn't sound so great...
>>
>> -Doug
>
> Maybe, I heard that they are removed in the updated TRM, but I have not got
> the TRM yet.
> I will double check it, and it seems that you do not agree to remove these
> clock...

Well, if it were to be removed from the TRM then that would be a
strong sign that the SoC designers think that this clock should never
ever be turned off.  If that were the case I don't think I could
object to leaving this clock on all the time.  Presumably then we'd
totally remove the clock from the clock tree and rely on firmware to
leave it on?  Technically removing this clock is not really
device-tree backward compatible, but I guess if there are no current
users...

...note: if the clock IS listed in the TRM and there's ever a chance
that we'd want to turn it off, it's much easier to set that up all
now.  Trying to later go in and decide that these clocks are no longer
"always on" gets into all sorts of weird device tree backward
compatibility corner cases.

-Doug