* [PATCH v2 7/9] pmdomain: renesas: rcar-gen4-sysc: Drop GENPD_FLAG_NO_STAY_ON
From: Ulf Hansson @ 2026-04-10 10:40 UTC (permalink / raw)
To: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm
Cc: Sudeep Holla, Cristian Marussi, Kevin Hilman, Stephen Boyd,
Marek Szyprowski, Bjorn Andersson, Abel Vesa, Peng Fan,
Tomi Valkeinen, Maulik Shah, Konrad Dybcio, Thierry Reding,
Jonathan Hunter, Geert Uytterhoeven, Dmitry Baryshkov,
Ulf Hansson, linux-arm-kernel, linux-kernel, Geert Uytterhoeven
In-Reply-To: <20260410104058.83748-1-ulf.hansson@linaro.org>
Due to the new fine grained sync_state support for onecell genpd provider
drivers, we should no longer need use the legacy behaviour. Therefore,
let's drop GENPD_FLAG_NO_STAY_ON.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/pmdomain/renesas/rcar-gen4-sysc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/pmdomain/renesas/rcar-gen4-sysc.c b/drivers/pmdomain/renesas/rcar-gen4-sysc.c
index 0c6c639a91d0..81b154da725f 100644
--- a/drivers/pmdomain/renesas/rcar-gen4-sysc.c
+++ b/drivers/pmdomain/renesas/rcar-gen4-sysc.c
@@ -251,7 +251,6 @@ static int __init rcar_gen4_sysc_pd_setup(struct rcar_gen4_sysc_pd *pd)
genpd->detach_dev = cpg_mssr_detach_dev;
}
- genpd->flags |= GENPD_FLAG_NO_STAY_ON;
genpd->power_off = rcar_gen4_sysc_pd_power_off;
genpd->power_on = rcar_gen4_sysc_pd_power_on;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 5/9] pmdomain: core: Extend fine grained sync_state to more onecell providers
From: Ulf Hansson @ 2026-04-10 10:40 UTC (permalink / raw)
To: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm
Cc: Sudeep Holla, Cristian Marussi, Kevin Hilman, Stephen Boyd,
Marek Szyprowski, Bjorn Andersson, Abel Vesa, Peng Fan,
Tomi Valkeinen, Maulik Shah, Konrad Dybcio, Thierry Reding,
Jonathan Hunter, Geert Uytterhoeven, Dmitry Baryshkov,
Ulf Hansson, linux-arm-kernel, linux-kernel, Geert Uytterhoeven
In-Reply-To: <20260410104058.83748-1-ulf.hansson@linaro.org>
A onecell power domain provider driver that we can assign a common
->sync_state() callback for, should be able to benefit from the improved
fine grained sync_state support in genpd. Therefore, let's also assign the
->queue_sync_state() callback for these types of provider drivers.
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/pmdomain/core.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
index 783d6f981708..f11dc2110737 100644
--- a/drivers/pmdomain/core.c
+++ b/drivers/pmdomain/core.c
@@ -2918,10 +2918,12 @@ int of_genpd_add_provider_onecell(struct device_node *np,
fwnode = of_fwnode_handle(np);
dev = get_dev_from_fwnode(fwnode);
- if (!dev)
+ if (!dev) {
sync_state = true;
- else
+ } else if (!dev_has_sync_state(dev)) {
dev_set_drv_sync_state(dev, genpd_sync_state);
+ dev_set_drv_queue_sync_state(dev, genpd_queue_sync_state);
+ }
put_device(dev);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 4/9] pmdomain: core: Add initial fine grained sync_state support
From: Ulf Hansson @ 2026-04-10 10:40 UTC (permalink / raw)
To: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm
Cc: Sudeep Holla, Cristian Marussi, Kevin Hilman, Stephen Boyd,
Marek Szyprowski, Bjorn Andersson, Abel Vesa, Peng Fan,
Tomi Valkeinen, Maulik Shah, Konrad Dybcio, Thierry Reding,
Jonathan Hunter, Geert Uytterhoeven, Dmitry Baryshkov,
Ulf Hansson, linux-arm-kernel, linux-kernel, Geert Uytterhoeven
In-Reply-To: <20260410104058.83748-1-ulf.hansson@linaro.org>
A onecell (#power-domain-cells = <1 or 2>; in DT) power domain provider
typically provides multiple independent power domains, each with their own
corresponding consumers. In these cases we have to wait for all consumers
for all the provided power domains before the ->sync_state() callback gets
called for the supplier.
In a first step to improve this, let's implement support for fine grained
sync_state support a per genpd basis by using the ->queue_sync_state()
callback. To take step by step, let's initially limit the improvement to
the internal genpd provider driver and to its corresponding genpd devices
for onecell providers.
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/pmdomain/core.c | 125 ++++++++++++++++++++++++++++++++++++++
include/linux/pm_domain.h | 1 +
2 files changed, 126 insertions(+)
diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
index ad57846f02a3..783d6f981708 100644
--- a/drivers/pmdomain/core.c
+++ b/drivers/pmdomain/core.c
@@ -2699,6 +2699,120 @@ static struct generic_pm_domain *genpd_get_from_provider(
return genpd;
}
+static bool genpd_should_wait_for_consumer(struct device_node *np)
+{
+ struct generic_pm_domain *genpd;
+ bool should_wait = false;
+
+ mutex_lock(&gpd_list_lock);
+ list_for_each_entry(genpd, &gpd_list, gpd_list_node) {
+ if (genpd->provider == of_fwnode_handle(np)) {
+ genpd_lock(genpd);
+
+ /* Clear the previous state before reevaluating. */
+ genpd->wait_for_consumer = false;
+
+ /*
+ * Unless there is at least one genpd for the provider
+ * that is being kept powered-on, we don't have to care
+ * about waiting for consumers.
+ */
+ if (genpd->stay_on)
+ should_wait = true;
+
+ genpd_unlock(genpd);
+ }
+ }
+ mutex_unlock(&gpd_list_lock);
+
+ return should_wait;
+}
+
+static void genpd_parse_for_consumer(struct device_node *sup,
+ struct device_node *con)
+{
+ struct generic_pm_domain *genpd;
+ int i;
+
+ for (i = 0; ; i++) {
+ struct of_phandle_args pd_args;
+
+ if (of_parse_phandle_with_args(con, "power-domains",
+ "#power-domain-cells",
+ i, &pd_args))
+ break;
+
+ /*
+ * The phandle must correspond to the supplier's genpd provider
+ * to be relevant else let's move to the next index.
+ */
+ if (sup != pd_args.np) {
+ of_node_put(pd_args.np);
+ continue;
+ }
+
+ mutex_lock(&gpd_list_lock);
+ genpd = genpd_get_from_provider(&pd_args);
+ if (!IS_ERR(genpd)) {
+ genpd_lock(genpd);
+ genpd->wait_for_consumer = true;
+ genpd_unlock(genpd);
+ }
+ mutex_unlock(&gpd_list_lock);
+
+ of_node_put(pd_args.np);
+ }
+}
+
+static void _genpd_queue_sync_state(struct device_node *np)
+{
+ struct generic_pm_domain *genpd;
+
+ mutex_lock(&gpd_list_lock);
+ list_for_each_entry(genpd, &gpd_list, gpd_list_node) {
+ if (genpd->provider == of_fwnode_handle(np)) {
+ genpd_lock(genpd);
+ if (genpd->stay_on && !genpd->wait_for_consumer) {
+ genpd->stay_on = false;
+ genpd_queue_power_off_work(genpd);
+ }
+ genpd_unlock(genpd);
+ }
+ }
+ mutex_unlock(&gpd_list_lock);
+}
+
+static void genpd_queue_sync_state(struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ struct device_link *link;
+
+ if (!genpd_should_wait_for_consumer(np))
+ return;
+
+ list_for_each_entry(link, &dev->links.consumers, s_node) {
+ struct device *consumer = link->consumer;
+
+ if (!device_link_test(link, DL_FLAG_MANAGED))
+ continue;
+
+ if (link->status == DL_STATE_ACTIVE)
+ continue;
+
+ if (!consumer->of_node)
+ continue;
+
+ /*
+ * A consumer device has not been probed yet. Let's parse its
+ * device node for the power-domains property, to find out the
+ * genpds it may belong to and then prevent sync state for them.
+ */
+ genpd_parse_for_consumer(np, consumer->of_node);
+ }
+
+ _genpd_queue_sync_state(np);
+}
+
static void genpd_sync_state(struct device *dev)
{
return of_genpd_sync_state(dev->of_node);
@@ -3531,6 +3645,16 @@ static int genpd_provider_probe(struct device *dev)
return 0;
}
+static void genpd_provider_queue_sync_state(struct device *dev)
+{
+ struct generic_pm_domain *genpd = container_of(dev, struct generic_pm_domain, dev);
+
+ if (genpd->sync_state != GENPD_SYNC_STATE_ONECELL)
+ return;
+
+ genpd_queue_sync_state(dev);
+}
+
static void genpd_provider_sync_state(struct device *dev)
{
struct generic_pm_domain *genpd = container_of(dev, struct generic_pm_domain, dev);
@@ -3559,6 +3683,7 @@ static struct device_driver genpd_provider_drv = {
.name = "genpd_provider",
.bus = &genpd_provider_bus_type,
.probe = genpd_provider_probe,
+ .queue_sync_state = genpd_provider_queue_sync_state,
.sync_state = genpd_provider_sync_state,
.suppress_bind_attrs = true,
};
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index b299dc0128d6..7aa49721cde5 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -215,6 +215,7 @@ struct generic_pm_domain {
cpumask_var_t cpus; /* A cpumask of the attached CPUs */
bool synced_poweroff; /* A consumer needs a synced poweroff */
bool stay_on; /* Stay powered-on during boot. */
+ bool wait_for_consumer; /* Consumers awaits to be probed. */
enum genpd_sync_state sync_state; /* How sync_state is managed. */
int (*power_off)(struct generic_pm_domain *domain);
int (*power_on)(struct generic_pm_domain *domain);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/9] pmdomain: core: Move genpd_get_from_provider()
From: Ulf Hansson @ 2026-04-10 10:40 UTC (permalink / raw)
To: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm
Cc: Sudeep Holla, Cristian Marussi, Kevin Hilman, Stephen Boyd,
Marek Szyprowski, Bjorn Andersson, Abel Vesa, Peng Fan,
Tomi Valkeinen, Maulik Shah, Konrad Dybcio, Thierry Reding,
Jonathan Hunter, Geert Uytterhoeven, Dmitry Baryshkov,
Ulf Hansson, linux-arm-kernel, linux-kernel, Geert Uytterhoeven
In-Reply-To: <20260410104058.83748-1-ulf.hansson@linaro.org>
To prepare for subsequent changes and to avoid an unnecessary function
declaration, let's move genpd_get_from_provider() a bit earlier in the
code.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/pmdomain/core.c | 70 ++++++++++++++++++++---------------------
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
index 4d32fc676aaf..ad57846f02a3 100644
--- a/drivers/pmdomain/core.c
+++ b/drivers/pmdomain/core.c
@@ -2664,6 +2664,41 @@ static bool genpd_present(const struct generic_pm_domain *genpd)
return ret;
}
+/**
+ * genpd_get_from_provider() - Look-up PM domain
+ * @genpdspec: OF phandle args to use for look-up
+ *
+ * Looks for a PM domain provider under the node specified by @genpdspec and if
+ * found, uses xlate function of the provider to map phandle args to a PM
+ * domain.
+ *
+ * Returns a valid pointer to struct generic_pm_domain on success or ERR_PTR()
+ * on failure.
+ */
+static struct generic_pm_domain *genpd_get_from_provider(
+ const struct of_phandle_args *genpdspec)
+{
+ struct generic_pm_domain *genpd = ERR_PTR(-ENOENT);
+ struct of_genpd_provider *provider;
+
+ if (!genpdspec)
+ return ERR_PTR(-EINVAL);
+
+ mutex_lock(&of_genpd_mutex);
+
+ /* Check if we have such a provider in our array */
+ list_for_each_entry(provider, &of_genpd_providers, link) {
+ if (provider->node == genpdspec->np)
+ genpd = provider->xlate(genpdspec, provider->data);
+ if (!IS_ERR(genpd))
+ break;
+ }
+
+ mutex_unlock(&of_genpd_mutex);
+
+ return genpd;
+}
+
static void genpd_sync_state(struct device *dev)
{
return of_genpd_sync_state(dev->of_node);
@@ -2889,41 +2924,6 @@ void of_genpd_del_provider(struct device_node *np)
}
EXPORT_SYMBOL_GPL(of_genpd_del_provider);
-/**
- * genpd_get_from_provider() - Look-up PM domain
- * @genpdspec: OF phandle args to use for look-up
- *
- * Looks for a PM domain provider under the node specified by @genpdspec and if
- * found, uses xlate function of the provider to map phandle args to a PM
- * domain.
- *
- * Returns a valid pointer to struct generic_pm_domain on success or ERR_PTR()
- * on failure.
- */
-static struct generic_pm_domain *genpd_get_from_provider(
- const struct of_phandle_args *genpdspec)
-{
- struct generic_pm_domain *genpd = ERR_PTR(-ENOENT);
- struct of_genpd_provider *provider;
-
- if (!genpdspec)
- return ERR_PTR(-EINVAL);
-
- mutex_lock(&of_genpd_mutex);
-
- /* Check if we have such a provider in our array */
- list_for_each_entry(provider, &of_genpd_providers, link) {
- if (provider->node == genpdspec->np)
- genpd = provider->xlate(genpdspec, provider->data);
- if (!IS_ERR(genpd))
- break;
- }
-
- mutex_unlock(&of_genpd_mutex);
-
- return genpd;
-}
-
/**
* of_genpd_add_device() - Add a device to an I/O PM domain
* @genpdspec: OF phandle args to use for look-up PM domain
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/9] driver core: Enable suppliers to implement fine grained sync_state support
From: Ulf Hansson @ 2026-04-10 10:40 UTC (permalink / raw)
To: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm
Cc: Sudeep Holla, Cristian Marussi, Kevin Hilman, Stephen Boyd,
Marek Szyprowski, Bjorn Andersson, Abel Vesa, Peng Fan,
Tomi Valkeinen, Maulik Shah, Konrad Dybcio, Thierry Reding,
Jonathan Hunter, Geert Uytterhoeven, Dmitry Baryshkov,
Ulf Hansson, linux-arm-kernel, linux-kernel, Geert Uytterhoeven
In-Reply-To: <20260410104058.83748-1-ulf.hansson@linaro.org>
The common sync_state support isn't fine grained enough for some types of
suppliers, like power domains for example. Especially when a supplier
provides multiple independent power domains, each with their own set of
consumers. In these cases we need to wait for all consumers for all the
provided power domains before invoking the supplier's ->sync_state().
To allow a more fine grained sync_state support to be implemented on per
supplier's driver basis, let's add a new optional callback. As soon as
there is an update worth to consider in regards to managing sync_state for
a supplier device, __device_links_queue_sync_state() invokes the callback.
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/base/core.c | 7 ++++++-
include/linux/device/driver.h | 7 +++++++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 09b98f02f559..4085a011d8ca 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1106,7 +1106,9 @@ int device_links_check_suppliers(struct device *dev)
* Queues a device for a sync_state() callback when the device links write lock
* isn't held. This allows the sync_state() execution flow to use device links
* APIs. The caller must ensure this function is called with
- * device_links_write_lock() held.
+ * device_links_write_lock() held. Note, if the optional queue_sync_state()
+ * callback has been assigned too, it gets called for every update to allowing a
+ * more fine grained support to be implemented on per supplier basis.
*
* This function does a get_device() to make sure the device is not freed while
* on this list.
@@ -1126,6 +1128,9 @@ static void __device_links_queue_sync_state(struct device *dev,
if (dev->state_synced)
return;
+ if (dev->driver && dev->driver->queue_sync_state)
+ dev->driver->queue_sync_state(dev);
+
list_for_each_entry(link, &dev->links.consumers, s_node) {
if (!device_link_test(link, DL_FLAG_MANAGED))
continue;
diff --git a/include/linux/device/driver.h b/include/linux/device/driver.h
index bbc67ec513ed..bc9ae1cbe03c 100644
--- a/include/linux/device/driver.h
+++ b/include/linux/device/driver.h
@@ -68,6 +68,12 @@ enum probe_type {
* be called at late_initcall_sync level. If the device has
* consumers that are never bound to a driver, this function
* will never get called until they do.
+ * @queue_sync_state: Similar to the ->sync_state() callback, but called to
+ * allow syncing device state to software state in a more fine
+ * grained way. It is called when there is an updated state that
+ * may be worth to consider for any of the consumers linked to
+ * this device. If implemented, the ->sync_state() callback is
+ * required too.
* @remove: Called when the device is removed from the system to
* unbind a device from this driver.
* @shutdown: Called at shut-down time to quiesce the device.
@@ -110,6 +116,7 @@ struct device_driver {
int (*probe) (struct device *dev);
void (*sync_state)(struct device *dev);
+ void (*queue_sync_state)(struct device *dev);
int (*remove) (struct device *dev);
void (*shutdown) (struct device *dev);
int (*suspend) (struct device *dev, pm_message_t state);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/9] driver core: Add dev_set_drv_queue_sync_state()
From: Ulf Hansson @ 2026-04-10 10:40 UTC (permalink / raw)
To: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm
Cc: Sudeep Holla, Cristian Marussi, Kevin Hilman, Stephen Boyd,
Marek Szyprowski, Bjorn Andersson, Abel Vesa, Peng Fan,
Tomi Valkeinen, Maulik Shah, Konrad Dybcio, Thierry Reding,
Jonathan Hunter, Geert Uytterhoeven, Dmitry Baryshkov,
Ulf Hansson, linux-arm-kernel, linux-kernel, Geert Uytterhoeven
In-Reply-To: <20260410104058.83748-1-ulf.hansson@linaro.org>
Similar to the dev_set_drv_sync_state() helper, let's add another one to
allow subsystem level code to set the ->queue_sync_state() callback for a
driver that has not already set it.
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
include/linux/device.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index e65d564f01cd..f812e70bdf22 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -994,6 +994,18 @@ static inline int dev_set_drv_sync_state(struct device *dev,
return 0;
}
+static inline int dev_set_drv_queue_sync_state(struct device *dev,
+ void (*fn)(struct device *dev))
+{
+ if (!dev || !dev->driver)
+ return 0;
+ if (dev->driver->queue_sync_state && dev->driver->queue_sync_state != fn)
+ return -EBUSY;
+ if (!dev->driver->queue_sync_state)
+ dev->driver->queue_sync_state = fn;
+ return 0;
+}
+
static inline void dev_set_removable(struct device *dev,
enum device_removable removable)
{
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/9] driver core / pmdomain: Add support for fined grained sync_state
From: Ulf Hansson @ 2026-04-10 10:40 UTC (permalink / raw)
To: Saravana Kannan, Rafael J . Wysocki, Greg Kroah-Hartman, linux-pm
Cc: Sudeep Holla, Cristian Marussi, Kevin Hilman, Stephen Boyd,
Marek Szyprowski, Bjorn Andersson, Abel Vesa, Peng Fan,
Tomi Valkeinen, Maulik Shah, Konrad Dybcio, Thierry Reding,
Jonathan Hunter, Geert Uytterhoeven, Dmitry Baryshkov,
Ulf Hansson, linux-arm-kernel, linux-kernel
Since the introduction [1] of the common sync_state support for pmdomains
(genpd), we have encountered a lot of various interesting problems. In most
cases the new behaviour of genpd triggered some weird platform specific bugs.
That said, in LPC in Tokyo me and Saravana hosted a session to walk through the
remaining limitations that we have found for genpd's sync state support. In
particular, we discussed the problems we have for the so-called onecell power
domain providers, where a single provider typically provides multiple
independent power domains, all with their own set of consumers.
Note that, onecell power domain providers are very common. It's being used by
many SoCs/platforms/technologies. To name a few:
SCMI, Qualcomm, NXP, Mediatek, Renesas, TI, etc.
Anyway, in these cases, the generic sync_state mechanism with fw_devlink isn't
fine grained enough, as we end up waiting for all consumers for all power
domains before the ->sync_callback gets called for the supplier/provider. In
other words, we may end up keeping unused power domains powered-on, for no good
reasons.
The series intends to fix this problem. Please have a look at the commit
messages for more details and help review/test!
Kind regards
Ulf Hansson
[1]
https://lore.kernel.org/all/20250701114733.636510-1-ulf.hansson@linaro.org/
Ulf Hansson (9):
driver core: Enable suppliers to implement fine grained sync_state
support
driver core: Add dev_set_drv_queue_sync_state()
pmdomain: core: Move genpd_get_from_provider()
pmdomain: core: Add initial fine grained sync_state support
pmdomain: core: Extend fine grained sync_state to more onecell
providers
pmdomain: core: Export a common function for ->queue_sync_state()
pmdomain: renesas: rcar-gen4-sysc: Drop GENPD_FLAG_NO_STAY_ON
pmdomain: renesas: rcar-sysc: Drop GENPD_FLAG_NO_STAY_ON
pmdomain: renesas: rmobile-sysc: Drop GENPD_FLAG_NO_STAY_ON
drivers/base/core.c | 7 +-
drivers/pmdomain/core.c | 205 ++++++++++++++++++----
drivers/pmdomain/renesas/rcar-gen4-sysc.c | 1 -
drivers/pmdomain/renesas/rcar-sysc.c | 1 -
drivers/pmdomain/renesas/rmobile-sysc.c | 3 +-
include/linux/device.h | 12 ++
include/linux/device/driver.h | 7 +
include/linux/pm_domain.h | 3 +
8 files changed, 197 insertions(+), 42 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH net-next v3 00/12] net: airoha: Support multiple net_devices connected to the same GDM port
From: Lorenzo Bianconi @ 2026-04-10 10:39 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Christian Marangi,
Benjamin Larsson, linux-arm-kernel, linux-mediatek, netdev,
devicetree, Xuegang Lu
In-Reply-To: <20260409195645.16c68979@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 629 bytes --]
On Apr 09, Jakub Kicinski wrote:
> On Mon, 06 Apr 2026 12:34:05 +0200 Lorenzo Bianconi wrote:
> > EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
> > Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw arbiter that
> > manages the traffic in a TDM manner. As a result multiple net_devices can
> > connect to the same GDM{3,4} port and there is a theoretical "1:n"
> > relation between GDM ports and net_devices.
>
> Still waiting for the device tree review. I'm going to blindly send out
> the Sashiko review, please comment if any of it makes sense?
ack, I will do.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v3 10/12] net: airoha: Do not stop GDM port if it is shared
From: Lorenzo Bianconi @ 2026-04-10 10:35 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew+netdev, davem, edumazet, pabeni, robh, krzk+dt, conor+dt,
ansuelsmth, benjamin.larsson, linux-arm-kernel, linux-mediatek,
netdev, devicetree, Xuegang Lu
In-Reply-To: <20260410025726.1810041-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4665 bytes --]
> This is an AI-generated review of your patch. The human sending this
> email says "For your consideration."
> ---
> net: airoha: Do not stop GDM port if it is shared
>
> Theoretically, in the current codebase, two independent net_devices can
> be connected to the same GDM port so we need to check the GDM port is not
> used by any other running net_device before setting the forward
> configuration to FE_PSE_PORT_DROP.
>
> Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
>
> > diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> > index fd27ba13029bd..5b0cd37b155e4 100644
> > --- a/drivers/net/ethernet/airoha/airoha_eth.c
> > +++ b/drivers/net/ethernet/airoha/airoha_eth.c
>
> [ ... ]
>
> > @@ -1688,18 +1693,18 @@ static int airoha_dev_stop(struct net_device *netdev)
> > struct airoha_gdm_dev *dev = netdev_priv(netdev);
> > struct airoha_gdm_port *port = dev->port;
> > struct airoha_qdma *qdma = dev->qdma;
> > - int i, err;
> > + int i;
> >
> > netif_tx_disable(netdev);
> > - err = airoha_set_vip_for_gdm_port(dev, false);
> > - if (err)
> > - return err;
> > -
> > for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++)
> > netdev_tx_reset_subqueue(netdev, i);
> >
> > - airoha_set_gdm_port_fwd_cfg(qdma->eth, REG_GDM_FWD_CFG(port->id),
> > - FE_PSE_PORT_DROP);
> > + if (atomic_dec_and_test(&port->users)) {
> > + airoha_set_vip_for_gdm_port(dev, false);
> > + airoha_set_gdm_port_fwd_cfg(qdma->eth,
> > + REG_GDM_FWD_CFG(port->id),
> > + FE_PSE_PORT_DROP);
> > + }
> >
> > if (atomic_dec_and_test(&qdma->users)) {
> > airoha_qdma_clear(qdma, REG_QDMA_GLOBAL_CFG,
> > GLOBAL_CFG_TX_DMA_EN_MASK |
> > GLOBAL_CFG_RX_DMA_EN_MASK);
> >
> > for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++) {
> > if (!qdma->q_tx[i].ndesc)
> > continue;
> >
> > airoha_qdma_cleanup_tx_queue(&qdma->q_tx[i]);
> > }
> > }
>
> This problem wasn't introduced by this patch, but does the QDMA teardown
> path have a DMA corruption vulnerability here?
>
> When GLOBAL_CFG_TX_DMA_EN_MASK is cleared, it fails to poll
> GLOBAL_CFG_TX_DMA_BUSY_MASK, proceeding to unmap memory while the hardware
> DMA engine may still be processing in-flight descriptors.
>
> Furthermore, airoha_qdma_cleanup_tx_queue() unmaps the DMA addresses and
> frees the SKBs, but it does not appear to clear the physical hardware
> descriptors or reset the hardware ring pointers (REG_TX_CPU_IDX /
> REG_TX_DMA_IDX).
>
> When the device is later reopened in airoha_dev_open(),
> GLOBAL_CFG_TX_DMA_EN_MASK is set again without re-initializing the rings.
> Will the hardware DMA engine resume fetching from its previous index,
> processing stale descriptors whose backing memory was already unmapped
> and freed?
ack, I will work on it with a dedicated patch.
>
> [ ... ]
>
> > @@ -1851,10 +1856,22 @@ static void airoha_dev_get_stats64(struct net_device *netdev,
> > static int airoha_dev_change_mtu(struct net_device *netdev, int mtu)
> > {
> > struct airoha_gdm_dev *dev = netdev_priv(netdev);
> > + u32 cur_len, len = ETH_HLEN + mtu + ETH_FCS_LEN;
> > struct airoha_gdm_port *port = dev->port;
> > - u32 len = ETH_HLEN + mtu + ETH_FCS_LEN;
> > struct airoha_eth *eth = dev->eth;
> >
> > + cur_len = FIELD_GET(GDM_LONG_LEN_MASK,
> > + airoha_fe_rr(eth, REG_GDM_LEN_CFG(port->id)));
> > + if (len < cur_len) {
> > + u8 port_refcnt = atomic_read(&port->users);
> > +
> > + /* We can decrease the device MTU just if the GDM port is
> > + * not shared or if the other device is not running.
> > + */
> > + if (port_refcnt > 1 || (port_refcnt && !netif_running(netdev)))
> > + return -EBUSY;
> > + }
> > +
>
> Does this MTU decrease validation create a state trap on shared ports?
>
> If both eth0 and eth1 (sharing a port) are up, and a user increases eth0 MTU
> to 9000, the hardware MTU updates to 9000. If the user then tries to lower
> eth0 MTU back to 1500, len < cur_len evaluates to true. Because eth1 is also
> up (port_refcnt > 1), this returns -EBUSY.
>
> This would prevent either interface from decreasing its MTU without fully
> bringing down the sibling interface.
>
> Should the software netdev->mtu be decoupled from the hardware validation,
> allowing valid MTU changes in software while dynamically programming the
> hardware MTU to the maximum of all currently up interfaces on the shared
> port?
It seems more correct to me avoid receiving in the stack packet bigger than the
configured 'SW MTU".
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Andrea della Porta @ 2026-04-10 10:27 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Andrea della Porta, linux-pwm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
Stanimir Varbanov
In-Reply-To: <adiW1tBC8Imd14LD@monoceros>
Hi Uwe,
On 08:27 Fri 10 Apr , Uwe Kleine-König wrote:
> Hello Andrea,
>
> On Thu, Apr 09, 2026 at 06:16:41PM +0200, Andrea della Porta wrote:
> > On 23:45 Sun 05 Apr , Uwe Kleine-König wrote:
> > > On Fri, Apr 03, 2026 at 04:31:55PM +0200, Andrea della Porta wrote:
> > > > +static void rp1_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
> > > > +{
> > > > + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> > > > + u32 value;
> > > > +
> > > > + value = readl(rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> > > > + value &= ~PWM_MODE_MASK;
> > > > + writel(value, rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> > > > +
> > > > + rp1_pwm_apply_config(chip, pwm);
> > >
> > > What is the purpose of this call?
> >
> > To update the configuration on the next PWM strobe in order to avoid
> > glitches. I'll add a short comment in the code.
>
> .pwm_free() should not touch the hardware configuration. Changing the
> pinmuxing (which I guess is the purpose of clearing PWM_MODE_MASK) is
> somewhat a grey area. If that saves energy, that's okish. Otherwise
> not interfering with the operation of the PWM (e.g. to keep a display on
> during kexec or so) is preferred.
Sorry I should've been more clear on this. The pinmux/conf is not changed
at all by this mask, only the PWM output mode is. The controller can output
several type of waveforms and clearing PWM_MODE_MASK is just setting the
controller to output a 0, which is the reset default i.e. the same value
as just before exporting the channel.
I guess this is the expected behaviour in case of a fan, it should stop
spinning in case you unexport the pwm channel, but I see it could be
different with displays.
Honestly I don't have a strong opinion about that, please just let me
know if I should drop that pwm_free entirely.
>
> > > > +static int rp1_pwm_resume(struct device *dev)
> > > > +{
> > > > + struct rp1_pwm *rp1 = dev_get_drvdata(dev);
> > > > +
> > > > + return clk_prepare_enable(rp1->clk);
> > >
> > > Hmm, if this fails and then the driver is unbound, the clk operations
> > > are not balanced.
> >
> > I'll add some flags to check if the clock is really enabled or not.
>
> To be honest, I guess that is a problem of several drivers, not only in
> drivers/pwm. If this complicates the driver, I guess addressing this
> isn't very critical.
I'll come up with something, we can always drop this check if deemed
too 'noisy'.
Many thanks,
Andrea
>
> Best regards
> Uwe
^ permalink raw reply
* Re: [PATCH net-next v3 09/12] net: airoha: Support multiple net_devices for a single FE GDM port
From: Lorenzo Bianconi @ 2026-04-10 10:19 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew+netdev, davem, edumazet, pabeni, robh, krzk+dt, conor+dt,
ansuelsmth, benjamin.larsson, linux-arm-kernel, linux-mediatek,
netdev, devicetree
In-Reply-To: <20260410025724.1810007-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 8640 bytes --]
On Apr 09, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email says "For your consideration."
> ---
> net: airoha: Support multiple net_devices for a single FE GDM port
>
> This commit introduces support for mapping multiple net_device interfaces
> to a single Frame Engine (FE) GDM port via an external hardware arbiter.
> It updates the rx/tx paths, port allocation, and registration logic to
> handle the new net_device array.
>
> > diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> > --- a/drivers/net/ethernet/airoha/airoha_eth.c
> > +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> [ ... ]
> > @@ -615,9 +617,8 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
> > u32 hash, reason, msg1 = le32_to_cpu(desc->msg1);
> > struct page *page = virt_to_head_page(e->buf);
> > u32 desc_ctrl = le32_to_cpu(desc->ctrl);
> > - struct airoha_gdm_port *port;
> > - struct net_device *netdev;
> > - int data_len, len, p;
> > + struct airoha_gdm_dev *dev;
> > + int data_len, len;
> >
> > if (!(desc_ctrl & QDMA_DESC_DONE_MASK))
> > break;
>
> While looking at this code, I noticed an issue that predates this patch.
> Can the lack of a memory barrier after checking the descriptor ownership bit
> cause stale reads?
>
> The driver checks QDMA_DESC_DONE_MASK to verify that the hardware has finished
> writing the descriptor. However, it reads desc->msg1 before this check and
> without a dma_rmb():
>
> u32 hash, reason, msg1 = le32_to_cpu(desc->msg1);
> struct page *page = virt_to_head_page(e->buf);
> u32 desc_ctrl = le32_to_cpu(desc->ctrl);
>
> if (!(desc_ctrl & QDMA_DESC_DONE_MASK))
> break;
>
> Since weakly ordered architectures can reorder memory reads, could the CPU
> prefetch msg1 before the DMA engine writes the new descriptor values, leading
> to routing the packet to the wrong gdm_dev?
This issue has been already fixed with the following commit:
commit 4ae0604a0673e11e2075b178387151fcad5111b5
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date: Tue Apr 7 08:48:04 2026 +0200
net: airoha: Add dma_rmb() and READ_ONCE() in airoha_qdma_rx_process()
Add missing dma_rmb() in airoha_qdma_rx_process routine to make sure the
DMA read operations are completed when the NIC reports the processing on
the current descriptor is done. Moreover, add missing READ_ONCE() in
airoha_qdma_rx_process() for DMA descriptor control fields in order to
avoid any compiler reordering.
>
> [ ... ]
> > @@ -1764,9 +1765,7 @@ static int airoha_set_gdm2_loopback(struct airoha_gdm_dev *dev)
> > airoha_fe_clear(eth, REG_FE_VIP_PORT_EN, BIT(AIROHA_GDM2_IDX));
> > airoha_fe_clear(eth, REG_FE_IFC_PORT_EN, BIT(AIROHA_GDM2_IDX));
> >
> > - /* XXX: handle XSI_USB_PORT and XSI_PCE1_PORT */
> > - nbq = port->id == AIROHA_GDM3_IDX && airoha_is_7581(eth) ? 4 : 0;
> > - src_port = eth->soc->ops.get_src_port_id(port, nbq);
> > + src_port = eth->soc->ops.get_src_port_id(port, dev->nbq);
> > if (src_port < 0)
> > return src_port;
>
> Can configuring the loopback for one device break connectivity for other
> devices sharing the same port?
>
> When multiple net_devices (like PCIE0 and PCIE1 on GDM3) open and call
> airoha_set_gdm2_loopback(), they modify global hardware registers such as
> REG_FE_WAN_PORT.
>
> Since WAN0_MASK is unconditionally updated to track the current device's
> src_port:
>
> airoha_fe_rmw(eth, REG_FE_WAN_PORT,
> WAN1_EN_MASK | WAN1_MASK | WAN0_MASK,
> FIELD_PREP(WAN0_MASK, src_port));
>
> won't the last configured device clobber the hardware state for the others?
This issue is fixed with the following patch in the series:
commit 008995bd8f39c5fdf37a933fa3c962e7ef52e8c6
Author: Lorenzo Bianconi <lorenzo@kernel.org>
Date: Fri Apr 3 12:07:27 2026 +0200
net: airoha: Introduce WAN device flag
Introduce WAN flag to specify if a given device is used to transmit/receive
WAN or LAN traffic. Current codebase supports specifying LAN/WAN device
configuration in ndo_init() callback during device bootstrap.
Please note it is possible to specify multiple LAN devices but just a
single WAN one.
>
> [ ... ]
> > @@ -1987,7 +1986,8 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
> > }
> >
> > fport = airoha_get_fe_port(dev);
> > - msg1 = FIELD_PREP(QDMA_ETH_TXMSG_FPORT_MASK, fport) |
> > + msg1 = FIELD_PREP(QDMA_ETH_TXMSG_NBOQ_MASK, dev->nbq) |
> > + FIELD_PREP(QDMA_ETH_TXMSG_FPORT_MASK, fport) |
> > FIELD_PREP(QDMA_ETH_TXMSG_METER_MASK, 0x7f);
> >
> > q = &qdma->q_tx[qid];
>
> Does sharing the hardware QDMA TX queues among multiple net_device instances
> introduce a permanent transmit stall?
>
> In airoha_dev_xmit(), if a shared hardware queue is full, the driver stops the
> netdev_queue of the specific netdev making the call:
>
> if (q->queued + nr_frags >= q->ndesc) {
> /* not enough space in the queue */
> netif_tx_stop_queue(txq);
> spin_unlock_bh(&q->lock);
> return NETDEV_TX_BUSY;
> }
>
> However, the TX completion handler (airoha_tx_irq_process()) only wakes the
> queue of the netdev attached to the completed packet. If an interface's TX
> queue is stopped but it has no pending packets in the hardware queue (because
> another interface filled it), will it ever get woken up?
This issue is orthogonal to this series and it will be fixed with a dedicated
patch.
>
> [ ... ]
> > @@ -2955,11 +2958,25 @@ static int airoha_alloc_gdm_device(struct airoha_eth *eth,
> > netdev->dev_addr);
> > }
> >
> > + /* Allowed nbq for EN7581 on GDM3 port are 4 and 5 for PCIE0
> > + * and PCIE1 respectively.
> > + */
> > + index = nbq;
> > + if (index && airoha_is_7581(eth) && port->id == AIROHA_GDM3_IDX)
> > + index -= 4;
> > +
> > + if (index >= ARRAY_SIZE(port->devs) || port->devs[index]) {
> > + dev_err(eth->dev, "invalid nbq id: %d\n", nbq);
> > + return -EINVAL;
> > + }
> > +
> > + netdev->dev.of_node = of_node_get(np);
> > dev = netdev_priv(netdev);
>
> Does this code leak the of_node reference?
>
> The node reference is explicitly incremented via of_node_get(np). The networking
> core does not automatically drop explicit of_node references on free_netdev().
> Without a matching of_node_put() in the error paths or the driver's teardown
> function (airoha_remove()), will this reference permanently leak when the device
> is destroyed?
ack, I will fix it in v4.
>
> [ ... ]
> > @@ -3003,7 +3021,43 @@ static int airoha_alloc_gdm_port(struct airoha_eth *eth,
> > if (err)
> > return err;
> >
> > - return airoha_alloc_gdm_device(eth, port, np);
> > + for_each_child_of_node(np, node) {
> > + /* Multiple external serdes connected to the FE GDM port via an
> > + * external arbiter.
> > + */
> > + const __be32 *nbq_ptr;
> > + int nbq;
> > +
> > + if (!of_device_is_compatible(node, "airoha,eth-port"))
> > + continue;
> > +
> > + d++;
> > + if (!of_device_is_available(node))
> > + continue;
> > +
> > + nbq_ptr = of_get_property(node, "reg", NULL);
> > + if (!nbq_ptr) {
> > + dev_err(eth->dev, "missing nbq id\n");
> > + of_node_put(node);
> > + return -EINVAL;
> > + }
> > +
> > + /* Verify the provided nbq parameter is valid */
> > + nbq = be32_to_cpup(nbq_ptr);
> > + err = eth->soc->ops.get_src_port_id(port, nbq);
> > + if (err < 0) {
> > + of_node_put(node);
> > + return err;
> > + }
> > +
> > + err = airoha_alloc_gdm_device(eth, port, nbq, node);
> > + if (err) {
> > + of_node_put(node);
> > + return err;
> > + }
> > + }
> > +
> > + return !d ? airoha_alloc_gdm_device(eth, port, 0, np) : 0;
> > }
>
> Does passing 0 for nbq in the fallback path break older device trees on the
> EN7581 SoC?
>
> Later, when the interface is brought up, airoha_set_gdm2_loopback() calls
> airoha_en7581_get_src_port_id(), which returns -EINVAL for GDM3 if nbq is
> not 4 or 5:
>
> switch (port->id) {
> case AIROHA_GDM3_IDX:
> /* 7581 SoC supports PCIe serdes on GDM3 port */
> if (nbq == 4)
> return HSGMII_LAN_7581_PCIE0_SRCPORT;
> if (nbq == 5)
> return HSGMII_LAN_7581_PCIE1_SRCPORT;
> break;
>
> If nbq is hardcoded to 0 for legacy DTs, won't this cause interface
> initialization to fail unconditionally for GDM3?
ack, I will fix it in v4.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH 4/4] arm64: dts: amlogic: t7: Add clk measure support
From: Jian Hu @ 2026-04-10 10:03 UTC (permalink / raw)
To: Neil Armstrong, Jerome Brunet, Kevin Hilman, Michael Turquette,
Martin Blumenstingl, robh+dt, Rob Herring, Krzysztof Kozlowski
Cc: Jian Hu, devicetree, linux-amlogic, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260410100329.3167482-1-jian.hu@amlogic.com>
Add the clock measure device to the T7 SoC family.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 7fe72c94ed62..cec2ea74850d 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -701,6 +701,11 @@ pwm_ao_cd: pwm@60000 {
status = "disabled";
};
+ clock-measurer@48000 {
+ compatible = "amlogic,t7-clk-measure";
+ reg = <0x0 0x48000 0x0 0x1c>;
+ };
+
sd_emmc_a: mmc@88000 {
compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
reg = <0x0 0x88000 0x0 0x800>;
--
2.47.1
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: meson: a1: Add clk measure support
From: Jian Hu @ 2026-04-10 10:03 UTC (permalink / raw)
To: Neil Armstrong, Jerome Brunet, Kevin Hilman, Michael Turquette,
Martin Blumenstingl, robh+dt, Rob Herring, Krzysztof Kozlowski
Cc: Jian Hu, devicetree, linux-amlogic, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260410100329.3167482-1-jian.hu@amlogic.com>
Add the clock measure device to the A1 SoC family.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
index 348411411f3d..6f6a6145cba1 100644
--- a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
@@ -576,6 +576,11 @@ saradc: adc@2c00 {
status = "disabled";
};
+ clock-measurer@3400 {
+ compatible = "amlogic,a1-clk-measure";
+ reg = <0x0 0x3400 0x0 0x1c>;
+ };
+
i2c1: i2c@5c00 {
compatible = "amlogic,meson-axg-i2c";
status = "disabled";
--
2.47.1
^ permalink raw reply related
* [PATCH 2/4] soc: amlogic: clk-measure: Add A1 and T7 support
From: Jian Hu @ 2026-04-10 10:03 UTC (permalink / raw)
To: Neil Armstrong, Jerome Brunet, Kevin Hilman, Michael Turquette,
Martin Blumenstingl, robh+dt, Rob Herring, Krzysztof Kozlowski
Cc: Jian Hu, devicetree, linux-amlogic, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260410100329.3167482-1-jian.hu@amlogic.com>
Add support for the A1 and T7 SoC family in amlogic clk measure.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
---
drivers/soc/amlogic/meson-clk-measure.c | 272 ++++++++++++++++++++++++
1 file changed, 272 insertions(+)
diff --git a/drivers/soc/amlogic/meson-clk-measure.c b/drivers/soc/amlogic/meson-clk-measure.c
index d862e30a244e..083524671b76 100644
--- a/drivers/soc/amlogic/meson-clk-measure.c
+++ b/drivers/soc/amlogic/meson-clk-measure.c
@@ -787,6 +787,258 @@ static const struct meson_msr_id clk_msr_s4[] = {
};
+static struct meson_msr_id clk_msr_a1[] = {
+ CLK_MSR_ID(0, "tdmout_b_sclk"),
+ CLK_MSR_ID(1, "tdmout_a_sclk"),
+ CLK_MSR_ID(2, "tdmin_lb_sclk"),
+ CLK_MSR_ID(3, "tdmin_b_sclk"),
+ CLK_MSR_ID(4, "tdmin_a_sclk"),
+ CLK_MSR_ID(5, "vad"),
+ CLK_MSR_ID(6, "resamplea"),
+ CLK_MSR_ID(7, "pdm_sysclk"),
+ CLK_MSR_ID(8, "pdm_dclk"),
+ CLK_MSR_ID(9, "locker_out"),
+ CLK_MSR_ID(10, "locker_in"),
+ CLK_MSR_ID(11, "spdifin"),
+ CLK_MSR_ID(12, "tdmin_vad"),
+ CLK_MSR_ID(13, "au_adc"),
+ CLK_MSR_ID(14, "au_dac"),
+ CLK_MSR_ID(16, "spicc_a"),
+ CLK_MSR_ID(17, "spifc"),
+ CLK_MSR_ID(18, "sd_emmc_a"),
+ CLK_MSR_ID(19, "dmcx4"),
+ CLK_MSR_ID(20, "dmc"),
+ CLK_MSR_ID(21, "psram"),
+ CLK_MSR_ID(22, "cecb"),
+ CLK_MSR_ID(23, "ceca"),
+ CLK_MSR_ID(24, "ts"),
+ CLK_MSR_ID(25, "pwm_f"),
+ CLK_MSR_ID(26, "pwm_e"),
+ CLK_MSR_ID(27, "pwm_d"),
+ CLK_MSR_ID(28, "pwm_c"),
+ CLK_MSR_ID(29, "pwm_b"),
+ CLK_MSR_ID(30, "pwm_a"),
+ CLK_MSR_ID(31, "saradc"),
+ CLK_MSR_ID(32, "usb_bus"),
+ CLK_MSR_ID(33, "dsp_b"),
+ CLK_MSR_ID(34, "dsp_a"),
+ CLK_MSR_ID(35, "axi"),
+ CLK_MSR_ID(36, "sys"),
+ CLK_MSR_ID(40, "rng_ring_osc0"),
+ CLK_MSR_ID(41, "rng_ring_osc1"),
+ CLK_MSR_ID(42, "rng_ring_osc2"),
+ CLK_MSR_ID(43, "rng_ring_osc3"),
+ CLK_MSR_ID(44, "dds_out"),
+ CLK_MSR_ID(45, "cpu_clk_div16"),
+ CLK_MSR_ID(46, "gpio_msr"),
+ CLK_MSR_ID(50, "osc_ring_cpu0"),
+ CLK_MSR_ID(51, "osc_ring_cpu1"),
+ CLK_MSR_ID(54, "osc_ring_top0"),
+ CLK_MSR_ID(55, "osc_ring_top1"),
+ CLK_MSR_ID(56, "osc_ring_ddr"),
+ CLK_MSR_ID(57, "osc_ring_dmc"),
+ CLK_MSR_ID(58, "osc_ring_dspa"),
+ CLK_MSR_ID(59, "osc_ring_dspb"),
+ CLK_MSR_ID(60, "osc_ring_rama"),
+ CLK_MSR_ID(61, "osc_ring_ramb"),
+};
+
+static struct meson_msr_id clk_msr_t7[] = {
+ CLK_MSR_ID(0, "sys"),
+ CLK_MSR_ID(1, "axi"),
+ CLK_MSR_ID(2, "rtc"),
+ CLK_MSR_ID(3, "dspa"),
+ CLK_MSR_ID(4, "dspb"),
+ CLK_MSR_ID(5, "mali"),
+ CLK_MSR_ID(6, "sys_cpu_clk_div16"),
+ CLK_MSR_ID(7, "ceca"),
+ CLK_MSR_ID(8, "cecb"),
+ CLK_MSR_ID(10, "fclk_div5"),
+ CLK_MSR_ID(11, "mpll0"),
+ CLK_MSR_ID(12, "mpll1"),
+ CLK_MSR_ID(13, "mpll2"),
+ CLK_MSR_ID(14, "mpll3"),
+ CLK_MSR_ID(15, "mpll_50m"),
+ CLK_MSR_ID(16, "pcie_inp"),
+ CLK_MSR_ID(17, "pcie_inn"),
+ CLK_MSR_ID(18, "mpll_test_out"),
+ CLK_MSR_ID(19, "hifi_pll"),
+ CLK_MSR_ID(20, "gp0_pll"),
+ CLK_MSR_ID(21, "gp1_pll"),
+ CLK_MSR_ID(22, "eth_mppll_50m"),
+ CLK_MSR_ID(23, "sys_pll_div16"),
+ CLK_MSR_ID(24, "ddr_dpll_pt"),
+ CLK_MSR_ID(25, "earcrx_pll"),
+ CLK_MSR_ID(26, "paie1_clk_inp"),
+ CLK_MSR_ID(27, "paie1_clk_inn"),
+ CLK_MSR_ID(28, "amlgdc"),
+ CLK_MSR_ID(29, "gdc"),
+ CLK_MSR_ID(30, "mod_eth_phy_ref"),
+ CLK_MSR_ID(31, "mod_eth_tx"),
+ CLK_MSR_ID(32, "eth_clk125Mhz"),
+ CLK_MSR_ID(33, "eth_clk_rmii"),
+ CLK_MSR_ID(34, "co_clkin_to_mac"),
+ CLK_MSR_ID(35, "mod_eth_rx_clk_rmii"),
+ CLK_MSR_ID(36, "co_rx"),
+ CLK_MSR_ID(37, "co_tx"),
+ CLK_MSR_ID(38, "eth_phy_rxclk"),
+ CLK_MSR_ID(39, "eth_phy_plltxclk"),
+ CLK_MSR_ID(40, "ephy_test"),
+ CLK_MSR_ID(41, "dsi_b_meas"),
+ CLK_MSR_ID(42, "hdmirx_apl"),
+ CLK_MSR_ID(43, "hdmirx_tmds"),
+ CLK_MSR_ID(44, "hdmirx_cable"),
+ CLK_MSR_ID(45, "hdmirx_apll_clk_audio"),
+ CLK_MSR_ID(46, "hdmirx_5m"),
+ CLK_MSR_ID(47, "hdmirx_2m"),
+ CLK_MSR_ID(48, "hdmirx_cfg"),
+ CLK_MSR_ID(49, "hdmirx_hdcp2x_eclk"),
+ CLK_MSR_ID(50, "vid_pll0_div"),
+ CLK_MSR_ID(51, "hdmi_vid_pll"),
+ CLK_MSR_ID(54, "vdac_clk"),
+ CLK_MSR_ID(55, "vpu_clk_buf"),
+ CLK_MSR_ID(56, "mod_tcon_clko"),
+ CLK_MSR_ID(57, "lcd_an_clk_ph2"),
+ CLK_MSR_ID(58, "lcd_an_clk_ph3"),
+ CLK_MSR_ID(59, "hdmi_tx_pixel"),
+ CLK_MSR_ID(60, "vdin_meas"),
+ CLK_MSR_ID(61, "vpu_clk"),
+ CLK_MSR_ID(62, "vpu_clkb"),
+ CLK_MSR_ID(63, "vpu_clkb_tmp"),
+ CLK_MSR_ID(64, "vpu_clkc"),
+ CLK_MSR_ID(65, "vid_lock"),
+ CLK_MSR_ID(66, "vapbclk"),
+ CLK_MSR_ID(67, "ge2d"),
+ CLK_MSR_ID(68, "aud_pll"),
+ CLK_MSR_ID(69, "aud_sck"),
+ CLK_MSR_ID(70, "dsi_a_meas"),
+ CLK_MSR_ID(72, "mipi_csi_phy"),
+ CLK_MSR_ID(73, "mipi_isp"),
+ CLK_MSR_ID(76, "hdmitx_tmds"),
+ CLK_MSR_ID(77, "hdmitx_sys"),
+ CLK_MSR_ID(78, "hdmitx_fe"),
+ CLK_MSR_ID(80, "hdmitx_prif"),
+ CLK_MSR_ID(81, "hdmitx_200m"),
+ CLK_MSR_ID(82, "hdmitx_aud"),
+ CLK_MSR_ID(83, "hdmitx_pnx"),
+ CLK_MSR_ID(84, "spicc5"),
+ CLK_MSR_ID(85, "spicc4"),
+ CLK_MSR_ID(86, "spicc3"),
+ CLK_MSR_ID(87, "spicc2"),
+ CLK_MSR_ID(93, "vdec"),
+ CLK_MSR_ID(94, "wave521_aclk"),
+ CLK_MSR_ID(95, "wave521_cclk"),
+ CLK_MSR_ID(96, "wave521_bclk"),
+ CLK_MSR_ID(97, "hcodec"),
+ CLK_MSR_ID(98, "hevcb"),
+ CLK_MSR_ID(99, "hevcf"),
+ CLK_MSR_ID(100, "hdmi_aud_pll"),
+ CLK_MSR_ID(101, "hdmi_acr_ref"),
+ CLK_MSR_ID(102, "hdmi_meter"),
+ CLK_MSR_ID(103, "hdmi_vid"),
+ CLK_MSR_ID(104, "hdmi_aud"),
+ CLK_MSR_ID(105, "hdmi_dsd"),
+ CLK_MSR_ID(108, "dsi1_phy"),
+ CLK_MSR_ID(109, "dsi0_phy"),
+ CLK_MSR_ID(110, "smartcard"),
+ CLK_MSR_ID(111, "sar_adc"),
+ CLK_MSR_ID(113, "sd_emmc_c"),
+ CLK_MSR_ID(114, "sd_emmc_b"),
+ CLK_MSR_ID(115, "sd_emmc_a"),
+ CLK_MSR_ID(116, "gpio_msr"),
+ CLK_MSR_ID(117, "spicc1"),
+ CLK_MSR_ID(118, "spicc0"),
+ CLK_MSR_ID(119, "anakin"),
+ CLK_MSR_ID(121, "ts_clk(temp sensor)"),
+ CLK_MSR_ID(122, "ts_a73"),
+ CLK_MSR_ID(123, "ts_a53"),
+ CLK_MSR_ID(124, "ts_nna"),
+ CLK_MSR_ID(130, "audio_vad"),
+ CLK_MSR_ID(131, "acodec_dac_clk_x128"),
+ CLK_MSR_ID(132, "audio_locker_in"),
+ CLK_MSR_ID(133, "audio_locker_out"),
+ CLK_MSR_ID(134, "audio_tdmout_c_sclk"),
+ CLK_MSR_ID(135, "audio_tdmout_b_sclk"),
+ CLK_MSR_ID(136, "audio_tdmout_a_sclk"),
+ CLK_MSR_ID(137, "audio_tdmin_lb_sclk"),
+ CLK_MSR_ID(138, "audio_tdmin_c_sclk"),
+ CLK_MSR_ID(139, "audio_tdmin_b_sclk"),
+ CLK_MSR_ID(140, "audio_tdmin_a_sclk"),
+ CLK_MSR_ID(141, "audio_resamplea"),
+ CLK_MSR_ID(142, "audio_pdm_sysclk"),
+ CLK_MSR_ID(143, "audio_spdifoutb_mst"),
+ CLK_MSR_ID(144, "audio_spdifout_mst"),
+ CLK_MSR_ID(145, "audio_spdifin_mst"),
+ CLK_MSR_ID(146, "audio_pdm_dclk"),
+ CLK_MSR_ID(147, "audio_resampleb"),
+ CLK_MSR_ID(148, "earcrx_pll_dmac"),
+ CLK_MSR_ID(156, "pwm_ao_h"),
+ CLK_MSR_ID(157, "pwm_ao_g"),
+ CLK_MSR_ID(158, "pwm_ao_f"),
+ CLK_MSR_ID(159, "pwm_ao_e"),
+ CLK_MSR_ID(160, "pwm_ao_d"),
+ CLK_MSR_ID(161, "pwm_ao_c"),
+ CLK_MSR_ID(162, "pwm_ao_b"),
+ CLK_MSR_ID(163, "pwm_ao_a"),
+ CLK_MSR_ID(164, "pwm_f"),
+ CLK_MSR_ID(165, "pwm_e"),
+ CLK_MSR_ID(166, "pwm_d"),
+ CLK_MSR_ID(167, "pwm_c"),
+ CLK_MSR_ID(168, "pwm_b"),
+ CLK_MSR_ID(169, "pwm_a"),
+ CLK_MSR_ID(170, "aclkm"),
+ CLK_MSR_ID(171, "mclk_pll"),
+ CLK_MSR_ID(172, "a73_sys_pll_div16"),
+ CLK_MSR_ID(173, "a73_cpu_clk_div16"),
+ CLK_MSR_ID(176, "rng_ring_0"),
+ CLK_MSR_ID(177, "rng_ring_1"),
+ CLK_MSR_ID(178, "rng_ring_2"),
+ CLK_MSR_ID(179, "rng_ring_3"),
+ CLK_MSR_ID(180, "am_ring_out0"),
+ CLK_MSR_ID(181, "am_ring_out1"),
+ CLK_MSR_ID(182, "am_ring_out2"),
+ CLK_MSR_ID(183, "am_ring_out3"),
+ CLK_MSR_ID(184, "am_ring_out4"),
+ CLK_MSR_ID(185, "am_ring_out5"),
+ CLK_MSR_ID(186, "am_ring_out6"),
+ CLK_MSR_ID(187, "am_ring_out7"),
+ CLK_MSR_ID(188, "am_ring_out8"),
+ CLK_MSR_ID(189, "am_ring_out9"),
+ CLK_MSR_ID(190, "am_ring_out10"),
+ CLK_MSR_ID(191, "am_ring_out11"),
+ CLK_MSR_ID(192, "am_ring_out12"),
+ CLK_MSR_ID(193, "am_ring_out13"),
+ CLK_MSR_ID(194, "am_ring_out14"),
+ CLK_MSR_ID(195, "am_ring_out15"),
+ CLK_MSR_ID(196, "am_ring_out16"),
+ CLK_MSR_ID(197, "am_ring_out17"),
+ CLK_MSR_ID(198, "am_ring_out18"),
+ CLK_MSR_ID(199, "am_ring_out19"),
+ CLK_MSR_ID(200, "mipi_csi_phy0"),
+ CLK_MSR_ID(201, "mipi_csi_phy1"),
+ CLK_MSR_ID(202, "mipi_csi_phy2"),
+ CLK_MSR_ID(203, "mipi_csi_phy3"),
+ CLK_MSR_ID(204, "vid_pll1_div"),
+ CLK_MSR_ID(205, "vid_pll2_div"),
+ CLK_MSR_ID(206, "am_ring_out20"),
+ CLK_MSR_ID(207, "am_ring_out21"),
+ CLK_MSR_ID(208, "am_ring_out22"),
+ CLK_MSR_ID(209, "am_ring_out23"),
+ CLK_MSR_ID(210, "am_ring_out24"),
+ CLK_MSR_ID(211, "am_ring_out25"),
+ CLK_MSR_ID(212, "am_ring_out26"),
+ CLK_MSR_ID(213, "am_ring_out27"),
+ CLK_MSR_ID(214, "am_ring_out28"),
+ CLK_MSR_ID(215, "am_ring_out29"),
+ CLK_MSR_ID(216, "am_ring_out30"),
+ CLK_MSR_ID(217, "am_ring_out31"),
+ CLK_MSR_ID(218, "am_ring_out32"),
+ CLK_MSR_ID(219, "enc0_if"),
+ CLK_MSR_ID(220, "enc2"),
+ CLK_MSR_ID(221, "enc1"),
+ CLK_MSR_ID(222, "enc0")
+};
+
static int meson_measure_id(struct meson_msr_id *clk_msr_id,
unsigned int duration)
{
@@ -1026,6 +1278,18 @@ static const struct meson_msr_data clk_msr_s4_data = {
.reg = &msr_reg_offset_v2,
};
+static const struct meson_msr_data clk_msr_a1_data = {
+ .msr_table = (void *)clk_msr_a1,
+ .msr_count = ARRAY_SIZE(clk_msr_a1),
+ .reg = &msr_reg_offset_v2,
+};
+
+static const struct meson_msr_data clk_msr_t7_data = {
+ .msr_table = (void *)clk_msr_t7,
+ .msr_count = ARRAY_SIZE(clk_msr_t7),
+ .reg = &msr_reg_offset_v2,
+};
+
static const struct of_device_id meson_msr_match_table[] = {
{
.compatible = "amlogic,meson-gx-clk-measure",
@@ -1059,6 +1323,14 @@ static const struct of_device_id meson_msr_match_table[] = {
.compatible = "amlogic,s4-clk-measure",
.data = &clk_msr_s4_data,
},
+ {
+ .compatible = "amlogic,a1-clk-measure",
+ .data = &clk_msr_a1_data,
+ },
+ {
+ .compatible = "amlogic,t7-clk-measure",
+ .data = &clk_msr_t7_data,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, meson_msr_match_table);
--
2.47.1
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: soc: amlogic: clk-measure: Add A1 and T7 compatible
From: Jian Hu @ 2026-04-10 10:03 UTC (permalink / raw)
To: Neil Armstrong, Jerome Brunet, Kevin Hilman, Michael Turquette,
Martin Blumenstingl, robh+dt, Rob Herring, Krzysztof Kozlowski
Cc: Jian Hu, devicetree, linux-amlogic, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260410100329.3167482-1-jian.hu@amlogic.com>
Add the Amlogic A1 and T7 compatible for the clk-measurer IP.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
---
.../bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml
index 39d4637c2d08..b1200e6940ac 100644
--- a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml
+++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml
@@ -24,6 +24,8 @@ properties:
- amlogic,meson-sm1-clk-measure
- amlogic,c3-clk-measure
- amlogic,s4-clk-measure
+ - amlogic,a1-clk-measure
+ - amlogic,t7-clk-measure
reg:
maxItems: 1
--
2.47.1
^ permalink raw reply related
* [PATCH 0/4] soc: amlogic: clk-measure: add A1 and T7 support
From: Jian Hu @ 2026-04-10 10:03 UTC (permalink / raw)
To: Neil Armstrong, Jerome Brunet, Kevin Hilman, Michael Turquette,
Martin Blumenstingl, robh+dt, Rob Herring, Krzysztof Kozlowski
Cc: Jian Hu, devicetree, linux-amlogic, linux-kernel,
linux-arm-kernel
This series adds Amlogic clock measurement support for A1 and T7 SoCs,
including binding updates, driver additions, and device tree enablement.
Jian Hu (4):
dt-bindings: soc: amlogic: clk-measure: Add A1 and T7 compatible
soc: amlogic: clk-measure: Add A1 and T7 support
arm64: dts: meson: a1: Add clk measure support
arm64: dts: amlogic: t7: Add clk measure support
.../amlogic/amlogic,meson-gx-clk-measure.yaml | 2 +
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 5 +
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 5 +
drivers/soc/amlogic/meson-clk-measure.c | 272 ++++++++++++++++++
4 files changed, 284 insertions(+)
--
2.47.1
^ permalink raw reply
* Re: [PATCH] pinctrl: mediatek: moore: implement gpio_chip::get_direction()
From: Bartosz Golaszewski @ 2026-04-10 9:54 UTC (permalink / raw)
To: Frank Wunderlich
Cc: bartosz.golaszewski, linux, sean.wang, linusw, matthias.bgg,
angelogioacchino.delregno, linux-mediatek, linux-gpio,
linux-kernel, linux-arm-kernel
In-Reply-To: <trinity-5e6f6a95-e576-4f97-9085-c6de21945eab-1775813076268@trinity-msg-rest-gmx-gmx-live-5cf7d7879b-qwfn5>
On Fri, Apr 10, 2026 at 11:24 AM Frank Wunderlich
<frank-w@public-files.de> wrote:
>
> > Gesendet: Freitag, 10. April 2026 um 09:09
> > Von: "Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>
> > An: "Frank Wunderlich" <linux@fw-web.de>, "Sean Wang" <sean.wang@kernel.org>, "Linus Walleij" <linusw@kernel.org>, "Matthias Brugger" <matthias.bgg@gmail.com>, "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com>, "Bartosz Golaszewski" <brgl@kernel.org>
> > CC: linux-mediatek@lists.infradead.org, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, "Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>
> > Betreff: [PATCH] pinctrl: mediatek: moore: implement gpio_chip::get_direction()
> >
> > If the gpio_chip::get_direction() callback is not implemented by the GPIO
> > controller driver, GPIOLIB emits a warning.
> >
> > Implement get_direction() for the GPIO part of pinctrl-moore.
> >
> > Fixes: 471e998c0e31 ("gpiolib: remove redundant callback check")
> > Fixes: e623c4303ed1 ("gpiolib: sanitize the return value of gpio_chip::get_direction()")
> > Reported-by: Frank Wunderlich <linux@fw-web.de>
>
> please use the email i used for SoB in my linked patch (closes link below), the other email i use only for sending patches due to mail provider limitation.
>
Linus: Can you fix this when applying, please?
Frank: Can you also leave your Tested-by under the patch?
Thanks,
Bartosz
^ permalink raw reply
* Re: [GIT PULL] Rockchip dts32 changes for 7.1 #2
From: Heiko Stuebner @ 2026-04-10 9:54 UTC (permalink / raw)
To: arm; +Cc: soc, linux-rockchip, linux-arm-kernel, Stephen Boyd, mturquette
In-Reply-To: <13980380.dW097sEU6C@phil>
Am Freitag, 3. April 2026, 15:39:31 Mitteleuropäische Sommerzeit schrieb Heiko Stuebner:
> Hi soc maintainers,
>
> please find below a new ARM32 Rockchip SoC for 7.1 . This goes on top
> of the generic arm32 changes I just sent.
>
>
> I've split this off from the other ARM32 changes, because this contains
> a shared clock header, shared between the devicetree side and the clock-
> driver side.
>
> The clock pull-request is sent [0], but not merged yet - probably after
> easter I guess.
>
> And while in the past this has always come together in time for the
> merge-window, I wasn't sure if in the soc multi-maintainer context the
> handling changes. So depending on your preference this could also wait
> until after the clock-subsystem-side got merged.
clock maintainers seem to be on vacation since 2026-03-25, so I'm not
so sure merging the related clock driver will happen in time anymore,
hence this PR should probably be skipped for now.
Ill rebase the SoC changes onto 7.1-rc1 once the clock driver gets
merged.
Heiko
^ permalink raw reply
* Re: [PATCH 7/7] clk: sunxi-ng: Add Allwinner A733 RTC CCU support
From: Junhui Liu @ 2026-04-10 9:49 UTC (permalink / raw)
To: wens, Junhui Liu
Cc: Michael Turquette, Stephen Boyd, Jernej Skrabec, Samuel Holland,
Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Ripard, linux-clk, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-rtc, devicetree, André Przywara
In-Reply-To: <CAGb2v64euL+QNXiJdTn0JygYLXg0WoguPSprKT4sKGZGVZbwug@mail.gmail.com>
On Sat Mar 28, 2026 at 10:41 PM CST, Chen-Yu Tsai wrote:
> On Wed, Jan 21, 2026 at 7:04 PM Junhui Liu <junhui.liu@pigmoral.tech> wrote:
>>
>> Add support for the internal CCU found in the RTC module of the Allwinner
>> A733 SoC. While the basic 16MHz (IOSC) and 32kHz logic remains compatible
>> with older SoCs like the sun6i, the A733 introduces several new features.
>>
>> The A733 RTC CCU supports choosing one of three external crystal
>> frequencies: 19.2MHz, 24MHz, and 26MHz. It features hardware detection
>> logic to automatically identify the frequency used on the board and
>> exports this DCXO signal as the "hosc" clock.
>>
>> Furthermore, the driver implements logic to derive a 32kHz reference
>> from the HOSC. This is achieved through a muxed clock path using fixed
>> pre-dividers to normalize the different crystal frequencies to ~32kHz.
>
> Have you tested whether the actually normalizes the frequency, i.e.
> selects a different divider based on the DCXO frequency? Otherwise
> we're just lying about the frequency.
I only have A733 boards with 26MHz crystals, so I couldn't test all
crystal configurations. However, I exported the "hosc_32k" clock
(referred to as dcxo24M_div32k_clk in the vendor driver) to a physical
pin via the fanout path and measured it with the oscilloscope.
Observations:
- Normal conditions: The frequency remains stable within the 32.744 kHz
to 32.791 kHz range.
- Forced condition: I grounded the R24 resistor on radxa A7A board to
trick the SoC into detecting a 24MHz crystal while the actual input
remained 26MHz. In this case, the frequency became unstable but still
stayed around the 32.2 kHz to 33.3 kHz range.
Based on these results, it appears the hardware does attempt to
normalize the frequency towards 32.768 kHz via some internal logic.
>
>> This path reuses the same hardware mux registers as the HOSC clock.
>>
>> Additionally, this CCU provides several gate clocks for specific
>> peripherals, including SerDes, HDMI, and UFS. The driver is implemented
>> as an auxiliary driver to be bound to the sun6i-rtc driver.
>>
>> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
>> ---
>> drivers/clk/sunxi-ng/Kconfig | 5 +
>> drivers/clk/sunxi-ng/Makefile | 2 +
>> drivers/clk/sunxi-ng/ccu-sun60i-a733-rtc.c | 204 +++++++++++++++++++++++++++++
>> drivers/clk/sunxi-ng/ccu-sun60i-a733-rtc.h | 18 +++
>> drivers/clk/sunxi-ng/ccu_rtc.h | 7 +
>> 5 files changed, 236 insertions(+)
>>
[...]
>> +
>> +static const struct clk_parent_data hosc_parents[] = {
>> + { .fw_name = "osc24M" },
>> + { .fw_name = "osc19M" },
>> + { .fw_name = "osc26M" },
>> + { .fw_name = "osc24M" },
>> +};
>
> As mentioned in my reply to the binding, this is wrong. There is only
> one input.
>
> The most you can do is check the rate of the parent clock against the
> detected one, and _scream_ that the DT is wrong. And maybe override
> the reported frequency.
I will add a warning message if the frequency detected by the driver
does not match the one in the DT.
>
> If you want to do the latter, you could add a new fixed rate gated
> clock type to our library. You would fill in the rate before the
> clocks get registered. I probably wouldn't go that far. We want people
> to have correct hardware descriptions.
>
> Funnily enough Allwinner's BSP actually implements a fixed rate gate
> for the next 24M-to-32k divider clock.
Yes, I noticed that as well. I agree, and I will model this path as a
simple fixed-rate clock (32768Hz) in v2.
>
>> +
>> +struct ccu_mux hosc_clk = {
>> + .enable = DCXO_CTRL_DCXO_EN,
>> + .mux = _SUNXI_CCU_MUX(14, 2),
>> + .common = {
>> + .reg = DCXO_CTRL_REG,
>> + .hw.init = CLK_HW_INIT_PARENTS_DATA("hosc",
>> + hosc_parents,
>> + &ccu_mux_ro_ops,
>> + 0),
>> + },
>> +};
>
> So this is wrong.
>
>> +
>> +static const struct ccu_mux_fixed_prediv hosc_32k_predivs[] = {
>> + { .index = 0, .div = 732 },
>
> Why is it 732 instead of 750?
As mentioned above, the target frequency is 32.768kHz rather than
32.0kHz. However, since I will drop this prediv array and use a
fixed-rate clock instead, I think this will no longer be an issue.
--
Best regards,
Junhui Liu
^ permalink raw reply
* RE: [PATCH v2 3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: Yu-Chun Lin [林祐君] @ 2026-04-10 9:39 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰], linusw@kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
afaerber@suse.com, TY_Chang[張子逸]
In-Reply-To: <CAMRc=MfUh_OuxS4SC6QzSOg_PMNc9i9crGYgBASrbVUgHDHSCw@mail.gmail.com>
Hi Bart,
> On Wed, 8 Apr 2026 04:52:42 +0200, Yu-Chun Lin <eleanor.lin@realtek.com>
> said:
> > From: Tzuyi Chang <tychang@realtek.com>
> >
> > Add support for the GPIO controller found on Realtek DHC RTD1625 SoCs.
> >
> > Unlike the existing Realtek GPIO driver (drivers/gpio/gpio-rtd.c),
> > which manages pins via shared bank registers, the RTD1625 introduces a
> > per-pin register architecture. Each GPIO line now has its own
> > dedicated 32-bit control register to manage configuration
> > independently, including direction, output value, input value,
> > interrupt enable, and debounce. Therefore, this distinct hardware
> > design requires a separate driver.
> >
> > Reviewed-by: Linus Walleij <linusw@kernel.org>
> > Signed-off-by: Tzuyi Chang <tychang@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > Changes in v2:
> > - Remove "default y".
> > - Add base_offset member to struct rtd1625_gpio_info to handle merged
> regions.
> > ---
> > drivers/gpio/Kconfig | 11 +
> > drivers/gpio/Makefile | 1 +
> > drivers/gpio/gpio-rtd1625.c | 584
> > ++++++++++++++++++++++++++++++++++++
> > 3 files changed, 596 insertions(+)
> > create mode 100644 drivers/gpio/gpio-rtd1625.c
> >
> > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index
> > 5ee11a889867..281549ad72ac 100644
> > --- a/drivers/gpio/Kconfig
> > +++ b/drivers/gpio/Kconfig
> > @@ -638,6 +638,17 @@ config GPIO_RTD
> > Say yes here to support GPIO functionality and GPIO interrupt on
> > Realtek DHC SoCs.
> >
> > +config GPIO_RTD1625
> > + tristate "Realtek DHC RTD1625 GPIO support"
> > + depends on ARCH_REALTEK || COMPILE_TEST
> > + select GPIOLIB_IRQCHIP
> > + help
> > + This option enables support for the GPIO controller on Realtek
> > + DHC (Digital Home Center) RTD1625 SoC.
> > +
> > + Say yes here to support both basic GPIO line functionality
> > + and GPIO interrupt handling capabilities for this platform.
> > +
> > config GPIO_SAMA5D2_PIOBU
> > tristate "SAMA5D2 PIOBU GPIO support"
> > depends on MFD_SYSCON
> > diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index
> > c05f7d795c43..c95ba218d53a 100644
> > --- a/drivers/gpio/Makefile
> > +++ b/drivers/gpio/Makefile
> > @@ -159,6 +159,7 @@ obj-$(CONFIG_GPIO_REALTEK_OTTO)
> += gpio-realtek-otto.o
> > obj-$(CONFIG_GPIO_REG) += gpio-reg.o
> > obj-$(CONFIG_GPIO_ROCKCHIP) += gpio-rockchip.o
> > obj-$(CONFIG_GPIO_RTD) += gpio-rtd.o
> > +obj-$(CONFIG_GPIO_RTD1625) += gpio-rtd1625.o
> > obj-$(CONFIG_ARCH_SA1100) += gpio-sa1100.o
> > obj-$(CONFIG_GPIO_SAMA5D2_PIOBU) += gpio-sama5d2-piobu.o
> > obj-$(CONFIG_GPIO_SCH311X) += gpio-sch311x.o
> > diff --git a/drivers/gpio/gpio-rtd1625.c b/drivers/gpio/gpio-rtd1625.c
> > new file mode 100644 index 000000000000..bcc1bbb115fa
> > --- /dev/null
> > +++ b/drivers/gpio/gpio-rtd1625.c
> > @@ -0,0 +1,584 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Realtek DHC RTD1625 gpio driver
> > + *
> > + * Copyright (c) 2023 Realtek Semiconductor Corp.
>
> No modifications since 2023?
>
Will include 2026.
> > + */
> > +
> > +#include <linux/bitfield.h>
> > +#include <linux/bitops.h>
> > +#include <linux/gpio/driver.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/irqchip.h>
> > +#include <linux/irqchip/chained_irq.h> #include <linux/irqdomain.h>
> > +#include <linux/module.h> #include <linux/platform_device.h> #include
> > +<linux/property.h> #include <linux/spinlock.h> #include
> > +<linux/types.h>
> > +
> > +#define RTD1625_GPIO_DIR BIT(0)
> > +#define RTD1625_GPIO_OUT BIT(2)
> > +#define RTD1625_GPIO_IN BIT(4)
> > +#define RTD1625_GPIO_EDGE_INT_DP BIT(6) #define
> > +RTD1625_GPIO_EDGE_INT_EN BIT(8) #define
> RTD1625_GPIO_LEVEL_INT_EN
> > +BIT(16) #define RTD1625_GPIO_LEVEL_INT_DP BIT(18) #define
> > +RTD1625_GPIO_DEBOUNCE GENMASK(30, 28) #define
> > +RTD1625_GPIO_DEBOUNCE_WREN BIT(31)
> > +
> > +#define RTD1625_GPIO_WREN(x) ((x) << 1)
> > +
> > +/* Write-enable masks for all GPIO configs and reserved hardware bits
> > +*/ #define RTD1625_ISO_GPIO_WREN_ALL 0x8000aa8a #define
> > +RTD1625_ISOM_GPIO_WREN_ALL 0x800aaa8a
> > +
> > +#define RTD1625_GPIO_DEBOUNCE_1US 0
> > +#define RTD1625_GPIO_DEBOUNCE_10US 1
> > +#define RTD1625_GPIO_DEBOUNCE_100US 2 #define
> > +RTD1625_GPIO_DEBOUNCE_1MS 3 #define
> RTD1625_GPIO_DEBOUNCE_10MS 4
> > +#define RTD1625_GPIO_DEBOUNCE_20MS 5 #define
> > +RTD1625_GPIO_DEBOUNCE_30MS 6 #define
> RTD1625_GPIO_DEBOUNCE_50MS 7
> > +
> > +#define GPIO_CONTROL(gpio) ((gpio) * 4)
> > +
> > +/**
> > + * struct rtd1625_gpio_info - Specific GPIO register information
> > + * @num_gpios: The number of GPIOs
> > + * @irq_type_support: Supported IRQ types
> > + * @gpa_offset: Offset for GPIO assert interrupt status registers
> > + * @gpda_offset: Offset for GPIO deassert interrupt status registers
> > + * @level_offset: Offset of level interrupt status register
> > + * @write_en_all: Write-enable mask for all configurable bits */
> > +struct rtd1625_gpio_info {
> > + unsigned int num_gpios;
> > + unsigned int irq_type_support;
> > + unsigned int base_offset;
> > + unsigned int gpa_offset;
> > + unsigned int gpda_offset;
> > + unsigned int level_offset;
> > + unsigned int write_en_all;
> > +};
>
> Please remove the tabs in the above struct.
>
Ack.
> > +
> > +struct rtd1625_gpio {
> > + struct gpio_chip gpio_chip;
> > + const struct rtd1625_gpio_info *info;
> > + void __iomem *base;
> > + void __iomem *irq_base;
> > + unsigned int irqs[3];
> > + raw_spinlock_t lock;
> > + unsigned int *save_regs;
> > +};
>
> I'd also personally remove these tabs here but won't die on that hill.
>
Ack.
> > +
> > +static unsigned int rtd1625_gpio_gpa_offset(struct rtd1625_gpio
> > +*data, unsigned int offset) {
> > + return data->info->gpa_offset + ((offset / 32) * 4); }
> > +
> > +static unsigned int rtd1625_gpio_gpda_offset(struct rtd1625_gpio
> > +*data, unsigned int offset) {
> > + return data->info->gpda_offset + ((offset / 32) * 4); }
> > +
> > +static unsigned int rtd1625_gpio_level_offset(struct rtd1625_gpio
> > +*data, unsigned int offset) {
> > + return data->info->level_offset + ((offset / 32) * 4); }
>
> Looking at these, I'm under the impression that this driver could quite easily be
> converted to using gpio-mmio or even gpio-regmap with an MMIO regmap,
> have you looked into it by any chance?
>
> Bart
We did look into gpio-mmio and gpio-regmap, but they are not quite suitable for
our platform due to the specific hardware design:
1. Per-GPIO Dedicated Registers: Unlike typical GPIO controllers that pack 32 pins
into a single 32-bit register (1 bit per pin), our hardware uses a dedicated 32-bit
register for each individual GPIO. This single register controls the
input/output state, direction, and interrupt trigger type for that specific pin.
2. Write-Enable (WREN) Mask Mechanism: Our hardware requires a specific Write-Enable
mask to be written simultaneously when updating the register values.
3. Hardware Debounce: We also need to support hardware debounce settings per pin,
which requires custom configuration via set_config mapped to these specific per-pin
registers.
Because of these hardware constraints, manually implementing the gpio_chip callbacks
seems to be the most straightforward
Best Regards,
Yu-Chun
^ permalink raw reply
* [PATCH 0/2] CPPC: reduce FFH feedback-counter sampling skew on arm64
From: Pengjie Zhang @ 2026-04-10 9:41 UTC (permalink / raw)
To: catalin.marinas, will, rafael, lenb, robert.moore,
beata.michalska, zhenglifeng1, zhanjie9, sumitg, cuiyunhui
Cc: linux-arm-kernel, linux-kernel, linux-acpi, acpica-devel,
linuxarm, jonathan.cameron, prime.zeng, wanghuiqiang, xuwei5,
lihuisong, yubowen8, zhangpengjie2, wangzhi12
The legacy CPPC feedback-counter path reads the delivered and reference
performance counters separately.
On arm64 systems using AMU-backed CPPC FFH counters, each FFH read is
served through a cross-CPU counter read helper. Reading the counters
separately therefore widens the sampling window between them and can
skew the delivered/reference ratio used by cpuinfo_cur_freq. Under heavy
load, the skew is observable as transient values that may exceed the
platform maximum, as discussed in [1] and [2].
This series adds a small generic hook for architectures that can obtain
both FFH feedback counters in one operation, while preserving the
existing per-register read path as the fallback.
Patch 1 adds the generic CPPC hook and uses it from cppc_get_perf_ctrs().
Patch 2 implements the hook on arm64 by sampling both AMU counters in a
single operation on the target CPU.
[1] https://lore.kernel.org/all/20231025093847.3740104-4-zengheng4@huawei.com/
[2] https://lore.kernel.org/all/20231212072617.14756-1-lihuisong@huawei.com/
Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
Pengjie Zhang (2):
ACPI: CPPC: add paired FFH feedback-counter read hook
arm64: topology: read CPPC FFH feedback counters in one operation
arch/arm64/kernel/topology.c | 75 ++++++++++++++++++++++++++++++++----
drivers/acpi/cppc_acpi.c | 58 +++++++++++++++++++++++++---
include/acpi/cppc_acpi.h | 7 ++++
3 files changed, 127 insertions(+), 13 deletions(-)
--
2.33.0
^ permalink raw reply
* [PATCH 1/2] ACPI: CPPC: add paired FFH feedback-counter read hook
From: Pengjie Zhang @ 2026-04-10 9:41 UTC (permalink / raw)
To: catalin.marinas, will, rafael, lenb, robert.moore,
beata.michalska, zhenglifeng1, zhanjie9, sumitg, cuiyunhui
Cc: linux-arm-kernel, linux-kernel, linux-acpi, acpica-devel,
linuxarm, jonathan.cameron, prime.zeng, wanghuiqiang, xuwei5,
lihuisong, yubowen8, zhangpengjie2, wangzhi12
In-Reply-To: <20260410094145.4132082-1-zhangpengjie2@huawei.com>
cppc_get_perf_ctrs() reads the delivered and reference performance
counters one at a time.
Allow architectures to provide both FFH feedback counters in one
operation when that either narrows the sampling window or avoids extra
cross-CPU reads. Add a small FFH-specific hook for that case and fall
back to the existing per-register reads when unsupported.
Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
---
drivers/acpi/cppc_acpi.c | 58 ++++++++++++++++++++++++++++++++++++----
include/acpi/cppc_acpi.h | 7 +++++
2 files changed, 60 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index 2e91c5a97761..7b3e8b0597dc 100644
--- a/drivers/acpi/cppc_acpi.c
+++ b/drivers/acpi/cppc_acpi.c
@@ -988,6 +988,23 @@ int __weak cpc_read_ffh(int cpunum, struct cpc_reg *reg, u64 *val)
return -ENOTSUPP;
}
+/**
+ * cpc_read_ffh_fb_ctrs() - Read FFH feedback counters together
+ * @cpunum: CPU number to read
+ * @reg1: first CPPC register information
+ * @val1: place holder for first return value
+ * @reg2: second CPPC register information
+ * @val2: place holder for second return value
+ *
+ * Return: 0 for success and error code
+ */
+int __weak cpc_read_ffh_fb_ctrs(int cpunum, struct cpc_reg *reg1,
+ u64 *val1, struct cpc_reg *reg2, u64 *val2)
+{
+ return -EOPNOTSUPP;
+}
+
+
/**
* cpc_write_ffh() - Write FFH register
* @cpunum: CPU number to write
@@ -1504,6 +1521,40 @@ bool cppc_perf_ctrs_in_pcc(void)
}
EXPORT_SYMBOL_GPL(cppc_perf_ctrs_in_pcc);
+static int cppc_read_perf_fb_ctrs(int cpunum,
+ struct cpc_register_resource *delivered_reg,
+ struct cpc_register_resource *reference_reg,
+ u64 *delivered, u64 *reference)
+{
+ int ret;
+
+ /*
+ * For FFH feedback counters, try a paired read first to reduce
+ * sampling skew between delivered and reference counters. Fall
+ * back to the existing per-register reads if unsupported.
+ */
+ if (CPC_IN_FFH(delivered_reg) && CPC_IN_FFH(reference_reg)) {
+ ret = cpc_read_ffh_fb_ctrs(cpunum,
+ &delivered_reg->cpc_entry.reg, delivered,
+ &reference_reg->cpc_entry.reg, reference);
+ if (!ret)
+ return 0;
+
+ if (ret != -EOPNOTSUPP)
+ return ret;
+ }
+
+ ret = cpc_read(cpunum, delivered_reg, delivered);
+ if (ret)
+ return ret;
+
+ ret = cpc_read(cpunum, reference_reg, reference);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
/**
* cppc_get_perf_ctrs - Read a CPU's performance feedback counters.
* @cpunum: CPU from which to read counters.
@@ -1547,11 +1598,8 @@ int cppc_get_perf_ctrs(int cpunum, struct cppc_perf_fb_ctrs *perf_fb_ctrs)
}
}
- ret = cpc_read(cpunum, delivered_reg, &delivered);
- if (ret)
- goto out_err;
-
- ret = cpc_read(cpunum, reference_reg, &reference);
+ ret = cppc_read_perf_fb_ctrs(cpunum, delivered_reg, reference_reg,
+ &delivered, &reference);
if (ret)
goto out_err;
diff --git a/include/acpi/cppc_acpi.h b/include/acpi/cppc_acpi.h
index d1f02ceec4f9..006b42dbbd4b 100644
--- a/include/acpi/cppc_acpi.h
+++ b/include/acpi/cppc_acpi.h
@@ -172,6 +172,8 @@ extern int cppc_get_transition_latency(int cpu);
extern bool cpc_ffh_supported(void);
extern bool cpc_supported_by_cpu(void);
extern int cpc_read_ffh(int cpunum, struct cpc_reg *reg, u64 *val);
+extern int cpc_read_ffh_fb_ctrs(int cpu, struct cpc_reg *reg1, u64 *val1,
+ struct cpc_reg *reg2, u64 *val2);
extern int cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val);
extern int cppc_get_epp_perf(int cpunum, u64 *epp_perf);
extern int cppc_set_epp_perf(int cpu, struct cppc_perf_ctrls *perf_ctrls, bool enable);
@@ -246,6 +248,11 @@ static inline int cpc_read_ffh(int cpunum, struct cpc_reg *reg, u64 *val)
{
return -EOPNOTSUPP;
}
+static inline int cpc_read_ffh_fb_ctrs(int cpu, struct cpc_reg *reg1, u64 *val1,
+ struct cpc_reg *reg2, u64 *val2)
+{
+ return -EOPNOTSUPP;
+}
static inline int cpc_write_ffh(int cpunum, struct cpc_reg *reg, u64 val)
{
return -EOPNOTSUPP;
--
2.33.0
^ permalink raw reply related
* [PATCH 2/2] arm64: topology: read CPPC FFH feedback counters in one operation
From: Pengjie Zhang @ 2026-04-10 9:41 UTC (permalink / raw)
To: catalin.marinas, will, rafael, lenb, robert.moore,
beata.michalska, zhenglifeng1, zhanjie9, sumitg, cuiyunhui
Cc: linux-arm-kernel, linux-kernel, linux-acpi, acpica-devel,
linuxarm, jonathan.cameron, prime.zeng, wanghuiqiang, xuwei5,
lihuisong, yubowen8, zhangpengjie2, wangzhi12
In-Reply-To: <20260410094145.4132082-1-zhangpengjie2@huawei.com>
arm64 implements CPPC FFH feedback-counter reads using AMU counters.
Because those counters must be sampled on the target CPU, reading the
delivered and reference counters separately widens the observation window
between them.
Implement the paired FFH feedback-counter read hook on arm64 and sample
both AMU counters together before decoding the requested CPC register
values.
Also factor the FFH bitfield extraction logic into a helper and reuse
it from the existing single-counter FFH read path.
Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
---
arch/arm64/kernel/topology.c | 75 ++++++++++++++++++++++++++++++++----
1 file changed, 67 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index b32f13358fbb..b90a767b2a1f 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -50,6 +50,16 @@ struct amu_cntr_sample {
unsigned long last_scale_update;
};
+struct amu_ffh_ctrs {
+ u64 corecnt;
+ u64 constcnt;
+};
+
+enum cpc_ffh_ctr_id {
+ CPC_FFH_CTR_CORE = 0x0,
+ CPC_FFH_CTR_CONST = 0x1,
+};
+
static DEFINE_PER_CPU_SHARED_ALIGNED(struct amu_cntr_sample, cpu_amu_samples);
void update_freq_counters_refs(void)
@@ -397,7 +407,7 @@ static void cpu_read_constcnt(void *val)
}
static inline
-int counters_read_on_cpu(int cpu, smp_call_func_t func, u64 *val)
+int counters_read_on_cpu(int cpu, smp_call_func_t func, void *val)
{
/*
* Abort call on counterless CPU.
@@ -447,24 +457,73 @@ bool cpc_ffh_supported(void)
return true;
}
+static void amu_read_core_const_ctrs(void *val)
+{
+ struct amu_ffh_ctrs *ctrs = val;
+
+ cpu_read_constcnt(&ctrs->constcnt);
+ cpu_read_corecnt(&ctrs->corecnt);
+}
+
+static u64 cpc_ffh_extract_bits(const struct cpc_reg *reg, u64 val)
+{
+ val &= GENMASK_ULL(reg->bit_offset + reg->bit_width - 1,
+ reg->bit_offset);
+ val >>= reg->bit_offset;
+
+ return val;
+}
+
+static bool cpc_ffh_ctr_value(const struct cpc_reg *reg,
+ const struct amu_ffh_ctrs *ctrs, u64 *val)
+{
+ switch ((u64)reg->address) {
+ case CPC_FFH_CTR_CORE:
+ *val = ctrs->corecnt;
+ break;
+ case CPC_FFH_CTR_CONST:
+ *val = ctrs->constcnt;
+ break;
+ default:
+ return false;
+ }
+
+ *val = cpc_ffh_extract_bits(reg, *val);
+ return true;
+}
+
+int cpc_read_ffh_fb_ctrs(int cpu, struct cpc_reg *reg1, u64 *val1,
+ struct cpc_reg *reg2, u64 *val2)
+{
+ struct amu_ffh_ctrs ctrs;
+ int ret;
+
+ ret = counters_read_on_cpu(cpu, amu_read_core_const_ctrs, &ctrs);
+ if (ret)
+ return ret;
+
+ if (!cpc_ffh_ctr_value(reg1, &ctrs, val1) ||
+ !cpc_ffh_ctr_value(reg2, &ctrs, val2))
+ return -EOPNOTSUPP;
+
+ return 0;
+}
+
int cpc_read_ffh(int cpu, struct cpc_reg *reg, u64 *val)
{
int ret = -EOPNOTSUPP;
switch ((u64)reg->address) {
- case 0x0:
+ case CPC_FFH_CTR_CORE:
ret = counters_read_on_cpu(cpu, cpu_read_corecnt, val);
break;
- case 0x1:
+ case CPC_FFH_CTR_CONST:
ret = counters_read_on_cpu(cpu, cpu_read_constcnt, val);
break;
}
- if (!ret) {
- *val &= GENMASK_ULL(reg->bit_offset + reg->bit_width - 1,
- reg->bit_offset);
- *val >>= reg->bit_offset;
- }
+ if (!ret)
+ *val = cpc_ffh_extract_bits(reg, *val);
return ret;
}
--
2.33.0
^ permalink raw reply related
* Re: [PATCH v3 2/7] arm64/runtime-const: Use aarch64_insn_patch_text_nosync() for patching
From: Catalin Marinas @ 2026-04-10 9:37 UTC (permalink / raw)
To: K Prateek Nayak
Cc: Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
Sebastian Andrzej Siewior, Will Deacon, David Laight, Darren Hart,
Davidlohr Bueso, André Almeida, linux-arch, linux-kernel,
linux-s390, linux-riscv, linux-arm-kernel, Jisheng Zhang
In-Reply-To: <20260402112250.2138-3-kprateek.nayak@amd.com>
On Thu, Apr 02, 2026 at 11:22:45AM +0000, K Prateek Nayak wrote:
> diff --git a/arch/arm64/include/asm/runtime-const.h b/arch/arm64/include/asm/runtime-const.h
> index c3dbd3ae68f6..a3106f80912b 100644
> --- a/arch/arm64/include/asm/runtime-const.h
> +++ b/arch/arm64/include/asm/runtime-const.h
> @@ -7,6 +7,7 @@
> #endif
>
> #include <asm/cacheflush.h>
> +#include <asm/text-patching.h>
>
> /* Sigh. You can still run arm64 in BE mode */
> #include <asm/byteorder.h>
> @@ -50,13 +51,7 @@ static inline void __runtime_fixup_16(__le32 *p, unsigned int val)
> u32 insn = le32_to_cpu(*p);
> insn &= 0xffe0001f;
> insn |= (val & 0xffff) << 5;
> - *p = cpu_to_le32(insn);
> -}
> -
> -static inline void __runtime_fixup_caches(void *where, unsigned int insns)
> -{
> - unsigned long va = (unsigned long)where;
> - caches_clean_inval_pou(va, va + 4*insns);
> + aarch64_insn_patch_text_nosync(p, insn);
> }
Sashiko has some good points here:
https://sashiko.dev/#/patchset/20260402112250.2138-1-kprateek.nayak@amd.com
In short, aarch64_insn_patch_text_nosync() does not expect a linear map
address but rather a kernel text one (or vmalloc/modules). The other
valid point is on aliasing I-caches.
I think dropping the lm_alias() and just use 'where' directly would do
but I haven't tried.
--
Catalin
^ permalink raw reply
* [PATCH v2 4/6] selftests/resctrl: Refactor perf event open/close using linked list
From: Yifan Wu @ 2026-04-10 9:33 UTC (permalink / raw)
To: tony.luck, reinette.chatre, Dave.Martin, james.morse, babu.moger,
shuah, tan.shaopeng, fenghuay, ben.horgan, jonathan.cameron,
zengheng4, wuyifan50, linux-kernel, linux-arm-kernel,
linux-kselftest, linuxarm
Cc: xiaqinxin, prime.zeng, wangyushan12, xuwei5, fanghao11, wangzhou1
In-Reply-To: <20260410093352.3988125-1-wuyifan50@huawei.com>
Using linked list when open/close perf event.
Signed-off-by: Yifan Wu <wuyifan50@huawei.com>
---
tools/testing/selftests/resctrl/resctrl_val.c | 29 ++++++++++---------
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/tools/testing/selftests/resctrl/resctrl_val.c b/tools/testing/selftests/resctrl/resctrl_val.c
index ce675d349a6e..ce5f96d5457c 100644
--- a/tools/testing/selftests/resctrl/resctrl_val.c
+++ b/tools/testing/selftests/resctrl/resctrl_val.c
@@ -93,15 +93,15 @@ static void get_read_event_and_umask(char *cas_count_cfg, struct imc_counter_con
}
}
-static int open_perf_read_event(int i, int cpu_no)
+static int open_perf_read_event(int cpu_no, struct imc_counter_config *imc_counter)
{
- imc_counters_config[i].fd =
- perf_event_open(&imc_counters_config[i].pe, -1, cpu_no, -1,
+ imc_counter->fd =
+ perf_event_open(&imc_counter->pe, -1, cpu_no, -1,
PERF_FLAG_FD_CLOEXEC);
- if (imc_counters_config[i].fd == -1) {
+ if (imc_counter->fd == -1) {
fprintf(stderr, "Error opening leader %llx\n",
- imc_counters_config[i].pe.config);
+ imc_counter->pe.config);
return -1;
}
@@ -318,11 +318,11 @@ void cleanup_read_mem_bw_imc(void)
static void perf_close_imc_read_mem_bw(void)
{
- int mc;
+ struct imc_counter_config *imc_counter;
- for (mc = 0; mc < imcs; mc++) {
- if (imc_counters_config[mc].fd != -1)
- close(imc_counters_config[mc].fd);
+ list_for_each_entry(imc_counter, &imc_counters_list, entry) {
+ if (imc_counter->fd != -1)
+ close(imc_counter->fd);
}
}
@@ -334,13 +334,14 @@ static void perf_close_imc_read_mem_bw(void)
*/
static int perf_open_imc_read_mem_bw(int cpu_no)
{
- int imc, ret;
+ struct imc_counter_config *imc_counter;
+ int ret;
- for (imc = 0; imc < imcs; imc++)
- imc_counters_config[imc].fd = -1;
+ list_for_each_entry(imc_counter, &imc_counters_list, entry)
+ imc_counter->fd = -1;
- for (imc = 0; imc < imcs; imc++) {
- ret = open_perf_read_event(imc, cpu_no);
+ list_for_each_entry(imc_counter, &imc_counters_list, entry) {
+ ret = open_perf_read_event(cpu_no, imc_counter);
if (ret)
goto close_fds;
}
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox