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
--
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
