Re: [PATCH 1/3] [RFC] PM: domains: Introduce .power_pre/post_on/off callbacks

[Marek Vasut <marex@denx.de>]

On 11/14/22 20:40, Ulf Hansson wrote:
> On Tue, 8 Nov 2022 at 02:35, Marek Vasut <marex@denx.de> wrote:
>>
>> Currently it is possible that a power domain power on or off would claim
>> the genpd lock first and clock core prepare_lock second, while another
>> thread could do the reverse, and this would trigger lockdep warning.
> 
> I am not quite sure I fully understand. In this case is the lockdep
> warning relevant or just something that we want to silence?

This is a valid problem, see patches 2/3 and 3/3 for details too.

>> Introduce new callbacks, .power_pre/post_on() and .power_off_pre/post(), which
>> are triggered before the genpd_lock() and after genpd_unlock() respectively in
>> case the domain is powered on and off. Those are meant to let drivers claim
>> clock core prepare_lock via clk_*prepare() call and release the lock via
>> clk_*unprepare() call to always assure that the clock and genpd lock ordering
>> is correct.
> 
> To me, this sounds like a problem that may be better fixed by trying
> to model the parent/child-domains in a more strict way, through genpd.
> 
> There is a comment in the code in imx8mp_blk_ctrl_probe() that seems
> to be pointing in this direction too.
> 
> "* We use runtime PM to trigger power on/off of the upstream GPC
>    * domain, as a strict hierarchical parent/child power domain
>    * setup doesn't allow us to meet the sequencing requirements......"
> 
> I am wondering about what those "sequencing requirements" are - and
> whether it could make better sense to fix these issues instead?

Here is the lockdep splat:

https://lore.kernel.org/all/Y1cs++TV2GCuh4tS@pendragon.ideasonboard.com/

It really is a problem between the clock and genpd subsystem locks, they 
can be claimed in arbitrary order, see patch 2/3 and 3/3.

I think that might clarify what I am attempting to solve here.

[...]