On 30 April 2015 at 08:21, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > On 29 April 2015 at 15:08, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: >> Hi Ulf, >> >> On Wed, Apr 29, 2015 at 2:31 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> 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. Correction: Of course they can register one PM clk notifier per bus type. The API currently also provides this option. > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
