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