On 09/12, Marek Szyprowski wrote: > Hi Stephen, > > > On 2016-09-08 02:19, Stephen Boyd 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? > > Runtime PM uses fine grained locking based on per-device locks, so there > should be no problem with global clock prepare lock. The only lock > interaction > is between clock controller device's rpm lock and clocks global > prepare lock, but > it always done with the same access pattern. I've tested it > extensively (also > with lock dep) with various use cases and found no problems. > Great! So you have runtime PM callbacks that are calling clk_prepare/unprepare? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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
 |