[PATCH RFC 2/2] pmdomain: ti-sci: Support retaining PD boot time state
Tomi Valkeinen
tomi.valkeinen at ideasonboard.com
Mon Apr 15 10:17:00 PDT 2024
On 15/04/2024 19:00, Tomi Valkeinen wrote:
> Add a new flag, TI_SCI_PD_KEEP_BOOT_STATE, which can be set in the dts
> when referring to power domains. When this flag is set, the ti-sci
> driver will check if the PD is currently enabled in the HW, and if so,
> set the GENPD_FLAG_ALWAYS_ON flag so that the PD will stay enabled.
>
> The main issue I'm trying to solve here is this:
>
> If the Display Subsystem (DSS) has been enabled by the bootloader, the
> related PD has also been enabled in the HW. When the tidss driver
> probes, the driver framework will automatically enable the PD. While
> executing the probe function it is very common for the probe to return
> EPROBE_DEFER, and, in rarer cases, an actual error. When this happens
> (probe() returns an error), the driver framework will automatically
> disable the related PD.
>
> Powering off the PD while the DSS is enabled and displaying a picture
> will cause the DSS HW to enter a bad state, from which (afaik) it can't
> be woken up except with full power-cycle. Trying to access the DSS in
> this state (e.g. when retrying the probe) will usually cause the board
> to hang sooner or later.
>
> Even if we wouldn't have this board-hangs issue, it's nice to be able to
> keep the DSS PD enabled: we want to keep the DSS enabled when the
> bootloader has enabled the screen. If, instead, we disable the PD at the
> first EPROBE_DEFER, the screen will (probably) go black.
A few things occurred to me. The driver is supposed to clear the
GENPD_FLAG_ALWAYS_ON when the driver has probed successfully. There are
two possible issues with that:
- Afaics, there's no API to do that, and currently I just clear the bit
in genpd->flags. There's a clear race there, so some locking would be
required.
- This uses the GENPD_FLAG_ALWAYS_ON flag to say "PD is always on, until
the driver has started". If the PD would have GENPD_FLAG_ALWAYS_ON set
for other reasons, the driver would still go and clear the flag, which
might break things.
Also, unrelated to the above and not a problem in practice at the very
moment, but I think clocks should also be dealt with somehow. Something,
at early-ish boot stage, should mark the relevant clocks as in use, so
that there's no chance they would be turned off when the main kernel has
started (the main display driver is often a module).
It would be nice to deal with all the above in a single place. I wonder
if the tidss driver itself could somehow be split into two parts, an
early part that would probe with minimal dependencies, mainly to reserve
the core resources without doing any kind of DRM init. And a main part
which would (somehow) finish the initialization at a later point, when
we have the filesystem (for firmware) and the other bridge/panel drivers
have probed.
That can be somewhat achieved with simplefb or simpledrm, though, but we
can't do any TI DSS specific things there, and it also creates a
requirement to have either of those drivers built-in, and the related DT
nodes to be added.
Tomi
> Another option here would perhaps be to change the driver framework
> (drivers/base/platform.c) which attaches and detaches the PD, and make
> it somehow optional, allowing the driver the manage the PD. That option
> has two downsides: 1) the driver _has_ to manage the PD, which would
> rule out the use of simplefb and simpledrm, and 2) it would leave the PD
> in off state from Linux's perspective until a driver enables the PD, and
> that might mean that the PD gets actually disabled as part of normal
> system wide power management (disabling unused resources).
>
> Yet another option would be to do this outside the ti_sci_pm_domains
> driver: a piece of code that would somehow be ran after the
> ti_sci_pm_domains driver has probed (so that we have the PDs), but
> before tidss/simplefb/simpledrm probes. The problem here is the
> "somehow" part. Also, this would partly have the same issue 2) as
> mentioned above.
>
> TODO: If this approach is ok, sci-pm-domain.yaml needs to be extended.
> Also, it sounds a bit like the cell value is not a bit-mask, so maybe
> adding TI_SCI_PD_KEEP_BOOT_STATE flag this way is not fine.
>
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ideasonboard.com>
> ---
> drivers/pmdomain/ti/ti_sci_pm_domains.c | 27 +++++++++++++++++++++++++--
> include/dt-bindings/soc/ti,sci_pm_domain.h | 1 +
> 2 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pmdomain/ti/ti_sci_pm_domains.c b/drivers/pmdomain/ti/ti_sci_pm_domains.c
> index 1510d5ddae3d..b71b390aaa39 100644
> --- a/drivers/pmdomain/ti/ti_sci_pm_domains.c
> +++ b/drivers/pmdomain/ti/ti_sci_pm_domains.c
> @@ -103,7 +103,7 @@ static struct generic_pm_domain *ti_sci_pd_xlate(
> return ERR_PTR(-ENOENT);
>
> genpd_to_ti_sci_pd(genpd_data->domains[idx])->exclusive =
> - genpdspec->args[1];
> + genpdspec->args[1] & TI_SCI_PD_EXCLUSIVE;
>
> return genpd_data->domains[idx];
> }
> @@ -161,6 +161,8 @@ static int ti_sci_pm_domain_probe(struct platform_device *pdev)
> break;
>
> if (args.args_count >= 1 && args.np == dev->of_node) {
> + bool is_on = false;
> +
> if (args.args[0] > max_id) {
> max_id = args.args[0];
> } else {
> @@ -189,7 +191,28 @@ static int ti_sci_pm_domain_probe(struct platform_device *pdev)
> pd->idx = args.args[0];
> pd->parent = pd_provider;
>
> - pm_genpd_init(&pd->pd, NULL, true);
> + /*
> + * If TI_SCI_PD_KEEP_BOOT_STATE is set and the
> + * PD has been enabled by the bootloader, set
> + * the PD to GENPD_FLAG_ALWAYS_ON. This will
> + * make sure the PD stays enabled until a driver
> + * takes over and clears the GENPD_FLAG_ALWAYS_ON
> + * flag.
> + */
> + if (args.args_count > 1 &&
> + args.args[1] & TI_SCI_PD_KEEP_BOOT_STATE) {
> + /*
> + * We ignore any error here, and in case
> + * of error just assume the PD is off.
> + */
> + pd_provider->ti_sci->ops.dev_ops.is_on(pd_provider->ti_sci,
> + pd->idx, NULL, &is_on);
> +
> + if (is_on)
> + pd->pd.flags |= GENPD_FLAG_ALWAYS_ON;
> + }
> +
> + pm_genpd_init(&pd->pd, NULL, !is_on);
>
> list_add(&pd->node, &pd_provider->pd_list);
> }
> diff --git a/include/dt-bindings/soc/ti,sci_pm_domain.h b/include/dt-bindings/soc/ti,sci_pm_domain.h
> index 8f2a7360b65e..af610208e3a3 100644
> --- a/include/dt-bindings/soc/ti,sci_pm_domain.h
> +++ b/include/dt-bindings/soc/ti,sci_pm_domain.h
> @@ -3,6 +3,7 @@
> #ifndef __DT_BINDINGS_TI_SCI_PM_DOMAIN_H
> #define __DT_BINDINGS_TI_SCI_PM_DOMAIN_H
>
> +#define TI_SCI_PD_KEEP_BOOT_STATE 2
> #define TI_SCI_PD_EXCLUSIVE 1
> #define TI_SCI_PD_SHARED 0
>
>
More information about the linux-arm-kernel
mailing list