[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPDyKFq_4W7bPr1NiuEGzMDoY6tQuHbw5uOXrkJagbEbtmqMWg@mail.gmail.com>
Date: Thu, 19 Jun 2025 12:24:47 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Michal Wilczynski <m.wilczynski@...sung.com>, Bartosz Golaszewski <brgl@...ev.pl>
Cc: Drew Fustini <drew@...7.com>, Guo Ren <guoren@...nel.org>, Fu Wei <wefu@...hat.com>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Philipp Zabel <p.zabel@...gutronix.de>, Frank Binns <frank.binns@...tec.com>,
Matt Coster <matt.coster@...tec.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>,
Marek Szyprowski <m.szyprowski@...sung.com>, linux-riscv@...ts.infradead.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v5 3/8] pmdomain: thead: Instantiate GPU power sequencer
via auxiliary bus
On Wed, 18 Jun 2025 at 12:22, Michal Wilczynski
<m.wilczynski@...sung.com> wrote:
>
> In order to support the complex power sequencing required by the TH1520
> GPU, the AON power domain driver must be responsible for initiating the
> corresponding sequencer driver. This functionality is specific to
> platforms where the GPU power sequencing hardware is controlled by the
> AON block.
>
> Extend the AON power domain driver to check for the presence of the
> "gpu-clkgen" reset in its own device tree node.
>
> If the property is found, create and register a new auxiliary device.
> This device acts as a proxy that allows the dedicated `pwrseq-thead-gpu`
> auxiliary driver to bind and take control of the sequencing logic.
>
> Signed-off-by: Michal Wilczynski <m.wilczynski@...sung.com>
Reviewed-by: Ulf Hansson <ulf.hansson@...aro.org>
It looks like there is another re-spin needed, but thinking of the
merge-strategy I could potentially take patch1->patch3 via my pmdomain
tree, as it seems reasonable to keep those changes together. Unless
Bartosz sees any problem with that, of course.
Kind regards
Uffe
> ---
> drivers/pmdomain/thead/Kconfig | 1 +
> drivers/pmdomain/thead/th1520-pm-domains.c | 51 ++++++++++++++++++++++++++++++
> 2 files changed, 52 insertions(+)
>
> diff --git a/drivers/pmdomain/thead/Kconfig b/drivers/pmdomain/thead/Kconfig
> index 7d52f8374b074167d508a80fd807929c53faef12..208828e0fa0dc91256bf808b905bea32bb84250d 100644
> --- a/drivers/pmdomain/thead/Kconfig
> +++ b/drivers/pmdomain/thead/Kconfig
> @@ -4,6 +4,7 @@ config TH1520_PM_DOMAINS
> tristate "Support TH1520 Power Domains"
> depends on TH1520_AON_PROTOCOL
> select REGMAP_MMIO
> + select AUXILIARY_BUS
> help
> This driver enables power domain management for the T-HEAD
> TH-1520 SoC. On this SoC there are number of power domains,
> diff --git a/drivers/pmdomain/thead/th1520-pm-domains.c b/drivers/pmdomain/thead/th1520-pm-domains.c
> index f702e20306f469aeb0ed15e54bd4f8309f28018c..9040b698e7f7f2400163841530fecacfb0f917bc 100644
> --- a/drivers/pmdomain/thead/th1520-pm-domains.c
> +++ b/drivers/pmdomain/thead/th1520-pm-domains.c
> @@ -5,6 +5,7 @@
> * Author: Michal Wilczynski <m.wilczynski@...sung.com>
> */
>
> +#include <linux/auxiliary_bus.h>
> #include <linux/firmware/thead/thead,th1520-aon.h>
> #include <linux/slab.h>
> #include <linux/platform_device.h>
> @@ -128,6 +129,50 @@ static void th1520_pd_init_all_off(struct generic_pm_domain **domains,
> }
> }
>
> +static void th1520_pd_pwrseq_unregister_adev(void *adev)
> +{
> + auxiliary_device_delete(adev);
> + auxiliary_device_uninit(adev);
> +}
> +
> +static int th1520_pd_pwrseq_gpu_init(struct device *dev)
> +{
> + struct auxiliary_device *adev;
> + int ret;
> +
> + /*
> + * Correctly check only for the property's existence in the DT node.
> + * We don't need to get/claim the reset here; that is the job of
> + * the auxiliary driver that we are about to spawn.
> + */
> + if (device_property_match_string(dev, "reset-names", "gpu-clkgen") < 0)
> + /*
> + * This is not an error. It simply means the optional sequencer
> + * is not described in the device tree.
> + */
> + return 0;
> +
> + adev = devm_kzalloc(dev, sizeof(*adev), GFP_KERNEL);
> + if (!adev)
> + return -ENOMEM;
> +
> + adev->name = "pwrseq-gpu";
> + adev->dev.parent = dev;
> +
> + ret = auxiliary_device_init(adev);
> + if (ret)
> + return ret;
> +
> + ret = auxiliary_device_add(adev);
> + if (ret) {
> + auxiliary_device_uninit(adev);
> + return ret;
> + }
> +
> + return devm_add_action_or_reset(dev, th1520_pd_pwrseq_unregister_adev,
> + adev);
> +}
> +
> static int th1520_pd_probe(struct platform_device *pdev)
> {
> struct generic_pm_domain **domains;
> @@ -186,8 +231,14 @@ static int th1520_pd_probe(struct platform_device *pdev)
> if (ret)
> goto err_clean_genpd;
>
> + ret = th1520_pd_pwrseq_gpu_init(dev);
> + if (ret)
> + goto err_clean_provider;
> +
> return 0;
>
> +err_clean_provider:
> + of_genpd_del_provider(dev->of_node);
> err_clean_genpd:
> for (i--; i >= 0; i--)
> pm_genpd_remove(domains[i]);
>
> --
> 2.34.1
>
Powered by blists - more mailing lists