[PATCH 1/5] clk: add support for runtime pm

[Marek Szyprowski]

Hi Stephen,


On 2016-09-14 23:39, Stephen Boyd wrote:
> On 09/13, Marek Szyprowski wrote:
>> On 2016-09-13 00:31, Stephen Boyd wrote:
>>> Great! So you have runtime PM callbacks that are calling
>>> clk_prepare/unprepare?
>> Well, not really. clock controller's runtime pm functions must not call
>> clk_prepare/unprepare yet.
>>
>> I didn't get your question. I thought that you are asking if my change
>> won't introduce any deadlock related to prepare and dev->pm locks. My
>> runtime pm functions doesn't do any call to clk_prepare/unprepare.
>> Although global clock prepare lock is re-entrant from the same process, it
>> would cause deadlock if called from runtime pm functions, because runtime
>> pm functions might be called from the worker running on the different
>> cpu/process.
> I mean non-clk controller driver based runtime PM callbacks that
> call clk_prepare/unprepare in them. For example, some i2c or spi
> device driver that has clk operations in the runtime PM
> callbacks. That would allow lockdep to see any potential deadlock
> because of aliasing lock classes for the device power lock and
> the global prepare lock.

This works perfectly fine. Runtime pm callbacks are called with power lock
released, so there is no deadlock possible related to dev->power.lock.
See __rpm_callback() function in drivers/base/power/runtime.c

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland