* Re: [PATCH] cpufreq: CPPC: add autonomous mode boot parameter support
From: Pierre Gondois @ 2026-04-10 13:47 UTC (permalink / raw)
To: Sumit Gupta
Cc: linux-tegra, linux-kernel, linux-doc, zhenglifeng1, treding,
viresh.kumar, jonathanh, vsethi, ionela.voinescu, ksitaraman,
sanjayc, zhanjie9, corbet, mochs, skhan, bbasu, rdunlap, linux-pm,
mario.limonciello, rafael
In-Reply-To: <b8debb30-67a5-4d2b-8c08-8fd287f7258e@nvidia.com>
Hello Sumit,
On 4/6/26 20:08, Sumit Gupta wrote:
> Hi Pierre,
>
> Thank you for the comments.
> Sorry for late reply as I was on vacation.
>
No worries
>
> On 24/03/26 23:48, Pierre Gondois wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> Hello Sumit,
>>
>> On 3/17/26 16:10, Sumit Gupta wrote:
>>> Add kernel boot parameter 'cppc_cpufreq.auto_sel_mode' to enable CPPC
>>> autonomous performance selection on all CPUs at system startup without
>>> requiring runtime sysfs manipulation. When autonomous mode is enabled,
>>> the hardware automatically adjusts CPU performance based on workload
>>> demands using Energy Performance Preference (EPP) hints.
>>>
>>> When auto_sel_mode=1:
>>> - Configure all CPUs for autonomous operation on first init
>>> - Set EPP to performance preference (0x0)
>>> - Use HW min/max when set; otherwise program from policy limits (caps)
>>> - Clamp desired_perf to bounds before enabling autonomous mode
>>> - Hardware controls frequency instead of the OS governor
>>>
>>> The boot parameter is applied only during first policy initialization.
>>> On hotplug, skip applying it so that the user's runtime sysfs
>>> configuration is preserved.
>>>
>>> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> (Documentation)
>>> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
>>> ---
>>> Part 1 [1] of this series was applied for 7.1 and present in next.
>>> Sending this patch as reworked version of 'patch 11' from [2] based
>>> on next.
>>>
>>> [1]
>>> https://lore.kernel.org/lkml/20260206142658.72583-1-sumitg@nvidia.com/
>>> [2]
>>> https://lore.kernel.org/lkml/20251223121307.711773-1-sumitg@nvidia.com/
>>> ---
>>> .../admin-guide/kernel-parameters.txt | 13 +++
>>> drivers/cpufreq/cppc_cpufreq.c | 84
>>> +++++++++++++++++--
>>> 2 files changed, 92 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
>>> b/Documentation/admin-guide/kernel-parameters.txt
>>> index fa6171b5fdd5..de4b4c89edfe 100644
>>> --- a/Documentation/admin-guide/kernel-parameters.txt
>>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>>> @@ -1060,6 +1060,19 @@ Kernel parameters
>>> policy to use. This governor must be
>>> registered in the
>>> kernel before the cpufreq driver probes.
>>>
>>> + cppc_cpufreq.auto_sel_mode=
>>> + [CPU_FREQ] Enable ACPI CPPC autonomous
>>> performance
>>> + selection. When enabled, hardware
>>> automatically adjusts
>>> + CPU frequency on all CPUs based on workload
>>> demands.
>>> + In Autonomous mode, Energy Performance
>>> Preference (EPP)
>>> + hints guide hardware toward performance (0x0)
>>> or energy
>>> + efficiency (0xff).
>>> + Requires ACPI CPPC autonomous selection
>>> register support.
>>> + Format: <bool>
>>> + Default: 0 (disabled)
>>> + 0: use cpufreq governors
>>> + 1: enable if supported by hardware
>>> +
>>> cpu_init_udelay=N
>>> [X86,EARLY] Delay for N microsec between
>>> assert and de-assert
>>> of APIC INIT to start processors. This delay
>>> occurs
>>> diff --git a/drivers/cpufreq/cppc_cpufreq.c
>>> b/drivers/cpufreq/cppc_cpufreq.c
>>> index 5dfb109cf1f4..49c148b2a0a4 100644
>>> --- a/drivers/cpufreq/cppc_cpufreq.c
>>> +++ b/drivers/cpufreq/cppc_cpufreq.c
>>> @@ -28,6 +28,9 @@
>>>
>>> static struct cpufreq_driver cppc_cpufreq_driver;
>>>
>>> +/* Autonomous Selection boot parameter */
>>> +static bool auto_sel_mode;
>>> +
>>> #ifdef CONFIG_ACPI_CPPC_CPUFREQ_FIE
>>> static enum {
>>> FIE_UNSET = -1,
>>> @@ -708,11 +711,74 @@ static int cppc_cpufreq_cpu_init(struct
>>> cpufreq_policy *policy)
>>> policy->cur = cppc_perf_to_khz(caps, caps->highest_perf);
>>> cpu_data->perf_ctrls.desired_perf = caps->highest_perf;
>>>
>>> - ret = cppc_set_perf(cpu, &cpu_data->perf_ctrls);
>>> - if (ret) {
>>> - pr_debug("Err setting perf value:%d on CPU:%d. ret:%d\n",
>>> - caps->highest_perf, cpu, ret);
>>> - goto out;
>>> + /*
>>> + * Enable autonomous mode on first init if boot param is set.
>>> + * Check last_governor to detect first init and skip if auto_sel
>>> + * is already enabled.
>>> + */
>> If the goal is to set autosel only once at the driver init,
>> shouldn't this be done in cppc_cpufreq_init() ?
>> I understand that cpu_data doesn't exist yet in
>> cppc_cpufreq_init(), but this seems more appropriate to do
>> it there IMO.
>>
>> This means the cpudata should be updated accordingly
>> in this cppc_cpufreq_cpu_init() function.
>
> In an earlier version [1], the setup was in cppc_cpufreq_init() but
> was moved to cppc_cpufreq_cpu_init() to improve per-CPU error handling.
> Keeping the setup in cppc_cpufreq_init() helps to avoid the last_governor
> check. We can warn for a CPU failing to enable and continue so other
> CPUs keep autonomous mode.
> cppc_cpufreq_cpu_init() would then just check the auto_sel state
> from register and sync policy limits from min/max_perf registers when
> autonomous mode is active.
> Please let me know your thoughts.
FWIU the auto_sel_mode module parameter allows to
configure the default auto_sel_mode when the driver is
first loaded, so there should not need to check that again
whenever cppc_cpufreq_cpu_init() is called.
Maybe Ionela saw something we didn't see ?
Also just to be sure, should it still be possible to change
the auto_sel_mode through the sysfs if the driver was
loaded with auto_sel_mode=1 ?
>
> [1]
> https://lore.kernel.org/lkml/5593d364-ca37-41c5-b33f-f7e245d6d626@nvidia.com/
>
>
>>
>>> + if (auto_sel_mode && policy->last_governor[0] == '\0' &&
>>> + !cpu_data->perf_ctrls.auto_sel) {
>>> + /* Enable CPPC - optional register, some platforms
>>> need it */
>> The documentation of the CPPC Enable Register is subject to
>> interpretation, but IIUC the field should be set to use the CPPC
>> controls, so I assume this should be set in cppc_cpufreq_init()
>> instead ?
>
> Agree that the CPPC Enable is about using the CPPC control path
> in general and not only for autonomous selection.
> Will move cppc_set_enable() into cppc_cpufreq_init() or outside the
> autonomous mode block in cppc_cpufreq_cpu_init() as per conclusion
> of previous comment.
>
>>> + ret = cppc_set_enable(cpu, true);
>>> + if (ret && ret != -EOPNOTSUPP)
>>> + pr_warn("Failed to enable CPPC for CPU%d
>>> (%d)\n", cpu, ret);
>>> +
>>> + /*
>>> + * Prefer HW min/max_perf when set; otherwise program
>>> from
>>> + * policy limits derived earlier from caps.
>>> + * Clamp desired_perf to bounds and sync policy->cur.
>>> + */
>>> + if (!cpu_data->perf_ctrls.min_perf ||
>>> !cpu_data->perf_ctrls.max_perf)
>>
>> The function doesn't seem to exist.
>
> It is newly added in [2].
> Don't need to call it if we move the setup to cppc_cpufreq_init().
Ah ok right thanks.
>
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ea3db45ae476889a1ba0ab3617e6afdeeefbda3d
>
>
>
>>
>>> + cppc_cpufreq_update_perf_limits(cpu_data, policy);
>>> +
>>> + cpu_data->perf_ctrls.desired_perf =
>>> + clamp_t(u32, cpu_data->perf_ctrls.desired_perf,
>>> + cpu_data->perf_ctrls.min_perf,
>>> + cpu_data->perf_ctrls.max_perf);
>>> +
>>> + policy->cur = cppc_perf_to_khz(caps,
>>> + cpu_data->perf_ctrls.desired_perf);
>>> +
>>
>> Maybe this should also be done in cppc_cpufreq_init()
>> if the auto_sel_mode parameter is set ?
>
> Yes.
>
>>
>>> + /* EPP is optional - some platforms may not support it */
>>> + ret = cppc_set_epp(cpu, CPPC_EPP_PERFORMANCE_PREF);
>>> + if (ret && ret != -EOPNOTSUPP)
>>> + pr_warn("Failed to set EPP for CPU%d (%d)\n",
>>> cpu, ret);
>>> + else if (!ret)
>>> + cpu_data->perf_ctrls.energy_perf =
>>> CPPC_EPP_PERFORMANCE_PREF;
>>> +
>>> + ret = cppc_set_perf(cpu, &cpu_data->perf_ctrls);
>>> + if (ret) {
>>> + pr_debug("Err setting perf for autonomous mode
>>> CPU:%d ret:%d\n",
>>> + cpu, ret);
>>> + goto out;
>>> + }
>>> +
>>> + ret = cppc_set_auto_sel(cpu, true);
>>> + if (ret && ret != -EOPNOTSUPP) {
>>> + pr_warn("Failed autonomous config for CPU%d
>>> (%d)\n",
>>> + cpu, ret);
>>> + goto out;
>>> + }
>>> + if (!ret)
>>> + cpu_data->perf_ctrls.auto_sel = true;
>>> + }
>>> +
>>> + if (cpu_data->perf_ctrls.auto_sel) {
>>
>> There is a patchset ongoing which tries to remove
>> setting policy->min/max from driver initialization.
>> Indeed, these values are only temporarily valid,
>> until the governor override them.
>> It is not sure yet the patch will be accepted though.
>>
>> https://lore.kernel.org/lkml/20260317101753.2284763-4-pierre.gondois@arm.com/
>>
>
>
> You are right that policy->min/max from .init() are temporary today
> as cpufreq_set_policy() overwrites them before the governor starts.
>
> On my test platform (highest == nominal, lowest_nonlinear == lowest),
> this had no visible effect because the BIOS bounds and cpuinfo range
> end up identical. But on platforms where they differ, the governor
> would widen the range to full cpuinfo limits.
>
> I think your patch [3] fixes this by giving these the right semantic as
> initial QoS requests. With it, cpufreq_set_policy() preserves the policy
> limits set from min/max_perf registers in .init(), which can either be
> BIOS values on first boot or last user configured values before hotplug.
>
> I will update the comment in v2 to reflect QoS seeding intent.
>
> I see that the first two patches of your series [3] is applied for 7.1.
> Do you plan to send the pending patch (3/4) from [3]?
>
I need to ping Viresh to check if this is still relevant.
> [3]
> https://lore.kernel.org/lkml/20260317101753.2284763-4-pierre.gondois@arm.com/
>
>
>>
>>
>>> + /* Sync policy limits from HW when autonomous mode is
>>> active */
>>> + policy->min = cppc_perf_to_khz(caps,
>>> + cpu_data->perf_ctrls.min_perf ?:
>>> + caps->lowest_nonlinear_perf);
>>> + policy->max = cppc_perf_to_khz(caps,
>>> + cpu_data->perf_ctrls.max_perf ?:
>>> + caps->nominal_perf);
>>> + } else {
>>> + /* Normal mode: governors control frequency */
>>> + ret = cppc_set_perf(cpu, &cpu_data->perf_ctrls);
>>> + if (ret) {
>>> + pr_debug("Err setting perf value:%d on CPU:%d.
>>> ret:%d\n",
>>> + caps->highest_perf, cpu, ret);
>>> + goto out;
>>> + }
>>> }
>>>
>>> cppc_cpufreq_cpu_fie_init(policy);
>>> @@ -1038,10 +1104,18 @@ static int __init cppc_cpufreq_init(void)
>>>
>>> static void __exit cppc_cpufreq_exit(void)
>>> {
>>> + unsigned int cpu;
>>> +
>>> + for_each_present_cpu(cpu)
>>> + cppc_set_auto_sel(cpu, false);
>>
>> If the firmware has a default EPP value, it means that loading
>> and the unloading the driver will reset this default EPP value.
>> Maybe the initial EPP value and/or the auto_sel value should be
>> cached somewhere and restored on exit ?
>> I don't know if this is actually an issue, this is just to signal it.
>
> The auto_sel_mode boot path programs EPP to performance preference(0),
> not the firmware’s previous value. On unload we only call
> cppc_set_auto_sel(false); we do not restore EPP, min/max perf,
> or other CPPC fields to firmware defaults.
Yes right, so loading/unloading the driver might change the
default EPP value.
>
> Thank you,
> Sumit Gupta
>
> ....
>
>
^ permalink raw reply
* [PATCH] mailbox: prefix new constants with MBOX_
From: Wolfram Sang @ 2026-04-10 12:49 UTC (permalink / raw)
To: linux-renesas-soc, Jassi Brar
Cc: Wolfram Sang, Peter Chen, Fugang Duan,
CIX Linux Kernel Upstream Group, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Matthias Brugger,
AngeloGioacchino Del Regno, Thierry Reding, Jonathan Hunter,
linux-arm-kernel, imx, linux-mediatek, linux-tegra
Commit 89e5d7d61600 ("mailbox: remove superfluous internal header")
moved some constants to a public header but forgot to add a mailbox
specific prefix. Add this now to prevent future collisions on a too
generic naming.
Link: https://sashiko.dev/#/patchset/20260327151112.5202-2-wsa%2Brenesas%40sang-engineering.com
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
This patch improves the above mentioned commit which already sits in
-next. It is not really a fix but it probably is still a good idea to
apply it before rc1 to avoid confusion.
drivers/mailbox/cix-mailbox.c | 2 +-
drivers/mailbox/imx-mailbox.c | 2 +-
drivers/mailbox/mailbox.c | 22 +++++++++++-----------
drivers/mailbox/mtk-cmdq-mailbox.c | 2 +-
drivers/mailbox/omap-mailbox.c | 2 +-
drivers/mailbox/tegra-hsp.c | 2 +-
include/linux/mailbox_controller.h | 6 +++---
7 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/mailbox/cix-mailbox.c b/drivers/mailbox/cix-mailbox.c
index 8cfaa91b75bd..43c76cdab24a 100644
--- a/drivers/mailbox/cix-mailbox.c
+++ b/drivers/mailbox/cix-mailbox.c
@@ -413,7 +413,7 @@ static int cix_mbox_startup(struct mbox_chan *chan)
switch (cp->type) {
case CIX_MBOX_TYPE_DB:
/* Overwrite txdone_method for DB channel */
- chan->txdone_method = TXDONE_BY_ACK;
+ chan->txdone_method = MBOX_TXDONE_BY_ACK;
fallthrough;
case CIX_MBOX_TYPE_REG:
if (priv->dir == CIX_MBOX_TX) {
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 22331b579489..246a9a9e3952 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -732,7 +732,7 @@ static struct mbox_chan * imx_mu_xlate(struct mbox_controller *mbox,
p_chan = &mbox->chans[chan];
if (type == IMX_MU_TYPE_TXDB_V2)
- p_chan->txdone_method = TXDONE_BY_ACK;
+ p_chan->txdone_method = MBOX_TXDONE_BY_ACK;
return p_chan;
}
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 138ffbcd4fde..30eafdf3a91e 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -72,7 +72,7 @@ static void msg_submit(struct mbox_chan *chan)
}
}
- if (!err && (chan->txdone_method & TXDONE_BY_POLL)) {
+ if (!err && (chan->txdone_method & MBOX_TXDONE_BY_POLL)) {
/* kick start the timer immediately to avoid delays */
scoped_guard(spinlock_irqsave, &chan->mbox->poll_hrt_lock)
hrtimer_start(&chan->mbox->poll_hrt, 0, HRTIMER_MODE_REL);
@@ -162,7 +162,7 @@ EXPORT_SYMBOL_GPL(mbox_chan_received_data);
*/
void mbox_chan_txdone(struct mbox_chan *chan, int r)
{
- if (unlikely(!(chan->txdone_method & TXDONE_BY_IRQ))) {
+ if (unlikely(!(chan->txdone_method & MBOX_TXDONE_BY_IRQ))) {
dev_err(chan->mbox->dev,
"Controller can't run the TX ticker\n");
return;
@@ -183,7 +183,7 @@ EXPORT_SYMBOL_GPL(mbox_chan_txdone);
*/
void mbox_client_txdone(struct mbox_chan *chan, int r)
{
- if (unlikely(!(chan->txdone_method & TXDONE_BY_ACK))) {
+ if (unlikely(!(chan->txdone_method & MBOX_TXDONE_BY_ACK))) {
dev_err(chan->mbox->dev, "Client can't run the TX ticker\n");
return;
}
@@ -344,8 +344,8 @@ static int __mbox_bind_client(struct mbox_chan *chan, struct mbox_client *cl)
chan->cl = cl;
init_completion(&chan->tx_complete);
- if (chan->txdone_method == TXDONE_BY_POLL && cl->knows_txdone)
- chan->txdone_method = TXDONE_BY_ACK;
+ if (chan->txdone_method == MBOX_TXDONE_BY_POLL && cl->knows_txdone)
+ chan->txdone_method = MBOX_TXDONE_BY_ACK;
}
if (chan->mbox->ops->startup) {
@@ -499,8 +499,8 @@ void mbox_free_channel(struct mbox_chan *chan)
scoped_guard(spinlock_irqsave, &chan->lock) {
chan->cl = NULL;
chan->active_req = MBOX_NO_MSG;
- if (chan->txdone_method == TXDONE_BY_ACK)
- chan->txdone_method = TXDONE_BY_POLL;
+ if (chan->txdone_method == MBOX_TXDONE_BY_ACK)
+ chan->txdone_method = MBOX_TXDONE_BY_POLL;
}
module_put(chan->mbox->dev->driver->owner);
@@ -531,13 +531,13 @@ int mbox_controller_register(struct mbox_controller *mbox)
return -EINVAL;
if (mbox->txdone_irq)
- txdone = TXDONE_BY_IRQ;
+ txdone = MBOX_TXDONE_BY_IRQ;
else if (mbox->txdone_poll)
- txdone = TXDONE_BY_POLL;
+ txdone = MBOX_TXDONE_BY_POLL;
else /* It has to be ACK then */
- txdone = TXDONE_BY_ACK;
+ txdone = MBOX_TXDONE_BY_ACK;
- if (txdone == TXDONE_BY_POLL) {
+ if (txdone == MBOX_TXDONE_BY_POLL) {
if (!mbox->ops->last_tx_done) {
dev_err(mbox->dev, "last_tx_done method is absent\n");
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c b/drivers/mailbox/mtk-cmdq-mailbox.c
index 547a10a8fad3..e523c84b4808 100644
--- a/drivers/mailbox/mtk-cmdq-mailbox.c
+++ b/drivers/mailbox/mtk-cmdq-mailbox.c
@@ -728,7 +728,7 @@ static int cmdq_probe(struct platform_device *pdev)
cmdq->mbox.ops = &cmdq_mbox_chan_ops;
cmdq->mbox.of_xlate = cmdq_xlate;
- /* make use of TXDONE_BY_ACK */
+ /* make use of MBOX_TXDONE_BY_ACK */
cmdq->mbox.txdone_irq = false;
cmdq->mbox.txdone_poll = false;
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 5772c6b9886a..535ca8020877 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b/drivers/mailbox/omap-mailbox.c
@@ -238,7 +238,7 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
}
if (mbox->send_no_irq)
- mbox->chan->txdone_method = TXDONE_BY_ACK;
+ mbox->chan->txdone_method = MBOX_TXDONE_BY_ACK;
omap_mbox_enable_irq(mbox, IRQ_RX);
diff --git a/drivers/mailbox/tegra-hsp.c b/drivers/mailbox/tegra-hsp.c
index 7b1e1b83ea29..500fa77c7d53 100644
--- a/drivers/mailbox/tegra-hsp.c
+++ b/drivers/mailbox/tegra-hsp.c
@@ -514,7 +514,7 @@ static int tegra_hsp_mailbox_startup(struct mbox_chan *chan)
struct tegra_hsp *hsp = mb->channel.hsp;
unsigned long flags;
- chan->txdone_method = TXDONE_BY_IRQ;
+ chan->txdone_method = MBOX_TXDONE_BY_IRQ;
/*
* Shared mailboxes start out as consumers by default. FULL and EMPTY
diff --git a/include/linux/mailbox_controller.h b/include/linux/mailbox_controller.h
index e3896b08f22e..a49ee687d4cf 100644
--- a/include/linux/mailbox_controller.h
+++ b/include/linux/mailbox_controller.h
@@ -15,9 +15,9 @@ struct mbox_chan;
/* Sentinel value distinguishing "no active request" from "NULL message data" */
#define MBOX_NO_MSG ((void *)-1)
-#define TXDONE_BY_IRQ BIT(0) /* controller has remote RTR irq */
-#define TXDONE_BY_POLL BIT(1) /* controller can read status of last TX */
-#define TXDONE_BY_ACK BIT(2) /* S/W ACK received by Client ticks the TX */
+#define MBOX_TXDONE_BY_IRQ BIT(0) /* controller has remote RTR irq */
+#define MBOX_TXDONE_BY_POLL BIT(1) /* controller can read status of last TX */
+#define MBOX_TXDONE_BY_ACK BIT(2) /* S/W ACK received by Client ticks the TX */
/**
* struct mbox_chan_ops - methods to control mailbox channels
--
2.51.0
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: pinctrl: nvidia,tegra234: Correctly use additionalProperties
From: Krzysztof Kozlowski @ 2026-04-10 11:10 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Jonathan Hunter, Prathamesh Shete, linux-gpio,
devicetree, linux-tegra, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20260410111047.309798-3-krzysztof.kozlowski@oss.qualcomm.com>
The binding does not reference any other schema, thus should use
"additionalProperties: false" to disallow any undocumented properties.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml | 2 +-
.../devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml
index 56fb9cf763ef..4910dc8e8aeb 100644
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml
@@ -62,7 +62,7 @@ required:
- compatible
- reg
-unevaluatedProperties: false
+additionalProperties: false
examples:
- |
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml
index bd305a34eee2..52b3d40e8839 100644
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml
@@ -119,7 +119,7 @@ required:
- compatible
- reg
-unevaluatedProperties: false
+additionalProperties: false
examples:
- |
--
2.51.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: pinctrl: nvidia,tegra234: Add missing required block
From: Krzysztof Kozlowski @ 2026-04-10 11:10 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Jonathan Hunter, Prathamesh Shete, linux-gpio,
devicetree, linux-tegra, linux-kernel
Cc: Krzysztof Kozlowski
Binding should require 'reg' property, because address space cannot be
missing in the hardware and is already needed by the Linux drivers.
Require also 'compatible' by convention, although it is not strictly
necessary.
Fixes: 857982138b79 ("dt-bindings: pinctrl: Document Tegra234 pin controllers")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml | 4 ++++
.../devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml
index db8224dfba2c..56fb9cf763ef 100644
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux-aon.yaml
@@ -58,6 +58,10 @@ patternProperties:
drive_soc_gpio27_pee6, drive_ao_retention_n_pee2,
drive_vcomp_alert_pee1, drive_hdmi_cec_pgg0 ]
+required:
+ - compatible
+ - reg
+
unevaluatedProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml
index f5a3a881dec4..bd305a34eee2 100644
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra234-pinmux.yaml
@@ -115,6 +115,10 @@ patternProperties:
drive_sdmmc1_dat2_pj4, drive_sdmmc1_dat1_pj3,
drive_sdmmc1_dat0_pj2 ]
+required:
+ - compatible
+ - reg
+
unevaluatedProperties: false
examples:
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 2/6] dt-bindings: pinctrl: Document Tegra238 pin controllers
From: Krzysztof Kozlowski @ 2026-04-10 11:04 UTC (permalink / raw)
To: pshete
Cc: linux-gpio, devicetree, linux-tegra, linux-kernel, arnd,
bjorn.andersson, conor+dt, dmitry.baryshkov, ebiggers, geert,
jonathanh, krzk+dt, kuninori.morimoto.gx, linusw, luca.weiss,
michal.simek, prabhakar.mahadev-lad.rj, robh, rosenp, sven,
thierry.reding, webgeek1234
In-Reply-To: <20260409131340.168556-3-pshete@nvidia.com>
On Thu, Apr 09, 2026 at 01:13:36PM +0000, pshete@nvidia.com wrote:
> + properties:
> + nvidia,pins:
> + items:
> + enum: [ bootv_ctl_n_paa0, soc_gpio00_paa1, vcomp_alert_paa2,
> + pwm1_paa3, batt_oc_paa4, soc_gpio04_paa5,
> + soc_gpio25_paa6, soc_gpio26_paa7,
> + hdmi_cec_pbb0,
> + spi2_sck_pcc0, spi2_miso_pcc1, spi2_mosi_pcc2,
> + spi2_cs0_pcc3, spi2_cs1_pcc4, uart3_tx_pcc5,
> + uart3_rx_pcc6, gen2_i2c_scl_pcc7,
> + gen2_i2c_sda_pdd0, gen8_i2c_scl_pdd1,
> + gen8_i2c_sda_pdd2, touch_clk_pdd3, dmic1_clk_pdd4,
> + dmic1_dat_pdd5, soc_gpio19_pdd6, pwm2_pdd7,
> + pwm3_pee0, pwm7_pee1,
> + # drive groups (ordered PAA, PBB, PCC, PDD, PEE)
> + drive_bootv_ctl_n_paa0, drive_soc_gpio00_paa1,
> + drive_vcomp_alert_paa2, drive_pwm1_paa3,
> + drive_batt_oc_paa4, drive_soc_gpio04_paa5,
> + drive_soc_gpio25_paa6, drive_soc_gpio26_paa7,
> + drive_hdmi_cec_pbb0,
> + drive_spi2_sck_pcc0, drive_spi2_miso_pcc1,
> + drive_spi2_mosi_pcc2, drive_spi2_cs0_pcc3,
> + drive_spi2_cs1_pcc4, drive_uart3_tx_pcc5,
> + drive_uart3_rx_pcc6, drive_gen2_i2c_scl_pcc7,
> + drive_gen2_i2c_sda_pdd0, drive_gen8_i2c_scl_pdd1,
> + drive_gen8_i2c_sda_pdd2, drive_touch_clk_pdd3,
> + drive_dmic1_clk_pdd4, drive_dmic1_dat_pdd5,
> + drive_soc_gpio19_pdd6, drive_pwm2_pdd7,
> + drive_pwm3_pee0, drive_pwm7_pee1 ]
> +
And missing required. I'll also fix existing ones.
> +unevaluatedProperties: false
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] pinctrl: tegra: Enable easier compile testing
From: Krzysztof Kozlowski @ 2026-04-10 11:00 UTC (permalink / raw)
To: Linus Walleij, Thierry Reding, Jonathan Hunter, linux-gpio,
linux-kernel, linux-tegra
In-Reply-To: <20260410103005.163128-2-krzysztof.kozlowski@oss.qualcomm.com>
On 10/04/2026 12:30, Krzysztof Kozlowski wrote:
> Currently NVIDIA Tegra pin controller drivers cannot be compile tested,
> unless ARCH_TEGRA is selected. That partially defeats the purpose of
> compile testing, since ARCH_TEGRA is pulled when building platform
> kernels. Solve it and allow compile testing independently of ARCH_TEGRA
> choice which requires few less usual changes:
>
> 1. Descent in Makefile in to drivers/pinctrl/tegra/ unconditionally,
> because there is no menu option.
>
> 2. Depend on COMMON_CLK for PINCTRL_TEGRA20, because it uses
> clk_register_mux().
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Not extensively compile tested yet. Pushing so LKP will pick it up. My
> build tests are still in progress.
I tested all of Ubuntu cross compile environments - arm, arm64, i386,
x86_64, sparc, m68k, sh, s390, riscv and powerpc.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/6] dt-bindings: pinctrl: Document Tegra238 pin controllers
From: Krzysztof Kozlowski @ 2026-04-10 11:00 UTC (permalink / raw)
To: pshete
Cc: linux-gpio, devicetree, linux-tegra, linux-kernel, arnd,
bjorn.andersson, conor+dt, dmitry.baryshkov, ebiggers, geert,
jonathanh, krzk+dt, kuninori.morimoto.gx, linusw, luca.weiss,
michal.simek, prabhakar.mahadev-lad.rj, robh, rosenp, sven,
thierry.reding, webgeek1234
In-Reply-To: <20260409131340.168556-3-pshete@nvidia.com>
On Thu, Apr 09, 2026 at 01:13:36PM +0000, pshete@nvidia.com wrote:
> +patternProperties:
> + "^pinmux(-[a-z0-9-]+)?$":
> + type: object
> +
> + # pin groups
> + additionalProperties:
> + $ref: nvidia,tegra238-pinmux-common.yaml
> +
> + properties:
> + nvidia,pins:
> + items:
> + enum: [ bootv_ctl_n_paa0, soc_gpio00_paa1, vcomp_alert_paa2,
> + pwm1_paa3, batt_oc_paa4, soc_gpio04_paa5,
> + soc_gpio25_paa6, soc_gpio26_paa7,
> + hdmi_cec_pbb0,
> + spi2_sck_pcc0, spi2_miso_pcc1, spi2_mosi_pcc2,
> + spi2_cs0_pcc3, spi2_cs1_pcc4, uart3_tx_pcc5,
> + uart3_rx_pcc6, gen2_i2c_scl_pcc7,
> + gen2_i2c_sda_pdd0, gen8_i2c_scl_pdd1,
> + gen8_i2c_sda_pdd2, touch_clk_pdd3, dmic1_clk_pdd4,
> + dmic1_dat_pdd5, soc_gpio19_pdd6, pwm2_pdd7,
> + pwm3_pee0, pwm7_pee1,
> + # drive groups (ordered PAA, PBB, PCC, PDD, PEE)
> + drive_bootv_ctl_n_paa0, drive_soc_gpio00_paa1,
> + drive_vcomp_alert_paa2, drive_pwm1_paa3,
> + drive_batt_oc_paa4, drive_soc_gpio04_paa5,
> + drive_soc_gpio25_paa6, drive_soc_gpio26_paa7,
> + drive_hdmi_cec_pbb0,
> + drive_spi2_sck_pcc0, drive_spi2_miso_pcc1,
> + drive_spi2_mosi_pcc2, drive_spi2_cs0_pcc3,
> + drive_spi2_cs1_pcc4, drive_uart3_tx_pcc5,
> + drive_uart3_rx_pcc6, drive_gen2_i2c_scl_pcc7,
> + drive_gen2_i2c_sda_pdd0, drive_gen8_i2c_scl_pdd1,
> + drive_gen8_i2c_sda_pdd2, drive_touch_clk_pdd3,
> + drive_dmic1_clk_pdd4, drive_dmic1_dat_pdd5,
> + drive_soc_gpio19_pdd6, drive_pwm2_pdd7,
> + drive_pwm3_pee0, drive_pwm7_pee1 ]
> +
> +unevaluatedProperties: false
additionalProperties. I'll fix existing files.
> +
> +examples:
> + - |
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] pinctrl: tegra: Enable easier compile testing
From: Krzysztof Kozlowski @ 2026-04-10 10:30 UTC (permalink / raw)
To: Linus Walleij, Thierry Reding, Jonathan Hunter, linux-gpio,
linux-kernel, linux-tegra
Cc: Krzysztof Kozlowski
Currently NVIDIA Tegra pin controller drivers cannot be compile tested,
unless ARCH_TEGRA is selected. That partially defeats the purpose of
compile testing, since ARCH_TEGRA is pulled when building platform
kernels. Solve it and allow compile testing independently of ARCH_TEGRA
choice which requires few less usual changes:
1. Descent in Makefile in to drivers/pinctrl/tegra/ unconditionally,
because there is no menu option.
2. Depend on COMMON_CLK for PINCTRL_TEGRA20, because it uses
clk_register_mux().
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Not extensively compile tested yet. Pushing so LKP will pick it up. My
build tests are still in progress.
---
drivers/pinctrl/Makefile | 2 +-
drivers/pinctrl/tegra/Kconfig | 22 ++++++++++++----------
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index f7d5d5f76d0c..9d33fa28a096 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -93,7 +93,7 @@ obj-y += starfive/
obj-$(CONFIG_PINCTRL_STM32) += stm32/
obj-y += sunplus/
obj-$(CONFIG_PINCTRL_SUNXI) += sunxi/
-obj-$(CONFIG_ARCH_TEGRA) += tegra/
+obj-y += tegra/
obj-y += ti/
obj-$(CONFIG_PINCTRL_UNIPHIER) += uniphier/
obj-$(CONFIG_PINCTRL_VISCONTI) += visconti/
diff --git a/drivers/pinctrl/tegra/Kconfig b/drivers/pinctrl/tegra/Kconfig
index 660d101ea367..3e8789871f0f 100644
--- a/drivers/pinctrl/tegra/Kconfig
+++ b/drivers/pinctrl/tegra/Kconfig
@@ -1,43 +1,45 @@
# SPDX-License-Identifier: GPL-2.0-only
config PINCTRL_TEGRA
- bool
+ bool "NVIDIA Tegra pin controllers common" if COMPILE_TEST && !ARCH_TEGRA
select PINMUX
select PINCONF
config PINCTRL_TEGRA20
- bool
+ bool "NVIDIA Tegra20 pin controller" if COMPILE_TEST && !ARCH_TEGRA
select PINCTRL_TEGRA
+ depends on COMMON_CLK
config PINCTRL_TEGRA30
- bool
+ bool "NVIDIA Tegra30 pin controller" if COMPILE_TEST && !ARCH_TEGRA
select PINCTRL_TEGRA
config PINCTRL_TEGRA114
- bool
+ bool "NVIDIA Tegra114 pin controller" if COMPILE_TEST && !ARCH_TEGRA
select PINCTRL_TEGRA
config PINCTRL_TEGRA124
- bool
+ bool "NVIDIA Tegra124 pin controller" if COMPILE_TEST && !ARCH_TEGRA
select PINCTRL_TEGRA
config PINCTRL_TEGRA210
- bool
+ bool "NVIDIA Tegra210 pin controller" if COMPILE_TEST && !ARCH_TEGRA
select PINCTRL_TEGRA
config PINCTRL_TEGRA186
- bool
+ bool "NVIDIA Tegra186 pin controller" if COMPILE_TEST && !ARCH_TEGRA
select PINCTRL_TEGRA
config PINCTRL_TEGRA194
- bool
+ bool "NVIDIA Tegra194 pin controller" if COMPILE_TEST && !ARCH_TEGRA
select PINCTRL_TEGRA
config PINCTRL_TEGRA234
- bool
+ bool "NVIDIA Tegra234 pin controller" if COMPILE_TEST && !ARCH_TEGRA
select PINCTRL_TEGRA
config PINCTRL_TEGRA_XUSB
- def_bool y if ARCH_TEGRA
+ bool "NVIDIA Tegra XUSB pin controller" if COMPILE_TEST && !ARCH_TEGRA
+ default y if ARCH_TEGRA
select GENERIC_PHY
select PINCONF
select PINMUX
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 3/6] pinctrl: tegra: Add Tegra238 pinmux driver
From: Krzysztof Kozlowski @ 2026-04-10 10:05 UTC (permalink / raw)
To: pshete, linux-gpio, devicetree, linux-tegra, linux-kernel, arnd,
bjorn.andersson, conor+dt, dmitry.baryshkov, ebiggers, geert,
jonathanh, krzk+dt, kuninori.morimoto.gx, linusw, luca.weiss,
michal.simek, prabhakar.mahadev-lad.rj, robh, rosenp, sven,
thierry.reding, webgeek1234
In-Reply-To: <20260409131340.168556-4-pshete@nvidia.com>
On 09/04/2026 15:13, pshete@nvidia.com wrote:
> From: Prathamesh Shete <pshete@nvidia.com>
>
> This change adds support for the two pin controllers
Please do not use "This commit/patch/change", but imperative mood. See
longer explanation here:
https://elixir.bootlin.com/linux/v6.16/source/Documentation/process/submitting-patches.rst#L94
> (MAIN and AON) found on Tegra238.
>
> Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
> ---
> drivers/pinctrl/tegra/Kconfig | 9 +
> drivers/pinctrl/tegra/Makefile | 1 +
> drivers/pinctrl/tegra/pinctrl-tegra238.c | 2056 ++++++++++++++++++++++
> 3 files changed, 2066 insertions(+)
> create mode 100644 drivers/pinctrl/tegra/pinctrl-tegra238.c
>
> diff --git a/drivers/pinctrl/tegra/Kconfig b/drivers/pinctrl/tegra/Kconfig
> index 660d101ea367..ccb8c337b4ee 100644
> --- a/drivers/pinctrl/tegra/Kconfig
> +++ b/drivers/pinctrl/tegra/Kconfig
> @@ -36,6 +36,15 @@ config PINCTRL_TEGRA234
> bool
> select PINCTRL_TEGRA
>
> +config PINCTRL_TEGRA238
> + tristate "NVIDIA Tegra238 pinctrl driver"
> + select PINCTRL_TEGRA
> + help
> + Say Y or M here to enable support for the pinctrl driver for
> + NVIDIA Tegra238 SoC. This driver controls the pin multiplexing
> + and configuration for the MAIN and AON pin controllers found
> + on Tegra238.
All other Tegra drivers are non-selectable, so you are introducing
completely different style. This needs explanation WHY in the commit msg.
Also, since you are changing things around, then I suggest to finally
enable proper COMPILE_TEST for all tegra pinctrl. Unless I mistaken,
it's impossible to compile test currently anything from Tegra pinctrl...
Actually let me take a look, maybe I will do it for several platforms.
...
> +static struct platform_driver tegra238_pinctrl_driver = {
> + .driver = {
> + .name = "tegra238-pinctrl",
> + .of_match_table = tegra238_pinctrl_of_match,
> + },
> + .probe = tegra238_pinctrl_probe,
> +};
> +
> +static int __init tegra238_pinctrl_init(void)
> +{
> + return platform_driver_register(&tegra238_pinctrl_driver);
> +}
> +module_init(tegra238_pinctrl_init);
> +
> +static void __exit tegra238_pinctrl_exit(void)
> +{
> + platform_driver_unregister(&tegra238_pinctrl_driver);
> +}
> +module_exit(tegra238_pinctrl_exit);
Why this cannot be module_platform_driver()?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 6/6] arm64: defconfig: make Tegra238 and Tegra264 Pinctrl a loadable module
From: Jon Hunter @ 2026-04-10 8:25 UTC (permalink / raw)
To: Krzysztof Kozlowski, pshete, linux-gpio, devicetree, linux-tegra,
linux-kernel, arnd, bjorn.andersson, conor+dt, dmitry.baryshkov,
ebiggers, geert, krzk+dt, kuninori.morimoto.gx, linusw,
luca.weiss, michal.simek, prabhakar.mahadev-lad.rj, robh, rosenp,
sven, thierry.reding, webgeek1234
In-Reply-To: <9408f231-7a12-425c-b8de-2990d3162bb3@kernel.org>
On 10/04/2026 07:37, Krzysztof Kozlowski wrote:
> On 09/04/2026 15:13, pshete@nvidia.com wrote:
>> From: Prathamesh Shete <pshete@nvidia.com>
>>
>> Building the Pinctrl driver into the kernel image increases its size.
>
> That's obvious.
>
>> These drivers are not required during early boot, build them as a loadable
>> module instead to reduce the kernel image size.
>
> So you replace built-in into module?
>>
>> Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
>> ---
>> arch/arm64/configs/defconfig | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
>> index dd1ac01ee29b..f525670d3b84 100644
>> --- a/arch/arm64/configs/defconfig
>> +++ b/arch/arm64/configs/defconfig
>> @@ -711,6 +711,8 @@ CONFIG_PINCTRL_SC8280XP_LPASS_LPI=m
>> CONFIG_PINCTRL_SM8550_LPASS_LPI=m
>> CONFIG_PINCTRL_SM8650_LPASS_LPI=m
>> CONFIG_PINCTRL_SOPHGO_SG2000=y
>> +CONFIG_PINCTRL_TEGRA238=m
>> +CONFIG_PINCTRL_TEGRA264=m
>
> No, you just added as module. Why do we want them in upstream defconfig?
>
> Standard question, already asked Nvidia more than once.
Yes :-)
Prathamesh, what we need to do is ...
1. Add a patch to populate the pinctrl DT nodes for Tegra264 device.
2. In this patch, only enable pinctrl for Tegra264 because we are
lacking an upstream board for Tegra238 for that moment. In the commit
message we should add a comment to indicate with Tegra264 platform is
using this.
We can still merge the DT binding-doc changes and driver for Tegra238,
but no point to enable in the defconfig yet.
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v6 00/10] Add GPCDMA support in Tegra264
From: Jon Hunter @ 2026-04-10 8:09 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Laxman Dewangan, Philipp Zabel, dmaengine,
devicetree, linux-tegra, linux-kernel, Akhil R, Frank Li
In-Reply-To: <586052f6-d415-4603-accb-be15bad80db8@nvidia.com>
Hi Vinod,
On 31/03/2026 19:06, Jon Hunter wrote:
>
> On 31/03/2026 11:22, Akhil R wrote:
>> This series adds support for GPCDMA in Tegra264 with additional
>> support for separate stream ID for each channel. Tegra264 GPCDMA
>> controller has changes in the register offsets and uses 41-bit
>> addressing for memory. Add changes in the tegra186-gpc-dma driver
>> to support these.
>>
>> v5->v6:
>> - Replace dev_err() with dev_err_probe() in the probe function for fixed
>> return values also.
>> v4->v5:
>> - Use dev_err_probe() when returning error from the probe function.
>> - Remove tegra194 and tegra234 compatible from the reset 'if' condition
>> in the bindings as suggested in v2 (which I missed).
>> v3->v4:
>> - Split device tree changes to two patches.
>> - Reordered patches to have fixes first.
>> - Added fixes tag to dt-bindings and device tree changes.
>> v2->v3:
>> - Add description for iommu-map property and update commit descriptions.
>> - Use enum for compatible string instead of const.
>> - Remove unused registers from struct tegra_dma_channel_regs.
>> - Use devm_of_dma_controller_register() to register the DMA controller.
>> - Remove return value check for mask setting in the driver as the bitmask
>> value is always greater than 32.
>> v1->v2:
>> - Fix dt_bindings_check warnings
>> - Drop fallback compatible "nvidia,tegra186-gpcdma" from Tegra264 DT
>> - Use dma_addr_t for sg_req src/dst fields and drop separate high_add
>> variable and check for the addr_bits only when programming the
>> registers.
>> - Update address width to 39 bits for Tegra234 and before since the SMMU
>> supports only up to 39 bits till Tegra234.
>> - Add a patch to do managed DMA controller registration.
>> - Describe the second iteration in the probe.
>> - Update commit descriptions.
>>
>> Akhil R (10):
>> dt-bindings: dma: nvidia,tegra186-gpc-dma: Make reset optional
>> arm64: tegra: Remove fallback compatible for GPCDMA
>> dt-bindings: dma: nvidia,tegra186-gpc-dma: Add iommu-map property
>> dmaengine: tegra: Make reset control optional
>> dmaengine: tegra: Use struct for register offsets
>> dmaengine: tegra: Support address width > 39 bits
>> dmaengine: tegra: Use managed DMA controller registration
>> dmaengine: tegra: Use iommu-map for stream ID
>> dmaengine: tegra: Add Tegra264 support
>> arm64: tegra: Enable GPCDMA in Tegra264 and add iommu-map
>>
>> .../bindings/dma/nvidia,tegra186-gpc-dma.yaml | 32 +-
>> .../arm64/boot/dts/nvidia/tegra264-p3834.dtsi | 4 +
>> arch/arm64/boot/dts/nvidia/tegra264.dtsi | 3 +-
>> drivers/dma/tegra186-gpc-dma.c | 429 +++++++++++-------
>> 4 files changed, 284 insertions(+), 184 deletions(-)
>>
>
> For the series ...
>
> Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
I am not sure if it is too late to pick this up for v7.1, but we would
like to get this into -next if you are happy with it.
Thanks
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v8 9/9] PCI: tegra194: Use aspm-l1-entry-delay-ns DT property for L1 entrance latency
From: Manikanta Maddireddy @ 2026-04-10 7:38 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: bhelgaas, lpieralisi, kwilczynski, mani, robh, krzk+dt, conor+dt,
thierry.reding, jonathanh, kishon, arnd, gregkh, Frank.Li, den,
hongxing.zhu, jingoohan1, vidyas, cassel, 18255117159, linux-pci,
linux-tegra, linux-kernel
In-Reply-To: <20260409184034.GA508609@bhelgaas>
On 10/04/26 12:10 am, Bjorn Helgaas wrote:
> On Thu, Apr 09, 2026 at 11:26:15AM +0530, Manikanta Maddireddy wrote:
>> On 09/04/26 4:00 am, Bjorn Helgaas wrote:
>>> On Wed, Mar 25, 2026 at 12:40:00AM +0530, Manikanta Maddireddy wrote:
>>>> Program ASPM L1 entrance latency from the optional aspm-l1-entry-delay-ns
>>>> device tree property instead of of_data. Convert the value from nanoseconds
>>>> to the hardware encoding (log2(us) + 1, 3-bit field). If the property is
>>>> absent, default to 7 (maximum latency).
>>>>
>>>> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
>>>> ---
>>>> Changes V8: Use aspm-l1-entry-delay-ns instead of of_data
>>>> Changes V1 -> V7: None
>>>>
>>>> drivers/pci/controller/dwc/pcie-tegra194.c | 14 ++++++++++++++
>>>> 1 file changed, 14 insertions(+)
>>>>
>>>> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
>>>> index 3278353b2c29..a856a48362df 100644
>>>> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
>>>> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
>>>> @@ -18,6 +18,7 @@
>>>> #include <linux/interrupt.h>
>>>> #include <linux/iopoll.h>
>>>> #include <linux/kernel.h>
>>>> +#include <linux/log2.h>
>>>> #include <linux/module.h>
>>>> #include <linux/of.h>
>>>> #include <linux/of_pci.h>
>>>> @@ -272,6 +273,7 @@ struct tegra_pcie_dw {
>>>> u32 aspm_cmrt;
>>>> u32 aspm_pwr_on_t;
>>>> u32 aspm_l0s_enter_lat;
>>>> + u32 aspm_l1_enter_lat;
>>>> struct regulator *pex_ctl_supply;
>>>> struct regulator *slot_ctl_3v3;
>>>> @@ -710,6 +712,8 @@ static void init_host_aspm(struct tegra_pcie_dw *pcie)
>>>> val = dw_pcie_readl_dbi(pci, PCIE_PORT_AFR);
>>>> val &= ~PORT_AFR_L0S_ENTRANCE_LAT_MASK;
>>>> val |= (pcie->aspm_l0s_enter_lat << PORT_AFR_L0S_ENTRANCE_LAT_SHIFT);
>>>> + val &= ~PORT_AFR_L1_ENTRANCE_LAT_MASK;
>>>> + val |= (pcie->aspm_l1_enter_lat << PORT_AFR_L1_ENTRANCE_LAT_SHIFT);
>>>> val |= PORT_AFR_ENTER_ASPM;
>>>> dw_pcie_writel_dbi(pci, PCIE_PORT_AFR, val);
>>>> }
>>>> @@ -1110,6 +1114,7 @@ static int tegra_pcie_dw_parse_dt(struct tegra_pcie_dw *pcie)
>>>> {
>>>> struct platform_device *pdev = to_platform_device(pcie->dev);
>>>> struct device_node *np = pcie->dev->of_node;
>>>> + u32 val;
>>>> int ret;
>>>> pcie->dbi_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi");
>>>> @@ -1136,6 +1141,15 @@ static int tegra_pcie_dw_parse_dt(struct tegra_pcie_dw *pcie)
>>>> dev_info(pcie->dev,
>>>> "Failed to read ASPM L0s Entrance latency: %d\n", ret);
>>>> + /* Default to max latency of 7. */
>>>> + pcie->aspm_l1_enter_lat = 7;
>>>> + ret = of_property_read_u32(np, "aspm-l1-entry-delay-ns", &val);
>>>> + if (!ret) {
>>>> + u32 us = max(val / 1000, 1U);
>>>> +
>>>> + pcie->aspm_l1_enter_lat = min(ilog2(us) + 1, 7U);
>>>
>>> I haven't investigated yet, but I see this build error on
>>> pci/controller/dwc-tegra194:
>>>
>>> CC drivers/pci/controller/dwc/pcie-tegra194.o
>>> In file included from <command-line>:
>>> In function ‘tegra_pcie_dw_parse_dt’,
>>> inlined from ‘tegra_pcie_dw_probe’ at drivers/pci/controller/dwc/pcie-tegra194.c:2148:8:
>>> ././include/linux/compiler_types.h:706:45: error: call to ‘__compiletime_assert_515’ declared with attribute error: min(( __builtin_constant_p(us) ? ((us) < 2 ? 0 : 63 - __builtin_clzll(us)) : (sizeof(us) <= 4) ? __ilog2_u32(us) : __ilog2_u64(us) ) + 1, 7U) signedness error
>> ...
>
>> I don't see this error at my side, but kernel test robot reported this error
>> at
>> https://lore.kernel.org/oe-kbuild-all/202604051407.AODe3ddZ-lkp@intel.com/.
>>
>> I published a patch https://patchwork.kernel.org/project/linux-pci/patch/20260407145749.130753-1-mmaddireddy@nvidia.com/
>> to fix this issue.
>
> I dropped the original patch so we can just add the fixed version so
> we don't have this commit plus another commit to fix the issue.
Hi Bjorn,
I published new patch with the fix.
https://patchwork.kernel.org/project/linux-pci/patch/20260410073330.837238-1-mmaddireddy@nvidia.com/
>
>> Could you provide me your build environmental details like which tool chain
>> and make command are you using? I will incorporate these steps so that I can
>> avoid mistakes like these in future.
>
> Sure. This is an x86_64 Unbuntu 25.10 system with gcc version 15.2.0
> (Ubuntu 15.2.0-4ubuntu4). Command was just "make". Config attached.
>
> Bjorn
Thank you.
I am able reproduce the error when I compiled for x86 with the attached
config.
--
nvpublic
^ permalink raw reply
* [PATCH] PCI: tegra194: Use aspm-l1-entry-delay-ns DT property for L1 entrance latency
From: Manikanta Maddireddy @ 2026-04-10 7:33 UTC (permalink / raw)
To: bhelgaas, lpieralisi, kwilczynski, mani, robh, krzk+dt, conor+dt,
thierry.reding, jonathanh, kishon, arnd, gregkh, Frank.Li, den,
hongxing.zhu, jingoohan1, vidyas, cassel, 18255117159
Cc: linux-pci, linux-tegra, linux-kernel, Manikanta Maddireddy
Program ASPM L1 entrance latency from the optional aspm-l1-entry-delay-ns
device tree property instead of of_data. Convert the value from nanoseconds
to the hardware encoding (log2(us) + 1, 3-bit field). If the property is
absent, default to 7 (maximum latency).
Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/20260324191000.1095768-10-mmaddireddy@nvidia.com
---
drivers/pci/controller/dwc/pcie-tegra194.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
index 50c5ef12552b..f171f7e32b75 100644
--- a/drivers/pci/controller/dwc/pcie-tegra194.c
+++ b/drivers/pci/controller/dwc/pcie-tegra194.c
@@ -18,6 +18,7 @@
#include <linux/interrupt.h>
#include <linux/iopoll.h>
#include <linux/kernel.h>
+#include <linux/log2.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_pci.h>
@@ -272,6 +273,7 @@ struct tegra_pcie_dw {
u32 aspm_cmrt;
u32 aspm_pwr_on_t;
u32 aspm_l0s_enter_lat;
+ u32 aspm_l1_enter_lat;
struct regulator *pex_ctl_supply;
struct regulator *slot_ctl_3v3;
@@ -710,6 +712,8 @@ static void init_host_aspm(struct tegra_pcie_dw *pcie)
val = dw_pcie_readl_dbi(pci, PCIE_PORT_AFR);
val &= ~PORT_AFR_L0S_ENTRANCE_LAT_MASK;
val |= (pcie->aspm_l0s_enter_lat << PORT_AFR_L0S_ENTRANCE_LAT_SHIFT);
+ val &= ~PORT_AFR_L1_ENTRANCE_LAT_MASK;
+ val |= (pcie->aspm_l1_enter_lat << PORT_AFR_L1_ENTRANCE_LAT_SHIFT);
val |= PORT_AFR_ENTER_ASPM;
dw_pcie_writel_dbi(pci, PCIE_PORT_AFR, val);
}
@@ -1110,6 +1114,7 @@ static int tegra_pcie_dw_parse_dt(struct tegra_pcie_dw *pcie)
{
struct platform_device *pdev = to_platform_device(pcie->dev);
struct device_node *np = pcie->dev->of_node;
+ u32 val;
int ret;
pcie->dbi_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi");
@@ -1136,6 +1141,15 @@ static int tegra_pcie_dw_parse_dt(struct tegra_pcie_dw *pcie)
dev_info(pcie->dev,
"Failed to read ASPM L0s Entrance latency: %d\n", ret);
+ /* Default to max latency of 7. */
+ pcie->aspm_l1_enter_lat = 7;
+ ret = of_property_read_u32(np, "aspm-l1-entry-delay-ns", &val);
+ if (!ret) {
+ u32 us = max(val / 1000, 1U);
+
+ pcie->aspm_l1_enter_lat = min(ilog2(us) + 1, 7);
+ }
+
ret = of_property_read_u32(np, "num-lanes", &pcie->num_lanes);
if (ret < 0) {
dev_err(pcie->dev, "Failed to read num-lanes: %d\n", ret);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] gpio: tegra: return -ENOMEM on allocation failure in probe
From: Bartosz Golaszewski @ 2026-04-10 7:01 UTC (permalink / raw)
To: linusw, brgl, thierry.reding, jonathanh, Samasth Norway Ananda
Cc: Bartosz Golaszewski, linux-gpio, linux-tegra, linux-kernel
In-Reply-To: <20260409185853.2163034-1-samasth.norway.ananda@oracle.com>
On Thu, 09 Apr 2026 11:58:53 -0700, Samasth Norway Ananda wrote:
> devm_kzalloc() failure in tegra_gpio_probe() returns -ENODEV, which
> indicates "no such device". The correct error code for a memory
> allocation failure is -ENOMEM.
>
>
Applied, thanks!
[1/1] gpio: tegra: return -ENOMEM on allocation failure in probe
https://git.kernel.org/brgl/c/57df6923ca53b524d06d2347b896d9de74b3bc86
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 6/6] arm64: defconfig: make Tegra238 and Tegra264 Pinctrl a loadable module
From: Krzysztof Kozlowski @ 2026-04-10 6:37 UTC (permalink / raw)
To: pshete, linux-gpio, devicetree, linux-tegra, linux-kernel, arnd,
bjorn.andersson, conor+dt, dmitry.baryshkov, ebiggers, geert,
jonathanh, krzk+dt, kuninori.morimoto.gx, linusw, luca.weiss,
michal.simek, prabhakar.mahadev-lad.rj, robh, rosenp, sven,
thierry.reding, webgeek1234
In-Reply-To: <20260409131340.168556-7-pshete@nvidia.com>
On 09/04/2026 15:13, pshete@nvidia.com wrote:
> From: Prathamesh Shete <pshete@nvidia.com>
>
> Building the Pinctrl driver into the kernel image increases its size.
That's obvious.
> These drivers are not required during early boot, build them as a loadable
> module instead to reduce the kernel image size.
So you replace built-in into module?
>
> Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
> ---
> arch/arm64/configs/defconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index dd1ac01ee29b..f525670d3b84 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -711,6 +711,8 @@ CONFIG_PINCTRL_SC8280XP_LPASS_LPI=m
> CONFIG_PINCTRL_SM8550_LPASS_LPI=m
> CONFIG_PINCTRL_SM8650_LPASS_LPI=m
> CONFIG_PINCTRL_SOPHGO_SG2000=y
> +CONFIG_PINCTRL_TEGRA238=m
> +CONFIG_PINCTRL_TEGRA264=m
No, you just added as module. Why do we want them in upstream defconfig?
Standard question, already asked Nvidia more than once.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v8 12/14] PCI: dwc: Apply ECRC workaround to DesignWare 5.00a as well
From: Manikanta Maddireddy @ 2026-04-10 6:32 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: bhelgaas, lpieralisi, kwilczynski, mani, robh, krzk+dt, conor+dt,
thierry.reding, jonathanh, kishon, arnd, gregkh, Frank.Li, den,
hongxing.zhu, jingoohan1, vidyas, cassel, 18255117159, linux-pci,
linux-tegra, linux-kernel
In-Reply-To: <20260409184528.GA508955@bhelgaas>
On 10/04/26 12:15 am, Bjorn Helgaas wrote:
> On Thu, Apr 09, 2026 at 02:21:57PM +0530, Manikanta Maddireddy wrote:
>> On 09/04/26 3:54 am, Bjorn Helgaas wrote:
>>> On Wed, Mar 25, 2026 at 12:37:53AM +0530, Manikanta Maddireddy wrote:
>>>> The ECRC (TLP digest) workaround was originally added for DesignWare
>>>> version 4.90a. Tegra234 SoC has 5.00a DWC HW version, which has
>>>> the same ATU TD override behaviour, so apply the workaround for 5.00a
>>>> too.
>>>>
>>>> Fixes: a54e19073718 ("PCI: tegra194: Add Tegra234 PCIe support")
>>>> Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
>>>> Tested-by: Jon Hunter <jonathanh@nvidia.com>
>>>> Reviewed-by: Vidya Sagar <vidyas@nvidia.com>
>>>> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
>>>> ---
>>>> Changes V8: Split into two patches
>>>> Changes V1 -> V7: None
>>>>
>>>> drivers/pci/controller/dwc/pcie-designware.c | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
>>>> index 345365ea97c7..c4dc2d88649e 100644
>>>> --- a/drivers/pci/controller/dwc/pcie-designware.c
>>>> +++ b/drivers/pci/controller/dwc/pcie-designware.c
>>>> @@ -486,7 +486,7 @@ static inline void dw_pcie_writel_atu_ob(struct dw_pcie *pci, u32 index, u32 reg
>>>> static inline u32 dw_pcie_enable_ecrc(u32 val)
>>>> {
>>>> /*
>>>> - * DesignWare core version 4.90A has a design issue where the 'TD'
>>>> + * DWC versions 0x3530302a and 0x3536322a has a design issue where the 'TD'
>>>
>>> 0x3536322a looks like DW_PCIE_VER_562A, not DW_PCIE_VER_500A, so this
>>> comment doesn't seem to match the commit log or the code.
>>>
>>> "0x3530302a and 0x3536322a" is not nearly as readable as 4.90A and
>>> 5.00A.
>>>
>>>> * bit in the Control register-1 of the ATU outbound region acts
>>>> * like an override for the ECRC setting, i.e., the presence of TLP
>>>> * Digest (ECRC) in the outgoing TLPs is solely determined by this
>>>> @@ -559,7 +559,7 @@ int dw_pcie_prog_outbound_atu(struct dw_pcie *pci,
>>>> if (upper_32_bits(limit_addr) > upper_32_bits(parent_bus_addr) &&
>>>> dw_pcie_ver_is_ge(pci, 460A))
>>>> val |= PCIE_ATU_INCREASE_REGION_SIZE;
>>>> - if (dw_pcie_ver_is(pci, 490A))
>>>> + if (dw_pcie_ver_is(pci, 490A) || dw_pcie_ver_is(pci, 500A))
>>>> val = dw_pcie_enable_ecrc(val);
>>>
>>> This is in shared DWC code, which raises the question of whether this
>>> issue applies *only* to 490A and 500A? What about other versions,
>>> e.g., 520A (unused AFAICS), 540A, 562A?
>>>
>>
>> Hi Bjorn,
>>
>> I reviewed our internal bug database, I found that this dependency of iATU
>> TD bit on ECRC is removed from version 5.10A. A comment from Synopsys case
>> is quoted in our internal bug. Shall I prepare patch to address this for all
>> versions < 5.10A? Or do we need inputs from Synopsys?
>
> The patch below looks good to me, assuming the commit log is updated
> to match this comment and the code.
>
> I don't have any visibility into the Synopsys IP versions.
Hi Bjorn,
I published new patch with proposed fix.
https://patchwork.kernel.org/project/linux-pci/patch/20260410062507.657453-1-mmaddireddy@nvidia.com/
Thanks,
Manikanta
>
>> Proposed patch
>>
>> --- a/drivers/pci/controller/dwc/pcie-designware.c
>> +++ b/drivers/pci/controller/dwc/pcie-designware.c
>> @@ -486,7 +486,7 @@ static inline void dw_pcie_writel_atu_ob(struct dw_pcie
>> *pci, u32 index, u32 reg
>> static inline u32 dw_pcie_enable_ecrc(u32 val)
>> {
>> /*
>> - * DWC versions 0x3530302a and 0x3536322a has a design issue where
>> the 'TD'
>> + * DWC versions less than 5.10A has a design issue where the 'TD'
>> * bit in the Control register-1 of the ATU outbound region acts
>> * like an override for the ECRC setting, i.e., the presence of TLP
>> * Digest (ECRC) in the outgoing TLPs is solely determined by this
>> @@ -559,7 +559,7 @@ int dw_pcie_prog_outbound_atu(struct dw_pcie *pci,
>> if (upper_32_bits(limit_addr) > upper_32_bits(parent_bus_addr) &&
>> dw_pcie_ver_is_ge(pci, 460A))
>> val |= PCIE_ATU_INCREASE_REGION_SIZE;
>> - if (dw_pcie_ver_is(pci, 490A) || dw_pcie_ver_is(pci, 500A))
>> + if (!dw_pcie_ver_is_ge(pci, 510A))
>> val = dw_pcie_enable_ecrc(val);
>> dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL1, val);
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-designware.h
>> b/drivers/pci/controller/dwc/pcie-designware.h
>> index 5bceadbd2c9f..00891adfd07d 100644
>> --- a/drivers/pci/controller/dwc/pcie-designware.h
>> +++ b/drivers/pci/controller/dwc/pcie-designware.h
>> @@ -35,6 +35,7 @@
>> #define DW_PCIE_VER_480A 0x3438302a
>> #define DW_PCIE_VER_490A 0x3439302a
>> #define DW_PCIE_VER_500A 0x3530302a
>> +#define DW_PCIE_VER_510A 0x3531302a
>> #define DW_PCIE_VER_520A 0x3532302a
>> #define DW_PCIE_VER_540A 0x3534302a
>> #define DW_PCIE_VER_562A 0x3536322a
>>
>> Thanks,
>> Manikanta
>>
>>>> dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL1, val);
>>>> --
>>>> 2.34.1
>>>>
>>
>> --
>> nvpublic
>>
--
nvpublic
^ permalink raw reply
* [PATCH 1/1] PCI: dwc: Apply ECRC workaround for DesignWare cores prior to 5.10A
From: Manikanta Maddireddy @ 2026-04-10 6:25 UTC (permalink / raw)
To: bhelgaas, lpieralisi, kwilczynski, mani, robh, krzk+dt, conor+dt,
thierry.reding, jonathanh, kishon, arnd, gregkh, Frank.Li, den,
hongxing.zhu, jingoohan1, vidyas, cassel, 18255117159
Cc: linux-pci, linux-tegra, linux-kernel, Manikanta Maddireddy
The ECRC (TLP digest) workaround was originally applied only for DesignWare
core version 4.90a. Per discussion in Synopsys case, the dependency of the
iATU TD bit on ECRC generation was removed in 5.10a, so apply the
workaround for all DWC versions below that release.
Replace the misleading comment that referred to raw version constants
with readable DesignWare release name aligned with the implementation.
Fixes: b210b1595606 PCI: dwc: Apply ECRC workaround to DesignWare 5.00a as well
Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
---
drivers/pci/controller/dwc/pcie-designware.c | 6 +++---
drivers/pci/controller/dwc/pcie-designware.h | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
index d69db0ab3b14..d0b3b93fc940 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -487,8 +487,8 @@ static inline void dw_pcie_writel_atu_ob(struct dw_pcie *pci, u32 index, u32 reg
static inline u32 dw_pcie_enable_ecrc(u32 val)
{
/*
- * DWC versions 0x3530302a and 0x3536322a has a design issue where the 'TD'
- * bit in the Control register-1 of the ATU outbound region acts
+ * DesignWare core versions prior to 5.10A have a design issue where the
+ * 'TD' bit in the Control register-1 of the ATU outbound region acts
* like an override for the ECRC setting, i.e., the presence of TLP
* Digest (ECRC) in the outgoing TLPs is solely determined by this
* bit. This is contrary to the PCIe spec which says that the
@@ -563,7 +563,7 @@ int dw_pcie_prog_outbound_atu(struct dw_pcie *pci,
if (upper_32_bits(limit_addr) > upper_32_bits(parent_bus_addr) &&
dw_pcie_ver_is_ge(pci, 460A))
val |= PCIE_ATU_INCREASE_REGION_SIZE;
- if (dw_pcie_ver_is(pci, 490A) || dw_pcie_ver_is(pci, 500A))
+ if (!dw_pcie_ver_is_ge(pci, 510A))
val = dw_pcie_enable_ecrc(val);
dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL1, val);
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 82946bf78b21..739a213c27c9 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -35,6 +35,7 @@
#define DW_PCIE_VER_480A 0x3438302a
#define DW_PCIE_VER_490A 0x3439302a
#define DW_PCIE_VER_500A 0x3530302a
+#define DW_PCIE_VER_510A 0x3531302a
#define DW_PCIE_VER_520A 0x3532302a
#define DW_PCIE_VER_540A 0x3534302a
#define DW_PCIE_VER_562A 0x3536322a
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v4 10/10] iommu/arm-smmu-v3: Allow sharing domain across SMMUs
From: Nicolin Chen @ 2026-04-10 1:18 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <20260410003624.GE3357077@nvidia.com>
On Thu, Apr 09, 2026 at 09:36:24PM -0300, Jason Gunthorpe wrote:
> On Thu, Apr 09, 2026 at 09:32:23PM -0300, Jason Gunthorpe wrote:
> Though something else is missing here, I expected this to be removed too:
>
> struct arm_smmu_domain {
> struct arm_smmu_device *smmu;
An, I didn't look into that very closely, as I vaguely recall that
we planned another series to clean this up.
> What is left using it?
>
> static int arm_smmu_s1_set_dev_pasid(struct iommu_domain *domain,
> struct device *dev, ioasid_t id,
> struct iommu_domain *old)
>
> int arm_smmu_set_pasid(struct arm_smmu_master *master,
> struct arm_smmu_domain *smmu_domain, ioasid_t pasid,
> struct arm_smmu_cd *cd, struct iommu_domain *old,
> arm_smmu_make_cd_fn make_cd_fn)
>
> Thous should use the new helper right? It should work for a S1 domain
> too.
Yes.
> static void arm_smmu_flush_iotlb_all(struct iommu_domain *domain)
> {
> struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
>
> if (smmu_domain->smmu)
> arm_smmu_tlb_inv_context(smmu_domain);
> }
>
> I suspect that is just dead code now, it is from before finalize was
> part of alloc?
It seems so. The invalidation doesn't need smmu_domain->smmu any
way.
I will clean this up in v5.
Thanks
Nicolin
^ permalink raw reply
* Re: [PATCH v4 10/10] iommu/arm-smmu-v3: Allow sharing domain across SMMUs
From: Jason Gunthorpe @ 2026-04-10 0:36 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <20260410003223.GD3357077@nvidia.com>
On Thu, Apr 09, 2026 at 09:32:23PM -0300, Jason Gunthorpe wrote:
> On Thu, Mar 19, 2026 at 12:51:56PM -0700, Nicolin Chen wrote:
> > @@ -987,6 +988,32 @@ struct arm_smmu_nested_domain {
> > __le64 ste[2];
> > };
> >
> > +static inline bool
> > +arm_smmu_domain_can_share(struct arm_smmu_domain *smmu_domain,
> > + struct arm_smmu_device *new_smmu)
> > +{
>
> Probably a bit big for an inline
>
> > + struct io_pgtable *pgtbl =
> > + io_pgtable_ops_to_pgtable(smmu_domain->pgtbl_ops);
> > +
> > + if (pgtbl->fmt == ARM_64_LPAE_S1 &&
> > + !(new_smmu->features & ARM_SMMU_FEAT_TRANS_S1))
> > + return false;
> > + if (pgtbl->fmt == ARM_64_LPAE_S2 &&
> > + !(new_smmu->features & ARM_SMMU_FEAT_TRANS_S2))
> > + return false;
> > + if (pgtbl->cfg.pgsize_bitmap & ~new_smmu->pgsize_bitmap)
> > + return false;
>
> I think this should check the lowest set bit in the
> domain->pgsize_bitmap is set in new_smmu->pgsize_bitmap
>
> ie that the selected tg is supported.
>
> The cfg.pgsize_bitmap is something a little different IIRC
>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Though something else is missing here, I expected this to be removed too:
struct arm_smmu_domain {
struct arm_smmu_device *smmu;
What is left using it?
static int arm_smmu_s1_set_dev_pasid(struct iommu_domain *domain,
struct device *dev, ioasid_t id,
struct iommu_domain *old)
int arm_smmu_set_pasid(struct arm_smmu_master *master,
struct arm_smmu_domain *smmu_domain, ioasid_t pasid,
struct arm_smmu_cd *cd, struct iommu_domain *old,
arm_smmu_make_cd_fn make_cd_fn)
Thous should use the new helper right? It should work for a S1 domain
too.
static void arm_smmu_flush_iotlb_all(struct iommu_domain *domain)
{
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
if (smmu_domain->smmu)
arm_smmu_tlb_inv_context(smmu_domain);
}
I suspect that is just dead code now, it is from before finalize was
part of alloc?
Jason
^ permalink raw reply
* Re: [PATCH v4 10/10] iommu/arm-smmu-v3: Allow sharing domain across SMMUs
From: Jason Gunthorpe @ 2026-04-10 0:32 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <5293b61417f96dd58f25fe797e7d0c20dbe30da8.1773949042.git.nicolinc@nvidia.com>
On Thu, Mar 19, 2026 at 12:51:56PM -0700, Nicolin Chen wrote:
> @@ -987,6 +988,32 @@ struct arm_smmu_nested_domain {
> __le64 ste[2];
> };
>
> +static inline bool
> +arm_smmu_domain_can_share(struct arm_smmu_domain *smmu_domain,
> + struct arm_smmu_device *new_smmu)
> +{
Probably a bit big for an inline
> + struct io_pgtable *pgtbl =
> + io_pgtable_ops_to_pgtable(smmu_domain->pgtbl_ops);
> +
> + if (pgtbl->fmt == ARM_64_LPAE_S1 &&
> + !(new_smmu->features & ARM_SMMU_FEAT_TRANS_S1))
> + return false;
> + if (pgtbl->fmt == ARM_64_LPAE_S2 &&
> + !(new_smmu->features & ARM_SMMU_FEAT_TRANS_S2))
> + return false;
> + if (pgtbl->cfg.pgsize_bitmap & ~new_smmu->pgsize_bitmap)
> + return false;
I think this should check the lowest set bit in the
domain->pgsize_bitmap is set in new_smmu->pgsize_bitmap
ie that the selected tg is supported.
The cfg.pgsize_bitmap is something a little different IIRC
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [PATCH v4 09/10] iommu/arm-smmu-v3: Remove ASID/VMID from arm_smmu_domain
From: Jason Gunthorpe @ 2026-04-10 0:27 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <b6d87a722635d29e896b277cb60f0208859073d6.1773949042.git.nicolinc@nvidia.com>
On Thu, Mar 19, 2026 at 12:51:55PM -0700, Nicolin Chen wrote:
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> index 846a278fa5469..0e48264ccd01b 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> @@ -300,14 +300,6 @@ static void arm_smmu_sva_domain_free(struct iommu_domain *domain)
> */
> arm_smmu_domain_inv(smmu_domain);
>
> - /*
> - * Notice that the arm_smmu_mm_arch_invalidate_secondary_tlbs op can
> - * still be called/running at this point. We allow the ASID to be
> - * reused, and if there is a race then it just suffers harmless
> - * unnecessary invalidation.
> - */
> - xa_erase(&arm_smmu_asid_xa, smmu_domain->cd.asid);
> -
I don't think this artifact has disappeared so the comment should
probably remain too. It has become slightly different because it is
now running under RCU protections so it will clear alot faster.
Otherwise
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [PATCH v4 08/10] iommu/arm-smmu-v3: Allocate INV_TYPE_S2_VMID_VSMMU in arm_vsmmu_init
From: Jason Gunthorpe @ 2026-04-10 0:19 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <05dd00dcb2f0d077f59bcbccac1820534ad7b5cf.1773949042.git.nicolinc@nvidia.com>
On Thu, Mar 19, 2026 at 12:51:54PM -0700, Nicolin Chen wrote:
> VMID owned by a vSMMU should be allocated in the viommu_init callback for
> - a straightforward lifecycle for a VMID used by a vSMMU
> - HW like tegra241-cmdqv needs to setup VINTF with the VMID
>
> Allocate/free a VMID in arm_vsmmu_init/destroy(). This decouples the VMID
> owned by vSMMU from the VMID living in the S2 parent domain (s2_cfg.vmid).
>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 +
> .../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 26 ++++++++++++++++---
> .../iommu/arm/arm-smmu-v3/tegra241-cmdqv.c | 1 +
> 3 files changed, 25 insertions(+), 3 deletions(-)
Yeah, this is exactly right now.. The vmid exists for the duration of
viommu and gets installed in the invs list when the s2 is actually
attached to a device.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [PATCH v4 07/10] iommu/arm-smmu-v3: Allocate IOTLB cache tag if no id to reuse
From: Jason Gunthorpe @ 2026-04-10 0:04 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <aea51cbf226d90436918dc09df5cf8f5c64ef8bb.1773949042.git.nicolinc@nvidia.com>
On Thu, Mar 19, 2026 at 12:51:53PM -0700, Nicolin Chen wrote:
> An IOTLB tag now is forwarded from arm_smmu_domain_get_iotlb_tag() to its
> final destination (a CD or STE entry).
>
> Thus, arm_smmu_domain_get_iotlb_tag() can safely delink its references to
> the cd->asid and s2_cfg->vmid in the smmu_domain. Instead, allocate a new
> IOTLB cache tag from the xarray/ida.
>
> The old ASID and VMID in the smmu_domain will be deprecated, once VMID is
> decoupled in the vSMMU use case too.
>
> Since invst->new_invs->inv[0] and invst->tag are basically the same thing,
> merge arm_smmu_inv_flush_iotlb_tag() into arm_smmu_iotlb_tag_free().
>
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 63 +++++++++++++--------
> 1 file changed, 38 insertions(+), 25 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [PATCH v4 06/10] iommu/arm-smmu-v3: Introduce INV_TYPE_S2_VMID_VSMMU
From: Jason Gunthorpe @ 2026-04-09 23:59 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <c514aa533257ce67bf28645863abf5eaab437996.1773949042.git.nicolinc@nvidia.com>
On Thu, Mar 19, 2026 at 12:51:52PM -0700, Nicolin Chen wrote:
> @@ -655,6 +655,7 @@ struct arm_smmu_cmdq_batch {
> enum arm_smmu_inv_type {
> INV_TYPE_S1_ASID,
> INV_TYPE_S2_VMID,
> + INV_TYPE_S2_VMID_VSMMU,
> INV_TYPE_S2_VMID_S1_CLEAR,
> INV_TYPE_ATS,
> INV_TYPE_ATS_FULL,
> @@ -3246,7 +3248,10 @@ int arm_smmu_find_iotlb_tag(struct iommu_domain *domain,
> tag->type = INV_TYPE_S1_ASID;
> break;
> case ARM_SMMU_DOMAIN_S2:
> - tag->type = INV_TYPE_S2_VMID;
> + if (to_vsmmu(domain))
> + tag->type = INV_TYPE_S2_VMID_VSMMU;
> + else
> + tag->type = INV_TYPE_S2_VMID;
> break;
This shouldn't search, the vmid always comes from the vsmmu struct.
arm_smmu_alloc_iotlb_tag() fixes it after, but the call in
arm_smmu_attach_prepare_invs() should also only be using the
vsmmu->vmid so this is a bug.
Just set tag->id here and return. Move the tag->smmu up so that is
safe.
> @@ -3357,7 +3369,7 @@ arm_smmu_master_build_invs(struct arm_smmu_master *master, bool ats_enabled,
> return NULL;
>
> /* All the nested S1 ASIDs have to be flushed when S2 parent changes */
> - if (nesting) {
> + if (tag->type == INV_TYPE_S2_VMID_VSMMU) {
> if (!arm_smmu_master_build_inv(master,
> INV_TYPE_S2_VMID_S1_CLEAR,
> tag->id, IOMMU_NO_PASID, 0))
I think this function should not mix nesting and type at the same
time..
If INV_TYPE_S2_VMID_VSMMU means the tag is used as a nesting child
then that should also drive the atc decision:
if (!arm_smmu_master_build_inv(
master, nesting ? INV_TYPE_ATS_FULL : INV_TYPE_ATS,
master->streams[i].id, ssid, 0))
Because it is exactly the same reasoning for the IOTLB full
invalidation.
This is the only place reading domain->nest_parent so we can get rid
of it too, instead it effectively becomes driven by tag which derives
the S2_VMID from domain->type == IOMMU_DOMAIN_NESTED
Jason
^ permalink raw reply
* Re: [PATCH v4 04/10] iommu/arm-smmu-v3: Pass in IOTLB cache tag to arm_smmu_master_build_invs()
From: Jason Gunthorpe @ 2026-04-09 23:43 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <87419a1f7371643959a037f1ee7119ffa054a9a1.1773949042.git.nicolinc@nvidia.com>
On Thu, Mar 19, 2026 at 12:51:50PM -0700, Nicolin Chen wrote:
> Now struct arm_smmu_attach_state carrys an IOTLB cache tag in invst->tag.
>
> Instead of getting the tag from smmu_domain again, pass in the invst->tag
> to arm_smmu_master_build_invs(). This could simplify the function.
/This could simplify/This does simplify/
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
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