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

From: [email-masked] (Stephen Boyd)
Date: Wed, 14 Sep 2016 14:39:03 -0700

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.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project