[RFC/RFT 2/6] clk: qcom: Add runtime support to handle clocks using PM clocks

[Ulf Hansson]

On 29 April 2015 at 15:08, Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> Hi Ulf,
>
> On Wed, Apr 29, 2015 at 2:31 PM, Ulf Hansson <ulf.hansson at linaro.org> wrote:
>>>> Geert, thanks, I was wondering how you handle the !CONFIG_PM case for
>>>> rmobile. I mean who turns the clocks on for the devices when you build
>>>> with CONFIG_PM disabled?
>>>
>>> We still use pm_clk_add_notifier() in drivers/sh/pm_runtime.c if
>>> CONFIG_PM_GENERIC_DOMAINS_OF=n. Hence the second instance of
>>> pm_clk_notify() will enable the clocks at driver binding time.
>>> Hardware power domains are assumed enabled by reset state/the boot
>>> loader.
>>
>> Yes, it a bit tricky - but I guess that's the current only viable
>> solution if we have when using the pm_clk API.
>>
>>> Given the amount of PM infrastructure involved when hardware power and
>>> clock domains are involved, I think at one point we'll have to start restricting
>>> our builds to CONFIG_PM=y.
>>
>> I don't think that would solve the problem, since you may still have
>> cross SoC drivers which may be used without CONFIG_PM.
>
> That's not as much of a problem as it sounds:
>   - If the driver cares (needs to know) about the clock, it should already
>     manage it itself.

Agree!

>   - If it doesn't care about the clock, it just needs Runtime PM support.
>     That will do the right thing on platforms with (needs PM=y) and without
>     (doesn't care about PM=x) clock domains.

How about those drivers that cares about clocks and thus manages them,
but also cares about runtime PM?

I believe we will get a clock reference count issue in these cases,
since both the PM domain and the driver will manage the clocks.

I assume that's why we have had a few attempts to have "runtime PM
clocks" specially marked, one was via DT, to have clear distinguish
between who will be responsible to manage them.

Those attempts did get nacked, so the problem is still there I assume.

> So the bigger "problem" is making sure all drivers have at least minimal
> Runtime PM support, else they can't be reused as-is on systems with PM
> domains.
>
>> So all SoC that uses a driver which expects clocks to be managed using
>> PM clocks from a PM domain, will need the above "trick". Right?
>
> One remaining issue with pm_clk_add_notifier() is that it applies to all
> platform devices in the system, not just the on-SoC devices. Hence it may
> inadvertently manage clocks for off-SoC devices it's not supposed to touch.

Yes. That's really bad. :-)

Additionally, it means devices that isn't part of the platform bus
isn't able to use PM clk domains at all.

Within this context, I find it hard to advise people to use PM clk
domains (via pm_clk_add_notifier()), since there just so many open
issues. What works a _little_ better is to use PM clks via genpd.

Kind regards
Uffe