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

[maxime.coquelin@st.com (Maxime Coquelin)]

On 03/20/2014 01:42 PM, Sylwester Nawrocki wrote:
> 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.
No problem! Apologies accepted ;)

>
> IIUC your first concern is about a situation when clocks need to be
> reconfigured upon each resume from system sleep or runtime PM resume ?

Yes. This is the case of the STi SoCs.
When resuming from system sleep, the clocks-related registers are 
restored at their boot state.

> 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.
 From a functional point of view, that would indeed resolve the PM 
related issue.
But I'm not sure that on a performance point of view, parsing the DT at 
each driver's resume call is an efficient way.

> 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.
Yes, that's another case to handle.
I don't know which platforms are in that case, but not STi SoCs for your 
information.

>
> 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).
OK, I agree with the approach.
There is still the PM issue remaining with these clocks, but I think 
that is not related to your series as we already have the issue currently.

Thanks,
Maxime

>
> --
> Regards,
> Sylwester
>
> [1] http://www.spinics.net/lists/arm-kernel/msg310507.html
> [2] http://www.spinics.net/lists/linux-omap/msg103069.html
>