On 8 September 2016 at 02:19, Stephen Boyd <sboyd@xxxxxxxxxxxxxx> wrote: > On 09/01, Marek Szyprowski wrote: >> Registers for some clocks might be located in the SOC area, which are under the >> power domain. To enable access to those registers respective domain has to be >> turned on. Additionally, registers for such clocks will usually loose its >> contents when power domain is turned off, so additional saving and restoring of >> them might be needed in the clock controller driver. >> >> This patch adds basic infrastructure in the clocks core to allow implementing >> driver for such clocks under power domains. Clock provider can supply a >> struct device pointer, which is the used by clock core for tracking and managing >> clock's controller runtime pm state. Each clk_prepare() operation >> will first call pm_runtime_get_sync() on the supplied device, while >> clk_unprepare() will do pm_runtime_put() at the end. >> >> Additional calls to pm_runtime_get/put functions are required to ensure that any >> register access (like calculating/chaning clock rates) will be done with clock >> controller in active runtime state. >> >> Special handling of the case when runtime pm is disabled for clock controller's >> device is needed to let this feature work properly also during system sleep >> suspend/resume operations (runtime pm is first disabled before entering sleep >> state's, but controller is usually still operational until its suspend pm >> callback is called). >> >> Signed-off-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> > > My "knee jerk" concern is that we're going to take a runtime PM > lock underneath the prepare lock. That seems like a situation > where we could hit a lock inversion if the runtime PM callbacks > themselves acquire the prepare lock by calling clk APIs? But this > concern is false right? We release the runtime PM lock before > calling the PM callback, so we shouldn't hit any deadlock and > lockdep won't complain? You assumption is correct! Before the runtime PM core invokes a runtime PM callback it will unlock the -">dev->power.lock" spinlock. When the callback returns it will re-lock the spinlock. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |