From mboxrd@z Thu Jan 1 00:00:00 1970 From: sboyd@codeaurora.org (Stephen Boyd) Date: Wed, 14 Sep 2016 14:39:03 -0700 Subject: [PATCH 1/5] clk: add support for runtime pm In-Reply-To: References: <1472737551-15272-1-git-send-email-m.szyprowski@samsung.com> <1472737551-15272-2-git-send-email-m.szyprowski@samsung.com> <20160908001943.GC13062@codeaurora.org> <20160912223105.GI7243@codeaurora.org> Message-ID: <20160914213903.GG7243@codeaurora.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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