From: "Heiko Stübner" <heiko@sntech.de>
To: daniel.lezcano@linaro.org, rjw@rjwysocki.net,
Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: robh@kernel.org, lukasz.luba@arm.com, arnd@linaro.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
Geert Uytterhoeven <geert+renesas@glider.be>,
"moderated list:ARM/Rockchip SoC support"
<linux-arm-kernel@lists.infradead.org>,
"open list:ARM/Rockchip SoC support"
<linux-rockchip@lists.infradead.org>
Subject: Re: [PATCH v7 5/5] rockchip/soc/drivers: Add DTPM description for rk3399
Date: Fri, 28 Jan 2022 11:19:22 +0100 [thread overview]
Message-ID: <48865702.Mx8J7aE1p6@diego> (raw)
In-Reply-To: <20220125171809.1273269-6-daniel.lezcano@linaro.org>
Am Dienstag, 25. Januar 2022, 18:18:09 CET schrieb Daniel Lezcano:
> The DTPM framework does support now the hierarchy description.
>
> The platform specific code can call the hierarchy creation function
> with an array of struct dtpm_node pointing to their parent.
>
> This patch provides a description of the big / Little CPUs and the
> GPU and tie them together under a virtual 'package' name. Only rk3399 is
> described now.
>
> The description could be extended in the future with the memory
> controller with devfreq.
>
> The description is always a module and it describes the soft
> dependencies. The userspace has to load the softdeps module in the
> right order.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
> drivers/soc/rockchip/Kconfig | 8 +++++
> drivers/soc/rockchip/Makefile | 1 +
> drivers/soc/rockchip/dtpm.c | 59 +++++++++++++++++++++++++++++++++++
> 3 files changed, 68 insertions(+)
> create mode 100644 drivers/soc/rockchip/dtpm.c
>
> diff --git a/drivers/soc/rockchip/Kconfig b/drivers/soc/rockchip/Kconfig
> index 25eb2c1e31bb..6dc017f02431 100644
> --- a/drivers/soc/rockchip/Kconfig
> +++ b/drivers/soc/rockchip/Kconfig
> @@ -34,4 +34,12 @@ config ROCKCHIP_PM_DOMAINS
>
> If unsure, say N.
>
> +config ROCKCHIP_DTPM
> + tristate "Rockchip DTPM hierarchy"
> + depends on DTPM && DRM_PANFROST && m
> + help
> + Describe the hierarchy for the Dynamic Thermal Power
> + Management tree on this platform. That will create all the
> + power capping capable devices.
> +
> endif
> diff --git a/drivers/soc/rockchip/Makefile b/drivers/soc/rockchip/Makefile
> index 875032f7344e..05f31a4e743c 100644
> --- a/drivers/soc/rockchip/Makefile
> +++ b/drivers/soc/rockchip/Makefile
> @@ -5,3 +5,4 @@
> obj-$(CONFIG_ROCKCHIP_GRF) += grf.o
> obj-$(CONFIG_ROCKCHIP_IODOMAIN) += io-domain.o
> obj-$(CONFIG_ROCKCHIP_PM_DOMAINS) += pm_domains.o
> +obj-$(CONFIG_ROCKCHIP_DTPM) += dtpm.o
> diff --git a/drivers/soc/rockchip/dtpm.c b/drivers/soc/rockchip/dtpm.c
> new file mode 100644
> index 000000000000..0b73a9cba954
> --- /dev/null
> +++ b/drivers/soc/rockchip/dtpm.c
> @@ -0,0 +1,59 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright 2021 Linaro Limited
> + *
> + * Author: Daniel Lezcano <daniel.lezcano@linaro.org>
> + *
> + * DTPM hierarchy description
> + */
> +#include <linux/dtpm.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +
> +static struct dtpm_node __initdata rk3399_hierarchy[] = {
The driver is tristate so buildable as module but uses __initdata.
As it depends on panfrost (which also can be a module) you
probably want a "__initdata_or_module" here .
> + [0]{ .name = "rk3399",
> + .type = DTPM_NODE_VIRTUAL },
> + [1]{ .name = "package",
> + .type = DTPM_NODE_VIRTUAL,
> + .parent = &rk3399_hierarchy[0] },
> + [2]{ .name = "/cpus/cpu@0",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [3]{ .name = "/cpus/cpu@1",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [4]{ .name = "/cpus/cpu@2",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [5]{ .name = "/cpus/cpu@3",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [6]{ .name = "/cpus/cpu@100",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [7]{ .name = "/cpus/cpu@101",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [8]{ .name = "/gpu@ff9a0000",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [9]{ },
hmm, do we want a "/* sentinel */" inside the empty last entry?
I think that is pretty common to denote the "this one is the last entry"
of a dynamic list ;-)
> +};
> +
> +static struct of_device_id __initdata rockchip_dtpm_match_table[] = {
> + { .compatible = "rockchip,rk3399", .data = rk3399_hierarchy },
> + {},
> +};
> +
> +static int __init rockchip_dtpm_init(void)
> +{
> + return dtpm_create_hierarchy(rockchip_dtpm_match_table);
> +}
> +module_init(rockchip_dtpm_init);
Just for my understanding what happens on driver unload?
Thanks
Heiko
> +
> +MODULE_SOFTDEP("pre: panfrost cpufreq-dt");
> +MODULE_DESCRIPTION("Rockchip DTPM driver");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:dtpm");
> +MODULE_AUTHOR("Daniel Lezcano <daniel.lezcano@kernel.org");
>
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: daniel.lezcano@linaro.org, rjw@rjwysocki.net,
Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: robh@kernel.org, lukasz.luba@arm.com, arnd@linaro.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
Geert Uytterhoeven <geert+renesas@glider.be>,
"moderated list:ARM/Rockchip SoC support"
<linux-arm-kernel@lists.infradead.org>,
"open list:ARM/Rockchip SoC support"
<linux-rockchip@lists.infradead.org>
Subject: Re: [PATCH v7 5/5] rockchip/soc/drivers: Add DTPM description for rk3399
Date: Fri, 28 Jan 2022 11:19:22 +0100 [thread overview]
Message-ID: <48865702.Mx8J7aE1p6@diego> (raw)
In-Reply-To: <20220125171809.1273269-6-daniel.lezcano@linaro.org>
Am Dienstag, 25. Januar 2022, 18:18:09 CET schrieb Daniel Lezcano:
> The DTPM framework does support now the hierarchy description.
>
> The platform specific code can call the hierarchy creation function
> with an array of struct dtpm_node pointing to their parent.
>
> This patch provides a description of the big / Little CPUs and the
> GPU and tie them together under a virtual 'package' name. Only rk3399 is
> described now.
>
> The description could be extended in the future with the memory
> controller with devfreq.
>
> The description is always a module and it describes the soft
> dependencies. The userspace has to load the softdeps module in the
> right order.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
> drivers/soc/rockchip/Kconfig | 8 +++++
> drivers/soc/rockchip/Makefile | 1 +
> drivers/soc/rockchip/dtpm.c | 59 +++++++++++++++++++++++++++++++++++
> 3 files changed, 68 insertions(+)
> create mode 100644 drivers/soc/rockchip/dtpm.c
>
> diff --git a/drivers/soc/rockchip/Kconfig b/drivers/soc/rockchip/Kconfig
> index 25eb2c1e31bb..6dc017f02431 100644
> --- a/drivers/soc/rockchip/Kconfig
> +++ b/drivers/soc/rockchip/Kconfig
> @@ -34,4 +34,12 @@ config ROCKCHIP_PM_DOMAINS
>
> If unsure, say N.
>
> +config ROCKCHIP_DTPM
> + tristate "Rockchip DTPM hierarchy"
> + depends on DTPM && DRM_PANFROST && m
> + help
> + Describe the hierarchy for the Dynamic Thermal Power
> + Management tree on this platform. That will create all the
> + power capping capable devices.
> +
> endif
> diff --git a/drivers/soc/rockchip/Makefile b/drivers/soc/rockchip/Makefile
> index 875032f7344e..05f31a4e743c 100644
> --- a/drivers/soc/rockchip/Makefile
> +++ b/drivers/soc/rockchip/Makefile
> @@ -5,3 +5,4 @@
> obj-$(CONFIG_ROCKCHIP_GRF) += grf.o
> obj-$(CONFIG_ROCKCHIP_IODOMAIN) += io-domain.o
> obj-$(CONFIG_ROCKCHIP_PM_DOMAINS) += pm_domains.o
> +obj-$(CONFIG_ROCKCHIP_DTPM) += dtpm.o
> diff --git a/drivers/soc/rockchip/dtpm.c b/drivers/soc/rockchip/dtpm.c
> new file mode 100644
> index 000000000000..0b73a9cba954
> --- /dev/null
> +++ b/drivers/soc/rockchip/dtpm.c
> @@ -0,0 +1,59 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright 2021 Linaro Limited
> + *
> + * Author: Daniel Lezcano <daniel.lezcano@linaro.org>
> + *
> + * DTPM hierarchy description
> + */
> +#include <linux/dtpm.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +
> +static struct dtpm_node __initdata rk3399_hierarchy[] = {
The driver is tristate so buildable as module but uses __initdata.
As it depends on panfrost (which also can be a module) you
probably want a "__initdata_or_module" here .
> + [0]{ .name = "rk3399",
> + .type = DTPM_NODE_VIRTUAL },
> + [1]{ .name = "package",
> + .type = DTPM_NODE_VIRTUAL,
> + .parent = &rk3399_hierarchy[0] },
> + [2]{ .name = "/cpus/cpu@0",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [3]{ .name = "/cpus/cpu@1",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [4]{ .name = "/cpus/cpu@2",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [5]{ .name = "/cpus/cpu@3",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [6]{ .name = "/cpus/cpu@100",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [7]{ .name = "/cpus/cpu@101",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [8]{ .name = "/gpu@ff9a0000",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [9]{ },
hmm, do we want a "/* sentinel */" inside the empty last entry?
I think that is pretty common to denote the "this one is the last entry"
of a dynamic list ;-)
> +};
> +
> +static struct of_device_id __initdata rockchip_dtpm_match_table[] = {
> + { .compatible = "rockchip,rk3399", .data = rk3399_hierarchy },
> + {},
> +};
> +
> +static int __init rockchip_dtpm_init(void)
> +{
> + return dtpm_create_hierarchy(rockchip_dtpm_match_table);
> +}
> +module_init(rockchip_dtpm_init);
Just for my understanding what happens on driver unload?
Thanks
Heiko
> +
> +MODULE_SOFTDEP("pre: panfrost cpufreq-dt");
> +MODULE_DESCRIPTION("Rockchip DTPM driver");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:dtpm");
> +MODULE_AUTHOR("Daniel Lezcano <daniel.lezcano@kernel.org");
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: daniel.lezcano@linaro.org, rjw@rjwysocki.net,
Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: robh@kernel.org, lukasz.luba@arm.com, arnd@linaro.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
Geert Uytterhoeven <geert+renesas@glider.be>,
"moderated list:ARM/Rockchip SoC support"
<linux-arm-kernel@lists.infradead.org>,
"open list:ARM/Rockchip SoC support"
<linux-rockchip@lists.infradead.org>
Subject: Re: [PATCH v7 5/5] rockchip/soc/drivers: Add DTPM description for rk3399
Date: Fri, 28 Jan 2022 11:19:22 +0100 [thread overview]
Message-ID: <48865702.Mx8J7aE1p6@diego> (raw)
In-Reply-To: <20220125171809.1273269-6-daniel.lezcano@linaro.org>
Am Dienstag, 25. Januar 2022, 18:18:09 CET schrieb Daniel Lezcano:
> The DTPM framework does support now the hierarchy description.
>
> The platform specific code can call the hierarchy creation function
> with an array of struct dtpm_node pointing to their parent.
>
> This patch provides a description of the big / Little CPUs and the
> GPU and tie them together under a virtual 'package' name. Only rk3399 is
> described now.
>
> The description could be extended in the future with the memory
> controller with devfreq.
>
> The description is always a module and it describes the soft
> dependencies. The userspace has to load the softdeps module in the
> right order.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
> drivers/soc/rockchip/Kconfig | 8 +++++
> drivers/soc/rockchip/Makefile | 1 +
> drivers/soc/rockchip/dtpm.c | 59 +++++++++++++++++++++++++++++++++++
> 3 files changed, 68 insertions(+)
> create mode 100644 drivers/soc/rockchip/dtpm.c
>
> diff --git a/drivers/soc/rockchip/Kconfig b/drivers/soc/rockchip/Kconfig
> index 25eb2c1e31bb..6dc017f02431 100644
> --- a/drivers/soc/rockchip/Kconfig
> +++ b/drivers/soc/rockchip/Kconfig
> @@ -34,4 +34,12 @@ config ROCKCHIP_PM_DOMAINS
>
> If unsure, say N.
>
> +config ROCKCHIP_DTPM
> + tristate "Rockchip DTPM hierarchy"
> + depends on DTPM && DRM_PANFROST && m
> + help
> + Describe the hierarchy for the Dynamic Thermal Power
> + Management tree on this platform. That will create all the
> + power capping capable devices.
> +
> endif
> diff --git a/drivers/soc/rockchip/Makefile b/drivers/soc/rockchip/Makefile
> index 875032f7344e..05f31a4e743c 100644
> --- a/drivers/soc/rockchip/Makefile
> +++ b/drivers/soc/rockchip/Makefile
> @@ -5,3 +5,4 @@
> obj-$(CONFIG_ROCKCHIP_GRF) += grf.o
> obj-$(CONFIG_ROCKCHIP_IODOMAIN) += io-domain.o
> obj-$(CONFIG_ROCKCHIP_PM_DOMAINS) += pm_domains.o
> +obj-$(CONFIG_ROCKCHIP_DTPM) += dtpm.o
> diff --git a/drivers/soc/rockchip/dtpm.c b/drivers/soc/rockchip/dtpm.c
> new file mode 100644
> index 000000000000..0b73a9cba954
> --- /dev/null
> +++ b/drivers/soc/rockchip/dtpm.c
> @@ -0,0 +1,59 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright 2021 Linaro Limited
> + *
> + * Author: Daniel Lezcano <daniel.lezcano@linaro.org>
> + *
> + * DTPM hierarchy description
> + */
> +#include <linux/dtpm.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +
> +static struct dtpm_node __initdata rk3399_hierarchy[] = {
The driver is tristate so buildable as module but uses __initdata.
As it depends on panfrost (which also can be a module) you
probably want a "__initdata_or_module" here .
> + [0]{ .name = "rk3399",
> + .type = DTPM_NODE_VIRTUAL },
> + [1]{ .name = "package",
> + .type = DTPM_NODE_VIRTUAL,
> + .parent = &rk3399_hierarchy[0] },
> + [2]{ .name = "/cpus/cpu@0",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [3]{ .name = "/cpus/cpu@1",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [4]{ .name = "/cpus/cpu@2",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [5]{ .name = "/cpus/cpu@3",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [6]{ .name = "/cpus/cpu@100",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [7]{ .name = "/cpus/cpu@101",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [8]{ .name = "/gpu@ff9a0000",
> + .type = DTPM_NODE_DT,
> + .parent = &rk3399_hierarchy[1] },
> + [9]{ },
hmm, do we want a "/* sentinel */" inside the empty last entry?
I think that is pretty common to denote the "this one is the last entry"
of a dynamic list ;-)
> +};
> +
> +static struct of_device_id __initdata rockchip_dtpm_match_table[] = {
> + { .compatible = "rockchip,rk3399", .data = rk3399_hierarchy },
> + {},
> +};
> +
> +static int __init rockchip_dtpm_init(void)
> +{
> + return dtpm_create_hierarchy(rockchip_dtpm_match_table);
> +}
> +module_init(rockchip_dtpm_init);
Just for my understanding what happens on driver unload?
Thanks
Heiko
> +
> +MODULE_SOFTDEP("pre: panfrost cpufreq-dt");
> +MODULE_DESCRIPTION("Rockchip DTPM driver");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:dtpm");
> +MODULE_AUTHOR("Daniel Lezcano <daniel.lezcano@kernel.org");
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-01-28 10:19 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-25 17:18 [PATCH v7 0/6] powercap/drivers/dtpm: Create the dtpm hierarchy Daniel Lezcano
2022-01-25 17:18 ` [PATCH v7 1/5] powercap/drivers/dtpm: Convert the init table section to a simple array Daniel Lezcano
2022-01-25 17:18 ` [PATCH v7 2/5] powercap/drivers/dtpm: Add hierarchy creation Daniel Lezcano
2022-01-25 17:36 ` Ulf Hansson
2022-01-25 17:53 ` Daniel Lezcano
2022-01-25 17:18 ` [PATCH v7 3/5] powercap/drivers/dtpm: Add CPU DT initialization support Daniel Lezcano
2022-01-25 17:18 ` [PATCH v7 4/5] powercap/drivers/dtpm: Add dtpm devfreq with energy model support Daniel Lezcano
2022-01-25 17:18 ` [PATCH v7 5/5] rockchip/soc/drivers: Add DTPM description for rk3399 Daniel Lezcano
2022-01-25 17:18 ` Daniel Lezcano
2022-01-25 17:18 ` Daniel Lezcano
2022-01-26 9:36 ` Daniel Lezcano
2022-01-26 9:36 ` Daniel Lezcano
2022-01-26 9:36 ` Daniel Lezcano
2022-01-26 9:40 ` Geert Uytterhoeven
2022-01-26 9:40 ` Geert Uytterhoeven
2022-01-26 9:40 ` Geert Uytterhoeven
2022-01-26 9:58 ` Daniel Lezcano
2022-01-26 9:58 ` Daniel Lezcano
2022-01-26 9:58 ` Daniel Lezcano
2022-01-28 10:19 ` Heiko Stübner [this message]
2022-01-28 10:19 ` Heiko Stübner
2022-01-28 10:19 ` Heiko Stübner
2022-01-28 15:13 ` Daniel Lezcano
2022-01-28 15:13 ` Daniel Lezcano
2022-01-28 15:13 ` Daniel Lezcano
2022-01-28 15:48 ` Heiko Stübner
2022-01-28 15:48 ` Heiko Stübner
2022-01-28 15:48 ` Heiko Stübner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48865702.Mx8J7aE1p6@diego \
--to=heiko@sntech.de \
--cc=arnd@linaro.org \
--cc=daniel.lezcano@linaro.org \
--cc=geert+renesas@glider.be \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=lukasz.luba@arm.com \
--cc=rjw@rjwysocki.net \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.