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.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
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
