[RFC PATCH 0/3] PM / clock_ops: allow to specify custom pm_clk_notifier callback

[khilman@linaro.org (Kevin Hilman)]

Grygorii Strashko <grygorii.strashko@ti.com> writes:

> The CLK PM domain (clock_ops.c) assumes that platform code should always provide
> list of Connection IDs of the clock (con_id) in pm_clk_notifier_block structure.
> Then CLK PM domain uses these con_ids to setup list of clocks per device.
>
> Such approach is inconvenient when devices can have different number
> of clocks. For example, if maximum number of clocks used by
> devices is 4 the pm_clk_notifier_block structure will look like:
>
> static struct pm_clk_notifier_block platform_domain_notifier = {
> 	.pm_domain = &keystone_pm_domain,
> 	.con_ids = { "fck", "opt1", "opt2", "opt3", NULL },
> };
>
> More over, clocks in DT have to be named using only above con_ids:
> 	clocks = <&paclk13>, <&clkcpgmac>, <&chipclk12>;
> 	clock-names = "fck", "opt1", "opt2";
>
> It makes hard to enable/support Runtime PM in case when some HW modules are used
> by different SoCs or there are few version of the same SoC, because clock trees
> can be changed significantly in all such cases.
>
> This patch set allows to specify custom pm_clk_notifier callback from
> platform code and in such way makes CLK PM domain initialization
> more flexible. 

Replacing the pm_clk notifier is essentially replacing the guts of the
clock_ops code.

I think your platform may have left the realm of "simple" platforms that
the clock_ops was intended for.

Since you're essentially gutting clock_ops, have you considered
migrating to genpd and having your own pm_domain ops that manage your clocks?

> Also, It updates Keystone 2 platform code to provide custom
> callback which fills list of clocks for Device with all clocks assigned to this
> Device in DT.
> More over, It's safe for Keystone 2 to perform CLK PM domain initialization
> at device's binding time instead of device's creation time.
>
> I've posted these patches because I need fully enable Runtime PM on Keystone 2
> where all HW modules are controlled using clocks only. That's why CLK PM domain 
> fits our needs perfectly. 

Heh, doesn't seem like a perfect fit to me ;)

> Also, on Keystone 2 clocks are initialized early and
> they are available at device creation time. The main problems from my side are:
>  - every time when support for new HW modules is added the ".con_ids" array 
>    need to be checked and updated;
>  - restriction for clock's names in DT - to be named using only above con_ids
>    It's ugly.
>
> I hope, this approach to be accepted at least as temporal solution until 
> the generic solution is not found.

Sorry if I missed it, but is there ongoing discussion of a more generic
solution other than this one:

> [1] Previously, same problem was discussed in, but no final solution was accepted:
>  "[PATCH/RFC 0/4] of: Register clocks for Runtime PM with PM core"
>  https://lkml.org/lkml/2014/4/24/1118

Personally, I still like Geert's approach better.

Kevin