[PATCH 2/2] soc: imx: gpcv2: prepare bus clocks early
Lucas Stach
l.stach at pengutronix.de
Fri Jun 2 13:06:13 PDT 2023
Hi Marek,
Am Freitag, dem 02.06.2023 um 21:12 +0200 schrieb Marek Vasut:
> On 6/2/23 20:54, Lucas Stach wrote:
> > Prepare the bus clocks during PGC domain driver probe. This avoids a
> > potential deadlock when there a clock providers inside the domain,
> > as this might end up trying to take the CCF prepare_lock from two
> > different contexts, when runtime PM is trying to resume the PGC domain
> > for the clock provider. By keeping the bus clocks prepared as long as
> > there is a PGC domain driver attached, we don't need to take the
> > prepare_lock in the domain power up/down paths.
> >
> > We don't want to do this for regular reset clocks, as this might lead
> > to some PLLs being kept prepared that could otherwise be shut down.
> > For the bus clocks this isn't a concern, as all the bus clocks are
> > derived from always-on system PLLs.
> >
> > Signed-off-by: Lucas Stach <l.stach at pengutronix.de>
> > ---
>
[...]
> Isn't this similar approach to
>
> [PATCH] [RFC] soc: imx: gpcv2: Split clock prepare from clock enable in
> the domain
>
> where Laurent (now on CC) reported that this still causes issues ?
>
> If not, then please ignore my comment here.
Yes, that's right. It doesn't solve the clock provider (HDMI PHY) is
inside a power domain itself issue.
However it resolves the simple cases where we would deadlock due to the
needed bus clocks, which is what happens when audiomix adds runtime PM
support. So I still think it's a good idea in general, even if it
doesn't solve all the problems.
Regards,
Lucas
More information about the linux-arm-kernel
mailing list