linux-kernel - Re: [RFC PATCH v2 0/2] clk: Support for DT assigned clock parents and rates

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: <532AE239.9000800@samsung.com>
Date:	Thu, 20 Mar 2014 13:42:33 +0100
From:	Sylwester Nawrocki <s.nawrocki@...sung.com>
To:	Maxime Coquelin <maxime.coquelin@...com>,
	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org
Cc:	mark.rutland@....com, mturquette@...aro.org,
	gregkh@...uxfoundation.org, t.figa@...sung.com,
	sw0312.kim@...sung.com, linux-kernel@...r.kernel.org,
	kyungmin.park@...sung.com, robh+dt@...nel.org,
	galak@...eaurora.org, grant.likely@...aro.org,
	linux@....linux.org.uk, m.szyprowski@...sung.com, t-kristo@...com
Subject: Re: [RFC PATCH v2 0/2] clk: Support for DT assigned clock parents and
 rates

Hi Maxime,

On 06/03/14 14:45, Maxime Coquelin wrote:
> Hi Sylwester,
> 
> 	I like the principle of your implementation, but I have two questions:
> 	1 - How can we manage PM with this solution, as the parent/rate will be 
> set only once at probe time?
> 	2 - How to set the parent of a parent clock (which can be shared with 
> other devices)? Same question about the parent rates.

Thanks for your feedback and apologies for late reply.

IIUC your first concern is about a situation when clocks need to be
reconfigured upon each resume from system sleep or runtime PM resume ?
As I mentioned in v1 of the RFC I was considering having individual
drivers calling explicitly the clocks set up routine. Presumably this
would allow to resolve the power management related issue.
One example I'm aware the approach as in this RFC wouldn't work is
when a device in a SoC belongs to a power domain, which needs to be
first switched on before we can start setting up and the clocks'
configuration get lost after the power domain switch off.

OTOH I suspect devices for which one-time clocks setup is sufficient
will be quite common. And for these there would need to be a single
call to the setup routine in probe() I guess, since it wouldn't be
possible to figure out just from the DT data when the actual call
should be made.

For a global clocks configuration, I thought about specifying that
in the clocks controller node, and then to have the setup routine
called e.g. from of_clk_init(). I think that could work well enough,
together with the patch [1], adding clock dependencies handling.
But then the clock frequency set up function would need to be
modified to respect the clock parent relationships, similarly as
in patch series [2]. A just noticed [2] recently, after posting
this RFC (adding Tero at Cc).

--
Regards,
Sylwester

[1] http://www.spinics.net/lists/arm-kernel/msg310507.html
[2] http://www.spinics.net/lists/linux-omap/msg103069.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/