* Re: [PATCH 1/1] ARM: dts: imx6ul: add #io-channel-cells to ADC
From: Frank Li @ 2026-04-09 10:57 UTC (permalink / raw)
To: Alexander Stein
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Markus Niebel, devicetree,
imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260409101759.4159324-1-alexander.stein@ew.tq-group.com>
On Thu, Apr 09, 2026 at 12:17:57PM +0200, Alexander Stein wrote:
> From: Markus Niebel <Markus.Niebel@ew.tq-group.com>
>
> This commit adds io-channel-cells property to the ADC node. This
Avoid use words "This patch/commit".
Add io-channel-cells property to the ADC node. This is required ...
Frank
> property is required in order for an IIO consumer driver to work.
>
> Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> ---
> arch/arm/boot/dts/nxp/imx/imx6ul.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/nxp/imx/imx6ul.dtsi b/arch/arm/boot/dts/nxp/imx/imx6ul.dtsi
> index 24541fdf49ceb..d2bfa08b5e767 100644
> --- a/arch/arm/boot/dts/nxp/imx/imx6ul.dtsi
> +++ b/arch/arm/boot/dts/nxp/imx/imx6ul.dtsi
> @@ -951,6 +951,7 @@ adc1: adc@2198000 {
> interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&clks IMX6UL_CLK_ADC1>;
> clock-names = "adc";
> + #io-channel-cells = <1>;
> fsl,adck-max-frequency = <30000000>, <40000000>,
> <20000000>;
> status = "disabled";
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH V3 7/7] arm64/hw_breakpoint: Enable FEAT_Debugv8p9
From: Mark Rutland @ 2026-04-09 10:52 UTC (permalink / raw)
To: Rob Herring
Cc: Anshuman Khandual, linux-arm-kernel, linux-kernel,
Jonathan Corbet, Marc Zyngier, Oliver Upton, James Morse,
Suzuki K Poulose, Catalin Marinas, Will Deacon, Mark Brown,
kvmarm
In-Reply-To: <CAL_JsqLEBJ7Ok9TngWTqjaWY_LJCPtronv8=gnm=J0FymDKLCg@mail.gmail.com>
On Thu, Apr 02, 2026 at 12:46:56PM -0500, Rob Herring wrote:
> On Thu, Apr 2, 2026 at 5:37 AM Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > On Tue, Mar 31, 2026 at 05:58:00PM -0500, Rob Herring wrote:
> > > On Mon, Dec 16, 2024 at 10:58:29AM +0000, Mark Rutland wrote:
> > > > On Mon, Dec 16, 2024 at 09:38:31AM +0530, Anshuman Khandual wrote:
> > That said, the use of 'bp_per_reg' looks suspect given their
> > arch_install_hw_breakpoint() and arch_uninstall_hw_breakpoint() modify
> > that non-atomically.
>
> You don't believe the comment saying counter->ctx->lock is held?
Sorry, my concern here was that hw_breakpoint_handler() (which cannot
hold the lock) consumes bp_per_reg[], and could race with the non-atomic
modification in arch_install_hw_breakpoint() or
arch_uninstall_hw_breakpoint().
I've sent a more elaborate mail to x86 folk, with that and another issue
caused by taking a breakpoint under arch_uninstall_hw_breakpoint():
https://lore.kernel.org/lkml/adZWmPW8S9Y2pwkv@J2N7QTR9R3.cambridge.arm.com/
I think we have a similar latent issue where we can take an breakpoint
or watchpoint ad infinitum, described in more detail at the end of this
mail.
[...]
> > > > | What prevents a race with an exception handler? e.g.
> > > > |
> > > > | * Does the structure of the code prevent that somehow?
> > >
> > > If you can't set a breakpoint/watchpoint in NOKPROBE_SYMBOL() annotated
> > > code, you can't race.
> >
> > As above, I agree (with caveats), but I couldn't spot where this is
> > enforced.
> >
> > > However, there's no such annotation for data. It looks like the kernel
> > > policy is "don't do that" or disable all breakpoints/watchpoints.
> >
> > If we have to transiently disable watchpoints/breakpoints when
> > manipulating the relevant HW registers, that sounds fine to me.
>
> For wp/bp_on_reg, the ordering is 'data access, h/w accesses'. I think
> we just need a barrier to enforce that ordering so the data access
> (and then watchpoint) don't trigger in the middle of the h/w accesses.
I assume that by 'h/w accesses' you mean MSRs to the system registers
controlling breakpoints/watchpoints. Ordering-wise, I don't believe
memory barriers are necessary here (explain in more detail below).
However, I also think there's a latent issue here that might bite us
with the new banking, described at the end of this mail.
Both breakpoint and watchpoint exceptions are synchronous, meanning that
they can only be taken from the specific instruction that triggered
them. However, updates to the watchpoint control registers *do* need a
context synchronization event before they're guarnateed to take effect.
For a sequence:
// Initially:
// - MDSCR, MDCR, DAIF.D permit debug exceptions at CurrentEL
// - No watchpoints enabled
0x000: LDR <val>, [<addr>]
0x004: MSR DBGWVR<n>_EL1, <addr>
0x008: MSR DBGWCR<n>_EL1, <configure_and_enable>
0x010: LDR <val>, [<addr>]
0x014: ISB
0x018: LDR <val>, [<addr>]
... we know:
(a) The LDR at 0x000 *cannot* trigger the watchpoint.
(b) The LDR at 0x010 *might* trigger the matchpoint.
(c) The LDR at 0x018 *must* trigger the watchpoint.
For C code, we can enforce this order with barrier(), e.g.
val = *addr;
barrier();
write_sysreg(addr, DBGWVR<n>_EL1);
write_sysreg(configure_and_enable, DBGWCR<n>_EL1);
isb();
... where the compiler cannot re-order the memory access (or
write_sysreg(), or isb()) across the barrier(), and as isb() has a
memory clobber, the same is true for isb().
Likewise, for the inverse sequence:
// Initially:
// - MDSCR, MDCR, DAIF.D permit debug exceptions at CurrentEL
// - Watchpoint configured and enabled for <addr>
0x100: LDR <val>, [<addr>]
0x104: MSR DBGWCR<n>_EL1, <disable>
0x108: LDR <val>, [<addr>]
0x110: ISB
0x114: LDR <val>, [<addr>]
... we know:
(a) The LDR at 0x100 *must* trigger the watchpoint.
(b) The LDR at 0x108 *might* trigger the watchpoint.
(c) The LDR at 0x114 *cannot* trigger the watchpoint.
> Any guidance on the flavor of dsb here? (And is there any guarantee
> that the access is visible to the watchpoint h/w after a dsb
> completes?)
Hopefully the above was sufficient?
As mentioned above, I think we have a latent issue where we can take a
breakpoint or watchpoint under arch_uninstall_hw_breakpoint(), where we
have:
arch_uninstall_hw_breakpoint(bp) {
...
hw_breakpoint_control(bp, HW_BREAKPOINT_UNINSTALL) {
...
hw_breakpoint_slot_setup(slots, max_slots, bp, HW_BREAKPOINT_UNINSTALL) {
...
*slot = NULL;
...
}
...
write_wb_reg(ctrl_reg, i, 0) {
...
write_sysreg(0, ...);
isb();
...
}
}
}
The HW breakpoint/watchpoint associated with 'bp' could be triggered
between setting '*slot' to NULL and the ISB. If that happens, then
do_breakpoint() won't find 'bp', and will return *without* disabling the
HW breakpoint or attempting to step.
If that first exception was taken *before* the MSR in write_sysreg(),
then nothing has changed, and the breakpoint/watchpoint will then be
taken again ad infinitum.
If that first exception was taken *after* the MSR in write_sysreg(), the
context synchronization provided by exception entry/return will prevent
it from being taken again.
Building v6.19 and testing (with pseudo-NMI enabled):
| # grep write_wb_reg /proc/kallsyms
| ffff80008004b980 t write_wb_reg
| # ./perf-6.19 stat -a -C 1 -e 'mem:0xffff80008004b980/4:xk' true
| rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
| rcu: 1-...0: (1 GPs behind) idle=2334/1/0x4000000000000000 softirq=140/140 fqs=2623
| rcu: (detected by 0, t=5252 jiffies, g=-859, q=7 ncpus=2)
| Sending NMI from CPU 0 to CPUs 1:
| NMI backtrace for cpu 1
| CPU: 1 UID: 0 PID: 139 Comm: perf-6.19 Not tainted 6.19.0 #1 PREEMPT
| Hardware name: linux,dummy-virt (DT)
| pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| pc : write_wb_reg+0x0/0x250
| lr : hw_breakpoint_control+0x164/0x248
| sp : ffff800082d73980
| pmr: 000000c0
| x29: ffff800082d73980 x28: ffff000004692dc0 x27: ffff8000802708a0
| x26: ffff00000473c000 x25: 0000000000000000 x24: 0000000000000000
| x23: ffff00000473c000 x22: 0000000000000000 x21: ffff800082d73b70
| x20: ffff00007fbd7b28 x19: ffff00000473c000 x18: 0000000000000000
| x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
| x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
| x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
| x8 : 0000000000000001 x7 : 0000000000000001 x6 : 0000000000000010
| x5 : 0000000000000001 x4 : 0000000000000006 x3 : ffff00000473c000
| x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000010
| Call trace:
| write_wb_reg+0x0/0x250 (P)
| arch_uninstall_hw_breakpoint+0x14/0x20
| hw_breakpoint_del+0x10/0x20
| event_sched_out+0x8c/0x160
| group_sched_out+0x44/0xa0
| __perf_event_disable.part.0+0x114/0x120
| __perf_event_disable+0x1c/0x2c
| event_function+0x84/0xd8
| remote_function+0x50/0x64
| generic_exec_single+0x88/0xf0
| smp_call_function_single+0x90/0x1c8
| event_function_call+0x1d8/0x1e4
| _perf_event_disable+0x44/0x6c
| perf_event_for_each_child+0x38/0x84
| _perf_ioctl+0x19c/0xab8
| perf_ioctl+0x50/0x80
| __arm64_sys_ioctl+0xa4/0x100
| invoke_syscall.constprop.0+0x40/0xf0
| el0_svc_common.constprop.0+0x38/0xd8
| do_el0_svc+0x1c/0x28
| el0_svc+0x38/0x148
| el0t_64_sync_handler+0xa0/0xe4
| el0t_64_sync+0x1ac/0x1b0
I think that ideally when diabling a breakpoint/watchpoint, we'd program
the control register *before* manipulating the slot. The existing
structure of the code is rather unhelpful for fixing that.
While this does fall into "don't do that" territory, I do think we
should aim for the kernel to survive rather than fall into a livelock.
I'll take another look into this shortly -- I think we need a wider
cleanup.
Mark.
^ permalink raw reply
* Re: [PATCH v10 17/20] coresight: trbe: Save and restore state across CPU low power state
From: James Clark @ 2026-04-09 10:52 UTC (permalink / raw)
To: Leo Yan
Cc: coresight, linux-arm-kernel, Suzuki K Poulose, Mike Leach,
Yeoreum Yun, Mark Rutland, Will Deacon, Yabin Cui, Keita Morisaki,
Yuanfang Zhang, Greg Kroah-Hartman, Alexander Shishkin,
Tamas Petz, Thomas Gleixner, Peter Zijlstra
In-Reply-To: <20260405-arm_coresight_path_power_management_improvement-v10-17-13e94754a8be@arm.com>
On 05/04/2026 4:02 pm, Leo Yan wrote:
> From: Yabin Cui <yabinc@google.com>
>
> TRBE context can be lost when a CPU enters low power states. If a trace
> source is restored while TRBE is not, tracing may run without an active
> sink, which can lead to hangs on some devices (e.g., Pixel 9).
Can't this still happen if saving the source times out on "wait for
TRCSTATR.IDLE to go up"?
That would make coresight_pm_save() exit early, not saving the active
TRBE state. Then when coresight_pm_restore() is called it restores a
stale inactive sink, then enables the source again which is the state
that can hang.
>
> The save and restore flows are described in the section K5.5 "Context
> switching" of Arm ARM (ARM DDI 0487 L.a). This commit adds save and
> restore callbacks with following the software usages defined in the
> architecture manual.
>
> During the restore flow, since TRBLIMITR_EL1.E resets to 0 on a warm
> reset, the trace buffer unit is disabled when idle resume, it is safe to
> restore base/pointer/status registers first and program TRBLIMITR_EL1
> last.
>
> Signed-off-by: Yabin Cui <yabinc@google.com>
> Tested-by: James Clark <james.clark@linaro.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: James Clark <james.clark@linaro.org>
> Co-developed-by: Leo Yan <leo.yan@arm.com>
> Signed-off-by: Leo Yan <leo.yan@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-trbe.c | 59 +++++++++++++++++++++++++++-
> 1 file changed, 58 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-trbe.c b/drivers/hwtracing/coresight/coresight-trbe.c
> index 14e35b9660d76e47619cc6026b94929b3bb3e02b..c7cbca45f2debd4047b93283ea9fe5dd9e1f2ebf 100644
> --- a/drivers/hwtracing/coresight/coresight-trbe.c
> +++ b/drivers/hwtracing/coresight/coresight-trbe.c
> @@ -116,6 +116,20 @@ static int trbe_errata_cpucaps[] = {
> */
> #define TRBE_WORKAROUND_OVERWRITE_FILL_MODE_SKIP_BYTES 256
>
> +/*
> + * struct trbe_save_state: Register values representing TRBE state
> + * @trblimitr - Trace Buffer Limit Address Register value
> + * @trbbaser - Trace Buffer Base Register value
> + * @trbptr - Trace Buffer Write Pointer Register value
> + * @trbsr - Trace Buffer Status Register value
> + */
> +struct trbe_save_state {
> + u64 trblimitr;
> + u64 trbbaser;
> + u64 trbptr;
> + u64 trbsr;
> +};
> +
> /*
> * struct trbe_cpudata: TRBE instance specific data
> * @trbe_flag - TRBE dirty/access flag support
> @@ -134,6 +148,7 @@ struct trbe_cpudata {
> enum cs_mode mode;
> struct trbe_buf *buf;
> struct trbe_drvdata *drvdata;
> + struct trbe_save_state save_state;
> DECLARE_BITMAP(errata, TRBE_ERRATA_MAX);
> };
>
> @@ -1189,6 +1204,46 @@ static irqreturn_t arm_trbe_irq_handler(int irq, void *dev)
> return IRQ_HANDLED;
> }
>
> +static int arm_trbe_save(struct coresight_device *csdev)
> +{
> + struct trbe_cpudata *cpudata = dev_get_drvdata(&csdev->dev);
> + struct trbe_save_state *state = &cpudata->save_state;
> +
> + state->trblimitr = read_sysreg_s(SYS_TRBLIMITR_EL1);
> +
> + /* Disable the unit, ensure the writes to memory are complete */
> + if (state->trblimitr & TRBLIMITR_EL1_E)
> + trbe_drain_and_disable_local(cpudata);
> +
> + state->trbbaser = read_sysreg_s(SYS_TRBBASER_EL1);
> + state->trbptr = read_sysreg_s(SYS_TRBPTR_EL1);
> + state->trbsr = read_sysreg_s(SYS_TRBSR_EL1);
> + return 0;
> +}
> +
> +static void arm_trbe_restore(struct coresight_device *csdev)
> +{
> + struct trbe_cpudata *cpudata = dev_get_drvdata(&csdev->dev);
> + struct trbe_save_state *state = &cpudata->save_state;
> +
> + write_sysreg_s(state->trbbaser, SYS_TRBBASER_EL1);
> + write_sysreg_s(state->trbptr, SYS_TRBPTR_EL1);
> + write_sysreg_s(state->trbsr, SYS_TRBSR_EL1);
> +
> + if (!(state->trblimitr & TRBLIMITR_EL1_E)) {
> + write_sysreg_s(state->trblimitr, SYS_TRBLIMITR_EL1);
> + } else {
> + /*
> + * The section K5.5 Context switching, Arm ARM (ARM DDI 0487
> + * L.a), S_PKLXF requires a Context synchronization event to
> + * guarantee the Trace Buffer Unit will observe the new values
> + * of the system registers.
> + */
> + isb();
> + set_trbe_enabled(cpudata, state->trblimitr);
> + }
> +}
> +
> static const struct coresight_ops_sink arm_trbe_sink_ops = {
> .enable = arm_trbe_enable,
> .disable = arm_trbe_disable,
> @@ -1198,7 +1253,9 @@ static const struct coresight_ops_sink arm_trbe_sink_ops = {
> };
>
> static const struct coresight_ops arm_trbe_cs_ops = {
> - .sink_ops = &arm_trbe_sink_ops,
> + .pm_save_disable = arm_trbe_save,
> + .pm_restore_enable = arm_trbe_restore,
> + .sink_ops = &arm_trbe_sink_ops,
> };
>
> static ssize_t align_show(struct device *dev, struct device_attribute *attr, char *buf)
>
^ permalink raw reply
* Re: [PATCH v10 16/20] coresight: Add PM callbacks for sink device
From: James Clark @ 2026-04-09 10:52 UTC (permalink / raw)
To: Leo Yan
Cc: coresight, linux-arm-kernel, Yeoreum Yun, Mark Rutland,
Will Deacon, Yabin Cui, Keita Morisaki, Yuanfang Zhang,
Greg Kroah-Hartman, Alexander Shishkin, Tamas Petz,
Thomas Gleixner, Peter Zijlstra, Suzuki K Poulose, Mike Leach
In-Reply-To: <20260405-arm_coresight_path_power_management_improvement-v10-16-13e94754a8be@arm.com>
On 05/04/2026 4:02 pm, Leo Yan wrote:
> Unlike system level sinks, per-CPU sinks may lose power during CPU idle
> states. Currently, this applies specifically to TRBE. This commit
> invokes save and restore callbacks for the sink in the CPU PM notifier.
>
> If the sink provides PM callbacks but the source does not, this is
> unsafe because the sink cannot be disabled safely unless the source
> can also be controlled, so veto low power entry to avoid lockups.
>
> Tested-by: James Clark <james.clark@linaro.org>
> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
> Reviewed-by: James Clark <james.clark@linaro.org>
> Signed-off-by: Leo Yan <leo.yan@arm.com>
> ---
> drivers/hwtracing/coresight/coresight-core.c | 46 ++++++++++++++++++++++++++--
> 1 file changed, 43 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
> index c1e8debc76aba7eb5ecf7efe2a3b9b8b3e11b10c..a918bf6398a932de30fe9b4947020cc4c1cfb2f7 100644
> --- a/drivers/hwtracing/coresight/coresight-core.c
> +++ b/drivers/hwtracing/coresight/coresight-core.c
> @@ -1736,14 +1736,15 @@ static void coresight_release_device_list(void)
> /* Return: 1 if PM is required, 0 if skip, <0 on error */
> static int coresight_pm_check(struct coresight_path *path)
> {
> - struct coresight_device *source;
> - bool source_has_cb;
> + struct coresight_device *source, *sink;
> + bool source_has_cb, sink_has_cb;
>
> if (!path)
> return 0;
>
> source = coresight_get_source(path);
> - if (!source)
> + sink = coresight_get_sink(path);
> + if (!source || !sink)
> return 0;
>
> /* Don't save and restore if the source is inactive */
> @@ -1759,16 +1760,36 @@ static int coresight_pm_check(struct coresight_path *path)
> if (source_has_cb)
> return 1;
>
> + sink_has_cb = coresight_ops(sink)->pm_save_disable &&
> + coresight_ops(sink)->pm_restore_enable;
> + /*
> + * It is not permitted that the source has no callbacks while the sink
> + * does, as the sink cannot be disabled without disabling the source,
> + * which may lead to lockups. Alternatively, the ETM driver should
> + * enable self-hosted PM mode at probe (see etm4_probe()).
> + */
> + if (sink_has_cb) {
> + pr_warn_once("coresight PM failed: source has no PM callbacks; "
> + "cannot safely control sink\n");
This prints out on my Orion board on a fresh boot because of how
pm_save_enable is setup there. Do we really need the configuration of
pm_save_enable for ETE/TRBE if we know that it always needs saving?
It also stops warning if I rmmod and modprobe the module after booting.
Seems like pm_save_enable is different depending on how the module is
loaded which doesn't seem right.
> + return -EINVAL;
> + }
> +
> return 0;
> }
>
> static int coresight_pm_device_save(struct coresight_device *csdev)
> {
> + if (!csdev || !coresight_ops(csdev)->pm_save_disable)
> + return 0;
> +
> return coresight_ops(csdev)->pm_save_disable(csdev);
> }
>
> static void coresight_pm_device_restore(struct coresight_device *csdev)
> {
> + if (!csdev || !coresight_ops(csdev)->pm_restore_enable)
> + return;
> +
> coresight_ops(csdev)->pm_restore_enable(csdev);
> }
>
> @@ -1787,15 +1808,32 @@ static int coresight_pm_save(struct coresight_path *path)
> to = list_prev_entry(coresight_path_last_node(path), link);
> coresight_disable_path_from_to(path, from, to);
>
> + ret = coresight_pm_device_save(coresight_get_sink(path));
> + if (ret)
> + goto sink_failed;
> +
The comment directly above this says "Up to the node before sink to
avoid latency". But then this line goes and saves the sink anyway. So
I'm not sure what's meant by the comment?
> return 0;
> +
> +sink_failed:
> + if (!coresight_enable_path_from_to(path, coresight_get_mode(source),
> + from, to))
> + coresight_pm_device_restore(source);
> +
> + pr_err("Failed in coresight PM save on CPU%d: %d\n",
> + smp_processor_id(), ret);
> + this_cpu_write(percpu_pm_failed, true);
Why does only a failing sink set percpu_pm_failed when failing to save
the source exits early. Sashiko has a similar comment that this could
result in restoring uninitialised source save data later, but a comment
in this function about why the flow is like this would be helpful.
We have coresight_disable_path_from_to() which always succeeds and
doesn't return an error. TRBE is the only sink with a pm_save_disable()
callback, but it always succeeds anyway.
Would it not be much simpler to require that sink save/restore callbacks
always succeed and don't return anything? Seems like this
percpu_pm_failed stuff is extra complexity for a scenario that doesn't
exist? The only thing that can fail is saving the source but it doesn't
goto sink_failed when that happens.
Ideally etm4_cpu_save() wouldn't have a return value either. It would be
good if we could find away to skip or ignore the timeouts in there
somehow because that's the only reason it can fail.
> + return ret;
> }
>
> static void coresight_pm_restore(struct coresight_path *path)
> {
> struct coresight_device *source = coresight_get_source(path);
> + struct coresight_device *sink = coresight_get_sink(path);
> struct coresight_node *from, *to;
> int ret;
>
> + coresight_pm_device_restore(sink);
> +
> from = coresight_path_first_node(path);
> /* Up to the node before sink to avoid latency */
> to = list_prev_entry(coresight_path_last_node(path), link);
> @@ -1808,6 +1846,8 @@ static void coresight_pm_restore(struct coresight_path *path)
> return;
>
> path_failed:
> + coresight_pm_device_save(sink);
> +
> pr_err("Failed in coresight PM restore on CPU%d: %d\n",
> smp_processor_id(), ret);
>
>
^ permalink raw reply
* Re: [RFC V1 02/16] mm: Add read-write accessors for vm_page_prot
From: Mike Rapoport @ 2026-04-09 10:37 UTC (permalink / raw)
To: Anshuman Khandual
Cc: linux-arm-kernel, Catalin Marinas, Will Deacon, Ryan Roberts,
Mark Rutland, Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Linu Cherian, linux-kernel, linux-mm
In-Reply-To: <20260224051153.3150613-3-anshuman.khandual@arm.com>
Hi Anshuman,
On Tue, Feb 24, 2026 at 10:41:39AM +0530, Anshuman Khandual wrote:
> Currently vma->vm_page_prot is safely read from and written to, without any
> locks with READ_ONCE() and WRITE_ONCE(). But with introduction of D128 page
> tables on arm64 platform, vm_page_prot grows to 128 bits which can't safely
> be handled with READ_ONCE() and WRITE_ONCE().
>
> Add read and write accessors for vm_page_prot like pgprot_read/write_once()
> which any platform can override when required, although still defaulting as
> READ_ONCE() and WRITE_ONCE(), thus preserving the functionality for others.
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: David Hildenbrand <david@kernel.org>
> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Cc: Mike Rapoport <rppt@kernel.org>
> Cc: linux-mm@kvack.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> include/linux/pgtable.h | 14 ++++++++++++++
> mm/huge_memory.c | 4 ++--
> mm/memory.c | 2 +-
> mm/migrate.c | 2 +-
> mm/mmap.c | 2 +-
> 5 files changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index da17139a1279..8858b8b03a02 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -495,6 +495,20 @@ static inline pgd_t pgdp_get(pgd_t *pgdp)
> }
> #endif
>
> +#ifndef pgprot_read_once
> +static inline pgprot_t pgprot_read_once(pgprot_t *prot)
I don't think we need _once in the helper name. Presence of the helper
already implies that pointer should not be just dereferenced from one side
and that using the helper will do The Right Thing from the other side.
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [RFC V1 01/16] mm: Abstract printing of pxd_val()
From: Mike Rapoport @ 2026-04-09 10:33 UTC (permalink / raw)
To: Anshuman Khandual
Cc: linux-arm-kernel, Catalin Marinas, Will Deacon, Ryan Roberts,
Mark Rutland, Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Linu Cherian, linux-kernel, linux-mm
In-Reply-To: <20260224051153.3150613-2-anshuman.khandual@arm.com>
Hi Anshuman,
On Tue, Feb 24, 2026 at 10:41:38AM +0530, Anshuman Khandual wrote:
> Ahead of adding support for D128 pgtables, refactor places that print
> PTE values to use the new __PRIpte format specifier and __PRIpte_args()
> macro to prepare the argument(s). When using D128 pgtables in future,
> we can simply redefine __PRIpte and __PTIpte_args().
>
> Besides there is also an assumption about pxd_val() being always capped
> at 'unsigned long long' size but that will not work for D128 pgtables.
> Just increase its size to u128 if the compiler supports via a separate
> data type pxdval_t which also defaults to existing 'unsigned long long'.
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: David Hildenbrand <david@kernel.org>
> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Cc: Mike Rapoport <rppt@kernel.org>
> Cc: linux-mm@kvack.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> include/linux/pgtable.h | 5 +++++
> mm/memory.c | 29 +++++++++++++++++++----------
> 2 files changed, 24 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index a50df42a893f..da17139a1279 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -17,6 +17,11 @@
> #include <asm-generic/pgtable_uffd.h>
> #include <linux/page_table_check.h>
>
> +#ifndef __PRIpte
> +#define __PRIpte "016llx"
> +#define __PRIpte_args(val) ((u64)val)
> +#endif
> +
> #if 5 - defined(__PAGETABLE_P4D_FOLDED) - defined(__PAGETABLE_PUD_FOLDED) - \
> defined(__PAGETABLE_PMD_FOLDED) != CONFIG_PGTABLE_LEVELS
> #error CONFIG_PGTABLE_LEVELS is not consistent with __PAGETABLE_{P4D,PUD,PMD}_FOLDED
> diff --git a/mm/memory.c b/mm/memory.c
> index 07778814b4a8..cfc3077fc52f 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -532,9 +532,15 @@ static bool is_bad_page_map_ratelimited(void)
> return false;
> }
>
> +#ifdef __SIZEOF_INT128__
> + typedef u128 pxdval_t;
I don't think the typedef should be indented.
> +#else
> + typedef unsigned long long pxdval_t;
> +#endif
Don't we want this in, say, include/linux/pgtable.h?
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [RFC PATCH 5/8] mm/vmalloc: map contiguous pages in batches for vmap() if possible
From: Uladzislau Rezki @ 2026-04-09 10:20 UTC (permalink / raw)
To: Barry Song, Dev Jain
Cc: Dev Jain, linux-mm, linux-arm-kernel, catalin.marinas, will, akpm,
urezki, linux-kernel, anshuman.khandual, ryan.roberts, ajd, rppt,
david, Xueyuan.chen21
In-Reply-To: <CAGsJ_4yL3Y1Sr0MjTd6=ROC0jKf4JkCqNPODMh-m155rUFcS9g@mail.gmail.com>
On Thu, Apr 09, 2026 at 05:54:55AM +0800, Barry Song wrote:
> On Wed, Apr 8, 2026 at 10:03 PM Dev Jain <dev.jain@arm.com> wrote:
> >
> >
> >
> > On 08/04/26 8:21 am, Barry Song (Xiaomi) wrote:
> > > In many cases, the pages passed to vmap() may include high-order
> > > pages allocated with __GFP_COMP flags. For example, the systemheap
> > > often allocates pages in descending order: order 8, then 4, then 0.
> > > Currently, vmap() iterates over every page individually—even pages
> > > inside a high-order block are handled one by one.
> > >
> > > This patch detects high-order pages and maps them as a single
> > > contiguous block whenever possible.
> > >
> > > An alternative would be to implement a new API, vmap_sg(), but that
> > > change seems to be large in scope.
> > >
> > > Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> > > ---
> > > mm/vmalloc.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++--
> > > 1 file changed, 49 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > > index eba436386929..e8dbfada42bc 100644
> > > --- a/mm/vmalloc.c
> > > +++ b/mm/vmalloc.c
> > > @@ -3529,6 +3529,53 @@ void vunmap(const void *addr)
> > > }
> > > EXPORT_SYMBOL(vunmap);
> > >
> > > +static inline int get_vmap_batch_order(struct page **pages,
> > > + unsigned int max_steps, unsigned int idx)
> > > +{
> > > + unsigned int nr_pages;
> > > +
> > > + if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP) ||
> > > + ioremap_max_page_shift == PAGE_SHIFT)
> > > + return 0;
> > > +
> > > + nr_pages = compound_nr(pages[idx]);
> > > + if (nr_pages == 1 || max_steps < nr_pages)
> > > + return 0;
> >
> > This assumes that the page array passed to vmap() will have compound pages
> > if it is a higher order allocation.
> >
> > See rb_alloc_aux_page(). It gets higher-order allocations without passing
> > GFP_COMP.
> >
> > That is why my implementation does not assume anything about the property
> > of the pages.
>
> If you’re asking about support for non-compound pages, I think
> that’s fine. My current use case is dma-buf, where pages are
> compound. I recall discussing this previously with David and
> Uladzislau.
>
> If you’re working with non-compound pages, I’m happy to add
> support in the next version. I’m also happy to reuse some of your
> code and credit you as Co-developed-by if you’re willing. I actually
> prefer your __vmap_huge() name over my
> vmap_contig_pages_range().
>
> Does that make sense to you?
>
> >
> > Also it may be useful to do regression-testing for the common case of
> > vmap() with a single page (assuming it is common, I don't know), in
> > which case we may have to special case it.
>
> I agree, so I had Xueyuan test single pages and highlighted this
> in the cover letter. There is no regression: "vmap() is 5.6×
> faster when memory includes some order-8 pages, with no
> regression observed for order-0 pages."
>
> >
> > My implementation requires opting in with VM_ALLOW_HUGE_VMAP - I suspect
> > you may run into problems if you make vmap() do huge-mappings as best-effort
> > by default. I am guessing this because ...
> >
> > Drivers can operate on individual pages, so vmalloc() calls split_page()
> > and then does the block/cont mappings. This same issue should be present
> > with vmap() too? In which case if we are to do huge-mappings by default
> > then we can do split_page() after detecting contiguous chunks.
> >
> > But ... that may create problems for the caller of vmap() - vmap now
> > has the changed the properties of the pages.
>
> I don’t see this as a problem at all. Splitting pages does not
> affect physical or virtual contiguity; it only changes the
> contents of struct page objects, not the PTE/PMD mappings.
> For ioremap, there isn’t even a struct page, yet the mappings
> can still be huge.
>
It would be good if you could combine the work together with Jain.
--
Uladzislau Rezki
^ permalink raw reply
* [PATCH 1/1] ARM: dts: imx6ul: add #io-channel-cells to ADC
From: Alexander Stein @ 2026-04-09 10:17 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Markus Niebel, devicetree, imx, linux-arm-kernel, linux-kernel,
Alexander Stein
From: Markus Niebel <Markus.Niebel@ew.tq-group.com>
This commit adds io-channel-cells property to the ADC node. This
property is required in order for an IIO consumer driver to work.
Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
arch/arm/boot/dts/nxp/imx/imx6ul.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6ul.dtsi b/arch/arm/boot/dts/nxp/imx/imx6ul.dtsi
index 24541fdf49ceb..d2bfa08b5e767 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6ul.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6ul.dtsi
@@ -951,6 +951,7 @@ adc1: adc@2198000 {
interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6UL_CLK_ADC1>;
clock-names = "adc";
+ #io-channel-cells = <1>;
fsl,adck-max-frequency = <30000000>, <40000000>,
<20000000>;
status = "disabled";
--
2.43.0
^ permalink raw reply related
* Re: [RFC PATCH 5/8] mm/vmalloc: map contiguous pages in batches for vmap() if possible
From: Dev Jain @ 2026-04-09 10:10 UTC (permalink / raw)
To: Barry Song
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, urezki,
linux-kernel, anshuman.khandual, ryan.roberts, ajd, rppt, david,
Xueyuan.chen21
In-Reply-To: <CAGsJ_4yL3Y1Sr0MjTd6=ROC0jKf4JkCqNPODMh-m155rUFcS9g@mail.gmail.com>
On 09/04/26 3:24 am, Barry Song wrote:
> On Wed, Apr 8, 2026 at 10:03 PM Dev Jain <dev.jain@arm.com> wrote:
>>
>>
>>
>> On 08/04/26 8:21 am, Barry Song (Xiaomi) wrote:
>>> In many cases, the pages passed to vmap() may include high-order
>>> pages allocated with __GFP_COMP flags. For example, the systemheap
>>> often allocates pages in descending order: order 8, then 4, then 0.
>>> Currently, vmap() iterates over every page individually—even pages
>>> inside a high-order block are handled one by one.
>>>
>>> This patch detects high-order pages and maps them as a single
>>> contiguous block whenever possible.
>>>
>>> An alternative would be to implement a new API, vmap_sg(), but that
>>> change seems to be large in scope.
>>>
>>> Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
>>> ---
>>> mm/vmalloc.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++--
>>> 1 file changed, 49 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>>> index eba436386929..e8dbfada42bc 100644
>>> --- a/mm/vmalloc.c
>>> +++ b/mm/vmalloc.c
>>> @@ -3529,6 +3529,53 @@ void vunmap(const void *addr)
>>> }
>>> EXPORT_SYMBOL(vunmap);
>>>
>>> +static inline int get_vmap_batch_order(struct page **pages,
>>> + unsigned int max_steps, unsigned int idx)
>>> +{
>>> + unsigned int nr_pages;
>>> +
>>> + if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP) ||
>>> + ioremap_max_page_shift == PAGE_SHIFT)
>>> + return 0;
>>> +
>>> + nr_pages = compound_nr(pages[idx]);
>>> + if (nr_pages == 1 || max_steps < nr_pages)
>>> + return 0;
>>
>> This assumes that the page array passed to vmap() will have compound pages
>> if it is a higher order allocation.
>>
>> See rb_alloc_aux_page(). It gets higher-order allocations without passing
>> GFP_COMP.
>>
>> That is why my implementation does not assume anything about the property
>> of the pages.
>
> If you’re asking about support for non-compound pages, I think
> that’s fine. My current use case is dma-buf, where pages are
> compound. I recall discussing this previously with David and
> Uladzislau.
>
> If you’re working with non-compound pages, I’m happy to add
> support in the next version. I’m also happy to reuse some of your
> code and credit you as Co-developed-by if you’re willing. I actually
> prefer your __vmap_huge() name over my
> vmap_contig_pages_range().
>
> Does that make sense to you?
Yeah it will perhaps be better to have a fast-path detecting compound
pages, and if not then checking contiguity. So sure please go ahead
sharing some of my code and you can co-credit me.
>
>>
>> Also it may be useful to do regression-testing for the common case of
>> vmap() with a single page (assuming it is common, I don't know), in
>> which case we may have to special case it.
>
> I agree, so I had Xueyuan test single pages and highlighted this
> in the cover letter. There is no regression: "vmap() is 5.6×
> faster when memory includes some order-8 pages, with no
> regression observed for order-0 pages."
>
>>
>> My implementation requires opting in with VM_ALLOW_HUGE_VMAP - I suspect
>> you may run into problems if you make vmap() do huge-mappings as best-effort
>> by default. I am guessing this because ...
>>
>> Drivers can operate on individual pages, so vmalloc() calls split_page()
>> and then does the block/cont mappings. This same issue should be present
>> with vmap() too? In which case if we are to do huge-mappings by default
>> then we can do split_page() after detecting contiguous chunks.
>>
>> But ... that may create problems for the caller of vmap() - vmap now
>> has the changed the properties of the pages.
>
> I don’t see this as a problem at all. Splitting pages does not
> affect physical or virtual contiguity; it only changes the
> contents of struct page objects, not the PTE/PMD mappings.
> For ioremap, there isn’t even a struct page, yet the mappings
> can still be huge.
Okay so I was under the impression that *not* splitting the page
will be problematic.
But, vmalloc splits pages because the caller can operate on
individual struct pages by vmalloc_to_page(). To the contrary,
since the caller of vmap() decides what kind of pages to
virtually-map, we don't have the problem I was raising. So
I guess we are fine by making vmap do huge-mappings by default.
>
> Thanks
> Barry
^ permalink raw reply
* [PATCH v1 7/7] arm64: dts: freescale: imx95-verdin: Add Zinnia
From: Francesco Dolcini @ 2026-04-09 9:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo
Cc: Francesco Dolcini, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260409095855.61252-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Add Zinnia Carrier Board mated with Verdin iMX95.
It features 1 x RS232, 1 x RS485, 1 x CAN, 3 x isolated digital I/O,
2 x GBit/s Ethernet, a mini PCIe slot with USB / SIM card connector
for a modem, USB and SD card interfaces.
Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
arch/arm64/boot/dts/freescale/Makefile | 2 +
.../freescale/imx95-verdin-nonwifi-zinnia.dts | 21 +
.../freescale/imx95-verdin-wifi-zinnia.dts | 21 +
.../dts/freescale/imx95-verdin-zinnia.dtsi | 429 ++++++++++++++++++
4 files changed, 473 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-nonwifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-wifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-zinnia.dtsi
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index c14ccf24210a..870b9c9b869f 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -518,11 +518,13 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-nonwifi-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-nonwifi-ivy.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-nonwifi-mallow.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-nonwifi-yavia.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-nonwifi-zinnia.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-dahlia.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-ivy.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-mallow.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-yavia.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-zinnia.dtb
imx95-15x15-evk-pcie0-ep-dtbs = imx95-15x15-evk.dtb imx-pcie0-ep.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk-pcie0-ep.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx95-verdin-nonwifi-zinnia.dts b/arch/arm64/boot/dts/freescale/imx95-verdin-nonwifi-zinnia.dts
new file mode 100644
index 000000000000..b9fa18f34e9a
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-verdin-nonwifi-zinnia.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx95
+ * https://www.toradex.com/products/carrier-board/zinnia-carrier-board
+ */
+
+/dts-v1/;
+
+#include "imx95-verdin.dtsi"
+#include "imx95-verdin-nonwifi.dtsi"
+#include "imx95-verdin-zinnia.dtsi"
+
+/ {
+ model = "Toradex Verdin iMX95 on Zinnia Board";
+ compatible = "toradex,verdin-imx95-nonwifi-zinnia",
+ "toradex,verdin-imx95-nonwifi",
+ "toradex,verdin-imx95",
+ "fsl,imx95";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx95-verdin-wifi-zinnia.dts b/arch/arm64/boot/dts/freescale/imx95-verdin-wifi-zinnia.dts
new file mode 100644
index 000000000000..789614796370
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-verdin-wifi-zinnia.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx95
+ * https://www.toradex.com/products/carrier-board/zinnia-carrier-board
+ */
+
+/dts-v1/;
+
+#include "imx95-verdin.dtsi"
+#include "imx95-verdin-wifi.dtsi"
+#include "imx95-verdin-zinnia.dtsi"
+
+/ {
+ model = "Toradex Verdin iMX95 WB on Zinnia Board";
+ compatible = "toradex,verdin-imx95-wifi-zinnia",
+ "toradex,verdin-imx95-wifi",
+ "toradex,verdin-imx95",
+ "fsl,imx95";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx95-verdin-zinnia.dtsi b/arch/arm64/boot/dts/freescale/imx95-verdin-zinnia.dtsi
new file mode 100644
index 000000000000..6409a6ead713
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-verdin-zinnia.dtsi
@@ -0,0 +1,429 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * Common dtsi for Verdin iMX95 SoM on Zinnia carrier board
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx95
+ * https://www.toradex.com/products/carrier-board/zinnia-carrier-board
+ */
+
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/net/ti-dp83867.h>
+
+/ {
+ aliases {
+ eeprom1 = &carrier_eeprom;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_zinnia_leds>;
+
+ /* LED1 Red - SODIMM 48 - LED1_R */
+ led-1 {
+ color = <LED_COLOR_ID_RED>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <1>;
+ gpios = <&gpio5 7 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED1 Blue - SODIMM 46 - LED1_B */
+ led-2 {
+ color = <LED_COLOR_ID_BLUE>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <1>;
+ gpios = <&gpio5 4 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED3 Red - SODIMM 44 - LED3_R */
+ led-3 {
+ color = <LED_COLOR_ID_RED>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <3>;
+ gpios = <&gpio5 5 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED3 Green - SODIMM 54 - LED3_G */
+ led-4 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <3>;
+ gpios = <&gpio5 10 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED3 Blue - SODIMM 36 - LED3_B */
+ led-5 {
+ color = <LED_COLOR_ID_BLUE>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <3>;
+ gpios = <&gpio2 20 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED4 Red - SODIMM 34 - LED4_R */
+ led-6 {
+ color = <LED_COLOR_ID_RED>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <4>;
+ gpios = <&gpio2 21 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED4 Green - SODIMM 32 - LED4_G */
+ led-7 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <4>;
+ gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED4 Blue - SODIMM 30 - LED4_B */
+ led-8 {
+ color = <LED_COLOR_ID_BLUE>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <4>;
+ gpios = <&gpio2 16 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ /* Zinnia Power Supply Input Voltage */
+ zinnia-1v8-voltage {
+ compatible = "voltage-divider";
+ full-ohms = <39000>; /* 12k + 27k */
+ /* Verdin ADC_4 */
+ io-channels = <&adc1 3>;
+ output-ohms = <27000>;
+ };
+
+ zinnia-3v3-voltage {
+ compatible = "voltage-divider";
+ full-ohms = <54000>; /* 27k + 27k */
+ /* Verdin ADC_3 */
+ io-channels = <&adc1 2>;
+ output-ohms = <27000>;
+ };
+
+ zinnia-5v-voltage {
+ compatible = "voltage-divider";
+ full-ohms = <39000>; /* 27k + 12k */
+ /* Verdin ADC_2 */
+ io-channels = <&adc1 1>;
+ output-ohms = <12000>;
+ };
+
+ zinnia-input-voltage {
+ compatible = "voltage-divider";
+ full-ohms = <204700>; /* 200k + 4.7k */
+ /* Verdin ADC_1 */
+ io-channels = <&adc1 0>;
+ output-ohms = <4700>;
+ };
+};
+
+/* Verdin ADC_1, ADC_2, ADC_3 and ADC_4 */
+&adc1 {
+ status = "okay";
+};
+
+/* Verdin ETH_1 (On-module PHY) */
+&enetc_port0 {
+ status = "okay";
+};
+
+/* Verdin ETH_2_RGMII */
+&enetc_port1 {
+ phy-handle = <ðphy2>;
+ phy-mode = "rgmii-id";
+
+ status = "okay";
+};
+
+/* Verdin CAN_1 */
+&flexcan1 {
+ status = "okay";
+};
+
+&gpio1 {
+ gpio-line-names =
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "";
+};
+
+&gpio2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio1>, <&pinctrl_gpio2>, <&pinctrl_gpio3>;
+ gpio-line-names =
+ "DO1_EN", /* SODIMM 206 */ /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "DI1_EN", /* SODIMM 208 */
+ "",
+ "", /* 20 */
+ "",
+ "",
+ "",
+ "DI1_RB", /* SODIMM 210 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 30 */
+ "";
+};
+
+&gpio3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio6>;
+ gpio-line-names =
+ "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 20 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "DI2_EN", /* SODIMM 218 */
+ "",
+ "",
+ "", /* 30 */
+ "";
+};
+
+&gpio4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio5>;
+ gpio-line-names =
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 20 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "DI2_RB", /* SODIMM 216 */
+ "";
+};
+
+&gpio5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio4>, <&pinctrl_qspi1_io0_gpio>;
+ gpio-line-names =
+ "DI3_RB", /* SODIMM 56 */ /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "DO2_EN", /* SODIMM 212 */
+ "",
+ "",
+ "",
+ "",
+ "";
+};
+
+/* Verdin I2C_1 */
+&lpi2c4 {
+ status = "okay";
+
+ temperature-sensor@4f {
+ compatible = "ti,tmp1075";
+ reg = <0x4f>;
+ };
+
+ carrier_eeprom: eeprom@57 {
+ compatible = "st,24c02", "atmel,24c02";
+ reg = <0x57>;
+ pagesize = <16>;
+ };
+};
+
+/* Verdin SPI_1 */
+&lpspi6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi6>,
+ <&pinctrl_spi1_cs>,
+ <&pinctrl_uart8_cts_gpio>;
+ cs-gpios = <&gpio2 14 GPIO_ACTIVE_LOW>,
+ <&som_gpio_expander 13 GPIO_ACTIVE_LOW>,
+ <&gpio4 29 GPIO_ACTIVE_LOW>;
+
+ tpm@2 {
+ compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+ reg = <2>;
+ spi-max-frequency = <18500000>;
+ };
+};
+
+/* Verdin UART_3, used as the Linux console */
+&lpuart1 {
+ status = "okay";
+};
+
+/* Verdin UART_1 */
+&lpuart7 {
+ status = "okay";
+};
+
+/* Verdin UART_2, through RS485 transceiver */
+&lpuart8 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart8>, <&pinctrl_uart8_rts>;
+ rs485-rx-during-tx;
+ linux,rs485-enabled-at-boot-time;
+
+ status = "okay";
+};
+
+&netc_emdio {
+ ethphy2: ethernet-phy@2 {
+ reg = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_eth2_rgmii_int>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <12 IRQ_TYPE_LEVEL_LOW>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
+ };
+};
+
+&som_gpio_expander {
+ gpio-line-names =
+ "DO3_EN", /* SODIMM 220 */
+ "DI3_EN", /* SODIMM 222 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "";
+};
+
+/* Verdin USB_1 */
+&usb2 {
+ status = "okay";
+};
+
+/* Verdin USB_2 */
+&usb3 {
+ status = "okay";
+};
+
+&usb3_phy {
+ status = "okay";
+};
+
+/* Verdin SD_1 */
+&usdhc2 {
+ status = "okay";
+};
+
+&scmi_iomuxc {
+ pinctrl_uart8_cts_gpio: uart8ctsgrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO14__GPIO2_IO_BIT14 0x51e>; /* SODIMM 143 */
+ };
+
+ pinctrl_zinnia_leds: zinnialedsgrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO16__GPIO2_IO_BIT16 0x11e>, /* SODIMM 30 */
+ <IMX95_PAD_GPIO_IO26__GPIO2_IO_BIT26 0x11e>, /* SODIMM 32 */
+ <IMX95_PAD_GPIO_IO21__GPIO2_IO_BIT21 0x11e>, /* SODIMM 34 */
+ <IMX95_PAD_GPIO_IO20__GPIO2_IO_BIT20 0x11e>, /* SODIMM 36 */
+ <IMX95_PAD_XSPI1_DATA5__GPIO5_IO_BIT5 0x11e>, /* SODIMM 44 */
+ <IMX95_PAD_XSPI1_DATA4__GPIO5_IO_BIT4 0x11e>, /* SODIMM 46 */
+ <IMX95_PAD_XSPI1_DATA7__GPIO5_IO_BIT7 0x11e>, /* SODIMM 48 */
+ <IMX95_PAD_XSPI1_SS0_B__GPIO5_IO_BIT10 0x11e>; /* SODIMM 54 */
+ };
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v1 5/7] arm64: dts: freescale: imx8mp-verdin: Add Zinnia
From: Francesco Dolcini @ 2026-04-09 9:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo
Cc: Francesco Dolcini, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260409095855.61252-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Add Zinnia Carrier Board mated with Verdin iMX8M Plus.
It features 1 x RS232, 1 x RS485, 1 x CAN, 3 x isolated digital I/O,
2 x GBit/s Ethernet, a mini PCIe slot with USB / SIM card connector
for a modem, USB and SD card interfaces.
Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
arch/arm64/boot/dts/freescale/Makefile | 2 +
.../imx8mp-verdin-nonwifi-zinnia.dts | 21 +
.../freescale/imx8mp-verdin-wifi-zinnia.dts | 21 +
.../dts/freescale/imx8mp-verdin-zinnia.dtsi | 422 ++++++++++++++++++
4 files changed, 466 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-wifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-zinnia.dtsi
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 072df4128716..c14ccf24210a 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -347,11 +347,13 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-nonwifi-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-nonwifi-ivy.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-nonwifi-mallow.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-nonwifi-yavia.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-nonwifi-zinnia.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-wifi-dahlia.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-wifi-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-wifi-ivy.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-wifi-mallow.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-wifi-yavia.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-verdin-wifi-zinnia.dtb
imx8mp-evk-lvds0-imx-dlvds-hdmi-channel0-dtbs += imx8mp-evk.dtb imx8mp-evk-lvds0-imx-dlvds-hdmi-channel0.dtbo
imx8mp-evk-lvds0-imx-lvds-hdmi-dtbs += imx8mp-evk.dtb imx8mp-evk-lvds0-imx-lvds-hdmi.dtbo
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi-zinnia.dts b/arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi-zinnia.dts
new file mode 100644
index 000000000000..e78b25d65c94
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi-zinnia.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-plus
+ * https://www.toradex.com/products/carrier-board/zinnia-carrier-board
+ */
+
+/dts-v1/;
+
+#include "imx8mp-verdin.dtsi"
+#include "imx8mp-verdin-nonwifi.dtsi"
+#include "imx8mp-verdin-zinnia.dtsi"
+
+/ {
+ model = "Toradex Verdin iMX8M Plus on Zinnia";
+ compatible = "toradex,verdin-imx8mp-nonwifi-zinnia",
+ "toradex,verdin-imx8mp-nonwifi",
+ "toradex,verdin-imx8mp",
+ "fsl,imx8mp";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-verdin-wifi-zinnia.dts b/arch/arm64/boot/dts/freescale/imx8mp-verdin-wifi-zinnia.dts
new file mode 100644
index 000000000000..85eb56524314
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-verdin-wifi-zinnia.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-plus
+ * https://www.toradex.com/products/carrier-board/zinnia-carrier-board
+ */
+
+/dts-v1/;
+
+#include "imx8mp-verdin.dtsi"
+#include "imx8mp-verdin-wifi.dtsi"
+#include "imx8mp-verdin-zinnia.dtsi"
+
+/ {
+ model = "Toradex Verdin iMX8M Plus WB on Zinnia";
+ compatible = "toradex,verdin-imx8mp-wifi-zinnia",
+ "toradex,verdin-imx8mp-wifi",
+ "toradex,verdin-imx8mp",
+ "fsl,imx8mp";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-verdin-zinnia.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-verdin-zinnia.dtsi
new file mode 100644
index 000000000000..6beb2f2f4548
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-verdin-zinnia.dtsi
@@ -0,0 +1,422 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * Common dtsi for Verdin IMX8MP SoM on Zinnia carrier board
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-plus
+ * https://www.toradex.com/products/carrier-board/zinnia-carrier-board
+ */
+
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/net/ti-dp83867.h>
+
+/ {
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_zinnia_leds>;
+
+ /* LED1 Red - SODIMM 48 - LED1_R */
+ led-1 {
+ color = <LED_COLOR_ID_RED>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <1>;
+ gpios = <&gpio4 30 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED1 Blue - SODIMM 46 - LED1_B */
+ led-2 {
+ color = <LED_COLOR_ID_BLUE>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <1>;
+ gpios = <&gpio5 01 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED3 Red - SODIMM 44 - LED3_R */
+ led-3 {
+ color = <LED_COLOR_ID_RED>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <3>;
+ gpios = <&gpio4 31 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED3 Green - SODIMM 54 - LED3_G */
+ led-4 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <3>;
+ gpios = <&gpio3 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED3 Blue - SODIMM 36 - LED3_B */
+ led-5 {
+ color = <LED_COLOR_ID_BLUE>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <3>;
+ gpios = <&gpio4 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED4 Red - SODIMM 34 - LED4_R */
+ led-6 {
+ color = <LED_COLOR_ID_RED>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <4>;
+ gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED4 Green - SODIMM 32 - LED4_G */
+ led-7 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <4>;
+ gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED4 Blue - SODIMM 30 - LED4_B */
+ led-8 {
+ color = <LED_COLOR_ID_BLUE>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <4>;
+ gpios = <&gpio3 25 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ zinnia-1v8-voltage {
+ compatible = "voltage-divider";
+ full-ohms = <39000>; /* 12k + 27k */
+ /* Verdin ADC_4 */
+ io-channels = <&verdin_som_adc 4>;
+ output-ohms = <27000>;
+ };
+
+ zinnia-3v3-voltage {
+ compatible = "voltage-divider";
+ full-ohms = <54000>; /* 27k + 27k */
+ /* Verdin ADC_3 */
+ io-channels = <&verdin_som_adc 5>;
+ output-ohms = <27000>;
+ };
+
+ zinnia-5v-voltage {
+ compatible = "voltage-divider";
+ full-ohms = <39000>; /* 27k + 12k */
+ /* Verdin ADC_2 */
+ io-channels = <&verdin_som_adc 6>;
+ output-ohms = <12000>;
+ };
+
+ /* Zinnia Power Supply Input Voltage */
+ zinnia-input-voltage {
+ compatible = "voltage-divider";
+ full-ohms = <204700>; /* 200k + 4.7k */
+ /* Verdin ADC_1 */
+ io-channels = <&verdin_som_adc 7>;
+ output-ohms = <4700>;
+ };
+};
+
+/* Verdin SPI_1 */
+&ecspi1 {
+ pinctrl-0 = <&pinctrl_ecspi1>, <&pinctrl_uart2_cts_gpio>;
+ cs-gpios = <&gpio2 6 GPIO_ACTIVE_LOW>, <&gpio5 9 GPIO_ACTIVE_LOW>;
+
+ status = "okay";
+
+ tpm@1 {
+ compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+ reg = <1>;
+ spi-max-frequency = <18500000>;
+ };
+};
+
+/* EEPROM on Zinnia */
+&eeprom_carrier_board {
+ status = "okay";
+};
+
+/* Verdin ETH_1 */
+&eqos {
+ status = "okay";
+};
+
+/* Verdin ETH_2 */
+&fec {
+ phy-handle = <ðphy2>;
+ phy-mode = "rgmii-id";
+
+ status = "okay";
+};
+
+&verdin_eth2_mdio {
+ ethphy2: ethernet-phy@2 {
+ reg = <2>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <18 IRQ_TYPE_LEVEL_LOW>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
+ };
+};
+
+/* Verdin CAN_1 */
+&flexcan1 {
+ status = "okay";
+};
+
+&gpio1 {
+ gpio-line-names =
+ "DO1_EN", /* 0 */ /* SODIMM 206 */
+ "DI1_EN", /* SODIMM 208 */
+ "",
+ "",
+ "",
+ "DI1_RB", /* SODIMM 210 */
+ "DO2_EN", /* SODIMM 212 */
+ "DI2_RB", /* SODIMM 216 */
+ "DI2_EN", /* SODIMM 218 */
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 20 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "";
+};
+
+&gpio2 {
+ gpio-line-names =
+ "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ ""; /* 20 */
+};
+
+&gpio3 {
+ gpio-line-names =
+ "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "DI3_RB", /* SODIMM 56 */
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 20 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "";
+};
+
+&gpio4 {
+ gpio-line-names =
+ "", /* 0 */
+ "DI3_EN", /* SODIMM 222 */
+ "",
+ "DO3_EN", /* SODIMM 220 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 20 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 30 */
+ "";
+};
+
+&gpio5 {
+ gpio-line-names =
+ "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 20 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "";
+};
+
+/* Temperature sensor on Zinnia */
+&hwmon_temp {
+ compatible = "ti,tmp1075";
+
+ status = "okay";
+};
+
+/* Verdin I2C_1 */
+&i2c4 {
+ status = "okay";
+};
+
+/* Verdin UART_1 */
+&uart1 {
+ status = "okay";
+};
+
+/* Verdin UART_2 */
+&uart2 {
+ pinctrl-0 = <&pinctrl_uart2>, <&pinctrl_uart2_rts>;
+ linux,rs485-enabled-at-boot-time;
+ rs485-rx-during-tx;
+
+ status = "okay";
+};
+
+/* Verdin UART_3 */
+&uart3 {
+ status = "okay";
+};
+
+/* Verdin USB_1 */
+&usb3_0 {
+ status = "okay";
+};
+
+&usb3_phy0 {
+ status = "okay";
+};
+
+/* Verdin USB_2 */
+&usb3_1 {
+ status = "okay";
+};
+
+&usb3_phy1 {
+ status = "okay";
+};
+
+/* Verdin SD_1 */
+&usdhc2 {
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio1>,
+ <&pinctrl_gpio2>,
+ <&pinctrl_gpio3>,
+ <&pinctrl_gpio4>,
+ <&pinctrl_gpio5>,
+ <&pinctrl_gpio6>,
+ <&pinctrl_gpio7>,
+ <&pinctrl_gpio8>,
+ <&pinctrl_qspi1_io0_gpio>;
+
+ pinctrl_uart2_cts_gpio: gpio2io6grp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_DATA4__GPIO2_IO06 0x184>; /* SODIMM 143 */
+ };
+
+ pinctrl_qspi1_io0_gpio: gpio3io6grp {
+ fsl,pins = <MX8MP_IOMUXC_NAND_DATA00__GPIO3_IO06 0x184>; /* SODIMM 56 */
+ };
+
+ pinctrl_zinnia_leds: zinnialedsgrp {
+ fsl,pins =
+ <MX8MP_IOMUXC_SAI5_MCLK__GPIO3_IO25 0x16>, /* SODIMM 30 */
+ <MX8MP_IOMUXC_SAI5_RXD1__GPIO3_IO22 0x16>, /* SODIMM 32 */
+ <MX8MP_IOMUXC_SAI5_RXFS__GPIO3_IO19 0x16>, /* SODIMM 34 */
+ <MX8MP_IOMUXC_SAI1_RXD0__GPIO4_IO02 0x16>, /* SODIMM 36 */
+ <MX8MP_IOMUXC_SAI3_TXFS__GPIO4_IO31 0x16>, /* SODIMM 44 */
+ <MX8MP_IOMUXC_SAI3_TXD__GPIO5_IO01 0x16>, /* SODIMM 46 */
+ <MX8MP_IOMUXC_SAI3_RXD__GPIO4_IO30 0x16>, /* SODIMM 48 */
+ <MX8MP_IOMUXC_NAND_CE0_B__GPIO3_IO01 0x16>; /* SODIMM 54 */
+ };
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v1 4/7] arm64: dts: freescale: imx8mp-verdin: Split UART_2 pinctrl group
From: Francesco Dolcini @ 2026-04-09 9:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo
Cc: Francesco Dolcini, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260409095855.61252-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Some carrier board reuse the UART_2 control signals as GPIO, split
the pinctrl RTS/CTS in separated nodes to maximize flexibility.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi
index d31f8082394f..9fee2cf9ef54 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp-verdin.dtsi
@@ -846,7 +846,7 @@ &uart1 {
/* Verdin UART_2 */
&uart2 {
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart2>;
+ pinctrl-0 = <&pinctrl_uart2>, <&pinctrl_uart2_cts>, <&pinctrl_uart2_rts>;
uart-has-rtscts;
};
@@ -1277,10 +1277,18 @@ pinctrl_uart1: uart1grp {
<MX8MP_IOMUXC_UART1_TXD__UART1_DCE_TX 0x1c4>; /* SODIMM 131 */
};
+ pinctrl_uart2_cts: uart2ctsgrp {
+ fsl,pins =
+ <MX8MP_IOMUXC_SD1_DATA4__UART2_DCE_RTS 0x1c4>; /* SODIMM 143 */
+ };
+
+ pinctrl_uart2_rts: uart2rtsgrp {
+ fsl,pins =
+ <MX8MP_IOMUXC_SD1_DATA5__UART2_DCE_CTS 0x1c4>; /* SODIMM 141 */
+ };
+
pinctrl_uart2: uart2grp {
fsl,pins =
- <MX8MP_IOMUXC_SD1_DATA4__UART2_DCE_RTS 0x1c4>, /* SODIMM 143 */
- <MX8MP_IOMUXC_SD1_DATA5__UART2_DCE_CTS 0x1c4>, /* SODIMM 141 */
<MX8MP_IOMUXC_UART2_RXD__UART2_DCE_RX 0x1c4>, /* SODIMM 137 */
<MX8MP_IOMUXC_UART2_TXD__UART2_DCE_TX 0x1c4>; /* SODIMM 139 */
};
--
2.47.3
^ permalink raw reply related
* [PATCH v1 1/7] dt-bindings: arm: fsl: Add verdin imx8m[mp] and imx95 zinnia board
From: Francesco Dolcini @ 2026-04-09 9:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo
Cc: Francesco Dolcini, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260409095855.61252-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Add Toradex Verdin Zinnia carrier board mated with Verdin
iMX8M Plus, Verdin iMX8M Mini and Verdin iMX95.
Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 0023cd126807..f5429e6c86ff 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1025,6 +1025,7 @@ properties:
- toradex,verdin-imx8mm-nonwifi-ivy # Verdin iMX8M Mini Module on Ivy
- toradex,verdin-imx8mm-nonwifi-mallow # Verdin iMX8M Mini Module on Mallow
- toradex,verdin-imx8mm-nonwifi-yavia # Verdin iMX8M Mini Module on Yavia
+ - toradex,verdin-imx8mm-nonwifi-zinnia # Verdin iMX8M Mini Module on Zinnia
- const: toradex,verdin-imx8mm-nonwifi # Verdin iMX8M Mini Module without Wi-Fi / BT
- const: toradex,verdin-imx8mm # Verdin iMX8M Mini Module
- const: fsl,imx8mm
@@ -1037,6 +1038,7 @@ properties:
- toradex,verdin-imx8mm-wifi-ivy # Verdin iMX8M Mini Wi-Fi / BT Module on Ivy
- toradex,verdin-imx8mm-wifi-mallow # Verdin iMX8M Mini Wi-Fi / BT Module on Mallow
- toradex,verdin-imx8mm-wifi-yavia # Verdin iMX8M Mini Wi-Fi / BT Module on Yavia
+ - toradex,verdin-imx8mm-wifi-zinnia # Verdin iMX8M Mini Wi-Fi / BT Module on Zinnia
- const: toradex,verdin-imx8mm-wifi # Verdin iMX8M Mini Wi-Fi / BT Module
- const: toradex,verdin-imx8mm # Verdin iMX8M Mini Module
- const: fsl,imx8mm
@@ -1271,6 +1273,7 @@ properties:
- toradex,verdin-imx8mp-nonwifi-ivy # Verdin iMX8M Plus Module on Ivy
- toradex,verdin-imx8mp-nonwifi-mallow # Verdin iMX8M Plus Module on Mallow
- toradex,verdin-imx8mp-nonwifi-yavia # Verdin iMX8M Plus Module on Yavia
+ - toradex,verdin-imx8mp-nonwifi-zinnia # Verdin iMX8M Plus Module on Zinnia
- const: toradex,verdin-imx8mp-nonwifi # Verdin iMX8M Plus Module without Wi-Fi / BT
- const: toradex,verdin-imx8mp # Verdin iMX8M Plus Module
- const: fsl,imx8mp
@@ -1283,6 +1286,7 @@ properties:
- toradex,verdin-imx8mp-wifi-ivy # Verdin iMX8M Plus Wi-Fi / BT Module on Ivy
- toradex,verdin-imx8mp-wifi-mallow # Verdin iMX8M Plus Wi-Fi / BT Module on Mallow
- toradex,verdin-imx8mp-wifi-yavia # Verdin iMX8M Plus Wi-Fi / BT Module on Yavia
+ - toradex,verdin-imx8mp-wifi-zinnia # Verdin iMX8M Plus Wi-Fi / BT Module on Zinnia
- const: toradex,verdin-imx8mp-wifi # Verdin iMX8M Plus Wi-Fi / BT Module
- const: toradex,verdin-imx8mp # Verdin iMX8M Plus Module
- const: fsl,imx8mp
@@ -1515,6 +1519,7 @@ properties:
- toradex,verdin-imx95-nonwifi-ivy # Verdin iMX95 Module on Ivy
- toradex,verdin-imx95-nonwifi-mallow # Verdin iMX95 Module on Mallow
- toradex,verdin-imx95-nonwifi-yavia # Verdin iMX95 Module on Yavia
+ - toradex,verdin-imx95-nonwifi-zinnia # Verdin iMX95 Module on Zinnia
- const: toradex,verdin-imx95-nonwifi # Verdin iMX95 Module without Wi-Fi / BT
- const: toradex,verdin-imx95 # Verdin iMX95 Module
- const: fsl,imx95
@@ -1527,6 +1532,7 @@ properties:
- toradex,verdin-imx95-wifi-ivy # Verdin iMX95 Wi-Fi / BT Module on Ivy
- toradex,verdin-imx95-wifi-mallow # Verdin iMX95 Wi-Fi / BT Module on Mallow
- toradex,verdin-imx95-wifi-yavia # Verdin iMX95 Wi-Fi / BT Module on Yavia
+ - toradex,verdin-imx95-wifi-zinnia # Verdin iMX95 Wi-Fi / BT Module on Zinnia
- const: toradex,verdin-imx95-wifi # Verdin iMX95 Wi-Fi / BT Module
- const: toradex,verdin-imx95 # Verdin iMX95 Module
- const: fsl,imx95
--
2.47.3
^ permalink raw reply related
* [PATCH v1 3/7] arm64: dts: freescale: imx8mm-verdin: Add Zinnia
From: Francesco Dolcini @ 2026-04-09 9:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo
Cc: Francesco Dolcini, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260409095855.61252-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Add Zinnia Carrier Board mated with Verdin iMX8M Mini.
It features 1 x RS232, 1 x RS485, 1 x CAN, 3 x isolated digital I/O,
1 x GBit/s Ethernet, a mini PCIe slot with USB / SIM card connector
for a modem, USB and SD card interfaces.
Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
arch/arm64/boot/dts/freescale/Makefile | 2 +
.../imx8mm-verdin-nonwifi-zinnia.dts | 21 +
.../freescale/imx8mm-verdin-wifi-zinnia.dts | 21 +
.../dts/freescale/imx8mm-verdin-zinnia.dtsi | 383 ++++++++++++++++++
4 files changed, 427 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-nonwifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-wifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-zinnia.dtsi
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 711e36cc2c99..072df4128716 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -177,11 +177,13 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-nonwifi-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-nonwifi-ivy.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-nonwifi-mallow.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-nonwifi-yavia.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-nonwifi-zinnia.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-dahlia.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-ivy.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-mallow.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-yavia.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-verdin-wifi-zinnia.dtb
imx8mm-tqma8mqml-mba8mx-lvds-g133han01-dtbs += imx8mm-tqma8mqml-mba8mx.dtb imx8mm-tqma8mqml-mba8mx-lvds-g133han01.dtbo
imx8mm-tqma8mqml-mba8mx-lvds-tm070jvhg33-dtbs += imx8mm-tqma8mqml-mba8mx.dtb imx8mm-tqma8mqml-mba8mx-lvds-tm070jvhg33.dtbo
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin-nonwifi-zinnia.dts b/arch/arm64/boot/dts/freescale/imx8mm-verdin-nonwifi-zinnia.dts
new file mode 100644
index 000000000000..07b4daf916c2
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin-nonwifi-zinnia.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-mini-nano
+ * https://www.toradex.com/products/carrier-board/zinnia-carrier-board
+ */
+
+/dts-v1/;
+
+#include "imx8mm-verdin.dtsi"
+#include "imx8mm-verdin-nonwifi.dtsi"
+#include "imx8mm-verdin-zinnia.dtsi"
+
+/ {
+ model = "Toradex Verdin iMX8M Mini on Zinnia";
+ compatible = "toradex,verdin-imx8mm-nonwifi-zinnia",
+ "toradex,verdin-imx8mm-nonwifi",
+ "toradex,verdin-imx8mm",
+ "fsl,imx8mm";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin-wifi-zinnia.dts b/arch/arm64/boot/dts/freescale/imx8mm-verdin-wifi-zinnia.dts
new file mode 100644
index 000000000000..01a254dc1e6c
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin-wifi-zinnia.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-mini-nano
+ * https://www.toradex.com/products/carrier-board/zinnia-carrier-board
+ */
+
+/dts-v1/;
+
+#include "imx8mm-verdin.dtsi"
+#include "imx8mm-verdin-wifi.dtsi"
+#include "imx8mm-verdin-zinnia.dtsi"
+
+/ {
+ model = "Toradex Verdin iMX8M Mini WB on Zinnia";
+ compatible = "toradex,verdin-imx8mm-wifi-zinnia",
+ "toradex,verdin-imx8mm-wifi",
+ "toradex,verdin-imx8mm",
+ "fsl,imx8mm";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin-zinnia.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-verdin-zinnia.dtsi
new file mode 100644
index 000000000000..686486e03178
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin-zinnia.dtsi
@@ -0,0 +1,383 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * Common dtsi for Verdin IMX8MM SoM on Zinnia carrier board
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-mini-nano
+ * https://www.toradex.com/products/carrier-board/zinnia-carrier-board
+ */
+
+#include <dt-bindings/leds/common.h>
+
+/ {
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_zinnia_leds>;
+
+ /* LED1 Red - SODIMM 48 - LED1_R */
+ led-0 {
+ color = <LED_COLOR_ID_RED>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <1>;
+ gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED1 Blue - SODIMM 46 - LED1_B */
+ led-1 {
+ color = <LED_COLOR_ID_BLUE>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <1>;
+ gpios = <&gpio3 24 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED3 Red - SODIMM 44 - LED3_R */
+ led-2 {
+ color = <LED_COLOR_ID_RED>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <3>;
+ gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED3 Green - SODIMM 54 - LED3_G */
+ led-3 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <3>;
+ gpios = <&gpio3 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED3 Blue - SODIMM 36 - LED3_B */
+ led-4 {
+ color = <LED_COLOR_ID_BLUE>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <3>;
+ gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED4 Red - SODIMM 34 - LED4_R */
+ led-5 {
+ color = <LED_COLOR_ID_RED>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <4>;
+ gpios = <&gpio4 26 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED4 Green - SODIMM 32 - LED4_G */
+ led-6 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <4>;
+ gpios = <&gpio4 24 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED4 Blue - SODIMM 30 - LED4_B */
+ led-7 {
+ color = <LED_COLOR_ID_BLUE>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <4>;
+ gpios = <&gpio4 25 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ zinnia-1v8-voltage {
+ compatible = "voltage-divider";
+ full-ohms = <39000>; /* 12k + 27k */
+ /* Verdin ADC_4 */
+ io-channels = <&verdin_som_adc 4>;
+ output-ohms = <27000>;
+ };
+
+ zinnia-3v3-voltage {
+ compatible = "voltage-divider";
+ full-ohms = <54000>; /* 27k + 27k */
+ /* Verdin ADC_3 */
+ io-channels = <&verdin_som_adc 5>;
+ output-ohms = <27000>;
+ };
+
+ zinnia-5v-voltage {
+ compatible = "voltage-divider";
+ full-ohms = <39000>; /* 27k + 12k */
+ /* Verdin ADC_2 */
+ io-channels = <&verdin_som_adc 6>;
+ output-ohms = <12000>;
+ };
+
+ /* Zinnia Power Supply Input Voltage */
+ zinnia-input-voltage {
+ compatible = "voltage-divider";
+ full-ohms = <204700>; /* 200k + 4.7k */
+ /* Verdin ADC_1 */
+ io-channels = <&verdin_som_adc 7>;
+ output-ohms = <4700>;
+ };
+};
+
+/* Verdin SPI_1 */
+&ecspi2 {
+ pinctrl-0 = <&pinctrl_ecspi2>, <&pinctrl_uart3_cts_gpio>;
+ cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>, <&gpio5 13 GPIO_ACTIVE_LOW>;
+
+ status = "okay";
+
+ tpm@1 {
+ compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+ reg = <1>;
+ spi-max-frequency = <18500000>;
+ };
+};
+
+/* EEPROM on Zinnia */
+&eeprom_carrier_board {
+ status = "okay";
+};
+
+/* Verdin ETH_1 */
+&fec1 {
+ status = "okay";
+};
+
+&gpio1 {
+ gpio-line-names =
+ "DI2_RB", /* SODIMM 216 */ /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "DO3_EN", /* SODIMM 220 */
+ "DI3_EN", /* SODIMM 222 */
+ "", /* 10 */
+ "DI2_EN", /* SODIMM 218 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 20 */
+ "",
+ "",
+ "",
+ "",
+ "";
+};
+
+&gpio2 {
+ gpio-line-names =
+ "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ ""; /* 20 */
+};
+
+&gpio3 {
+ gpio-line-names =
+ "", /* 0 */
+ "",
+ "",
+ "",
+ "DO1_EN", /* SODIMM 206 */
+ "",
+ "DI3_RB", /* SODIMM 56 */
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 20 */
+ "",
+ "",
+ "",
+ "",
+ "";
+};
+
+&gpio4 {
+ gpio-line-names =
+ "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 20 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "";
+};
+
+&gpio5 {
+ gpio-line-names =
+ "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "DI1_EN", /* SODIMM 208 */
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 20 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "DI1_RB", /* SODIMM 210 */
+ "DO2_EN", /* SODIMM 212 */
+ "",
+ "";
+};
+
+/* Temperature sensor on Zinnia */
+&hwmon_temp {
+ compatible = "ti,tmp1075";
+
+ status = "okay";
+};
+
+/* Verdin I2C_1 */
+&i2c4 {
+ status = "okay";
+};
+
+/* Verdin UART_3 */
+&uart1 {
+ status = "okay";
+};
+
+/* Verdin UART_1 */
+&uart2 {
+ status = "okay";
+};
+
+/* Verdin UART_2 */
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>, <&pinctrl_uart3_rts>;
+ rs485-rx-during-tx;
+ linux,rs485-enabled-at-boot-time;
+
+ status = "okay";
+};
+
+/* Verdin USB_1 */
+&usbotg1 {
+ status = "okay";
+};
+
+/* Verdin USB_2 */
+&usbotg2 {
+ status = "okay";
+};
+
+/* Verdin SD_1 */
+&usdhc2 {
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio1>,
+ <&pinctrl_gpio2>,
+ <&pinctrl_gpio3>,
+ <&pinctrl_gpio4>,
+ <&pinctrl_gpio5>,
+ <&pinctrl_gpio6>,
+ <&pinctrl_gpio7>,
+ <&pinctrl_gpio8>,
+ <&pinctrl_qspi1_io0_gpio>;
+
+ pinctrl_qspi1_io0_gpio: gpio3io6grp {
+ fsl,pins = <MX8MM_IOMUXC_NAND_DATA00_GPIO3_IO6 0x184>; /* SODIMM 56 */
+ };
+
+ pinctrl_uart3_cts_gpio: gpio5io9grp {
+ fsl,pins = <MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9 0x184>; /* SODIMM 143 */
+ };
+
+ pinctrl_zinnia_leds: zinnialedsgrp {
+ fsl,pins =
+ <MX8MM_IOMUXC_SAI2_TXC_GPIO4_IO25 0x16>, /* SODIMM 30 */
+ <MX8MM_IOMUXC_SAI2_TXFS_GPIO4_IO24 0x16>, /* SODIMM 32 */
+ <MX8MM_IOMUXC_SAI2_TXD0_GPIO4_IO26 0x16>, /* SODIMM 34 */
+ <MX8MM_IOMUXC_SAI2_RXD0_GPIO4_IO23 0x16>, /* SODIMM 36 */
+ <MX8MM_IOMUXC_SAI5_RXD1_GPIO3_IO22 0x16>, /* SODIMM 44 */
+ <MX8MM_IOMUXC_SAI5_RXD3_GPIO3_IO24 0x16>, /* SODIMM 46 */
+ <MX8MM_IOMUXC_SAI5_RXD0_GPIO3_IO21 0x16>, /* SODIMM 48 */
+ <MX8MM_IOMUXC_NAND_CE0_B_GPIO3_IO1 0x16>; /* SODIMM 54 */
+ };
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v1 6/7] arm64: dts: freescale: imx95-verdin: Split UART_2 pinctrl group
From: Francesco Dolcini @ 2026-04-09 9:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo
Cc: Francesco Dolcini, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260409095855.61252-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Some carrier board reuse the UART_2 control signals as GPIO, split
the pinctrl RTS/CTS in separated nodes to maximize flexibility.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
.../arm64/boot/dts/freescale/imx95-verdin.dtsi | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx95-verdin.dtsi b/arch/arm64/boot/dts/freescale/imx95-verdin.dtsi
index d3737956e2f9..72e7f1e88409 100644
--- a/arch/arm64/boot/dts/freescale/imx95-verdin.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95-verdin.dtsi
@@ -541,7 +541,7 @@ &lpuart7 {
/* Verdin UART_2 */
&lpuart8 {
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart8>;
+ pinctrl-0 = <&pinctrl_uart8>, <&pinctrl_uart8_cts>, <&pinctrl_uart8_rts>;
uart-has-rtscts;
};
@@ -1058,12 +1058,20 @@ pinctrl_uart7: uart7grp {
<IMX95_PAD_GPIO_IO11__LPUART7_RTS_B 0x31e>; /* SODIMM 133 */
};
- /* Verdin UART_2 */
+ /* Verdin UART_2 CTS */
+ pinctrl_uart8_cts: uart8ctsgrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO14__LPUART8_CTS_B 0x31e>; /* SODIMM 143 */
+ };
+
+ /* Verdin UART_2 RTS */
+ pinctrl_uart8_rts: uart8rtsgrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO15__LPUART8_RTS_B 0x31e>; /* SODIMM 141 */
+ };
+
+ /* Verdin UART_2 RX/TX */
pinctrl_uart8: uart8grp {
fsl,pins = <IMX95_PAD_GPIO_IO12__LPUART8_TX 0x31e>, /* SODIMM 139 */
- <IMX95_PAD_GPIO_IO13__LPUART8_RX 0x31e>, /* SODIMM 137 */
- <IMX95_PAD_GPIO_IO14__LPUART8_CTS_B 0x31e>, /* SODIMM 143 */
- <IMX95_PAD_GPIO_IO15__LPUART8_RTS_B 0x31e>; /* SODIMM 141 */
+ <IMX95_PAD_GPIO_IO13__LPUART8_RX 0x31e>; /* SODIMM 137 */
};
/* On-module eMMC */
--
2.47.3
^ permalink raw reply related
* [PATCH v1 0/7] Add verdin imx8m[mp] and imx95 zinnia board
From: Francesco Dolcini @ 2026-04-09 9:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo
Cc: Francesco Dolcini, devicetree, linux-kernel, imx,
linux-arm-kernel
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Add Zinnia Carrier Board mated with Verdin iMX8M Plus, Verdin iMX8M Mini and
Verdin iMX95.
It features 1 x RS232, 1 x RS485, 1 x CAN, 3 x isolated digital I/O,
2 x 1GBit/s Ethernet, a mini PCIe slot with USB / SIM card connector
for a modem, USB and SD card interfaces.
Some small fixes and cleanup are done on the SOM dtsi file, in preparation
for the Zinnia addition.
Shawn, Frank: bindings/arm/fsl.yaml still list Shawn as maintainer, maybe
confirm that this is wanted.
Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board
Francesco Dolcini (7):
dt-bindings: arm: fsl: Add verdin imx8m[mp] and imx95 zinnia board
arm64: dts: freescale: imx8mm-verdin: Split UART_2 pinctrl group
arm64: dts: freescale: imx8mm-verdin: Add Zinnia
arm64: dts: freescale: imx8mp-verdin: Split UART_2 pinctrl group
arm64: dts: freescale: imx8mp-verdin: Add Zinnia
arm64: dts: freescale: imx95-verdin: Split UART_2 pinctrl group
arm64: dts: freescale: imx95-verdin: Add Zinnia
.../devicetree/bindings/arm/fsl.yaml | 6 +
arch/arm64/boot/dts/freescale/Makefile | 6 +
.../imx8mm-verdin-nonwifi-zinnia.dts | 21 +
.../freescale/imx8mm-verdin-wifi-zinnia.dts | 21 +
.../dts/freescale/imx8mm-verdin-zinnia.dtsi | 383 ++++++++++++++++
.../boot/dts/freescale/imx8mm-verdin.dtsi | 16 +-
.../imx8mp-verdin-nonwifi-zinnia.dts | 21 +
.../freescale/imx8mp-verdin-wifi-zinnia.dts | 21 +
.../dts/freescale/imx8mp-verdin-zinnia.dtsi | 422 +++++++++++++++++
.../boot/dts/freescale/imx8mp-verdin.dtsi | 14 +-
.../freescale/imx95-verdin-nonwifi-zinnia.dts | 21 +
.../freescale/imx95-verdin-wifi-zinnia.dts | 21 +
.../dts/freescale/imx95-verdin-zinnia.dtsi | 429 ++++++++++++++++++
.../boot/dts/freescale/imx95-verdin.dtsi | 18 +-
14 files changed, 1408 insertions(+), 12 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-nonwifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-wifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-verdin-zinnia.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-nonwifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-wifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-verdin-zinnia.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-nonwifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-wifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx95-verdin-zinnia.dtsi
--
2.47.3
^ permalink raw reply
* [PATCH v1 2/7] arm64: dts: freescale: imx8mm-verdin: Split UART_2 pinctrl group
From: Francesco Dolcini @ 2026-04-09 9:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo
Cc: Francesco Dolcini, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260409095855.61252-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Some carrier board reuse the UART_2 control signals as GPIO, split
the pinctrl RTS/CTS in separated nodes to maximize flexibility.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi
index 1594ce9182a5..5fc177f589cb 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi
@@ -735,7 +735,7 @@ &uart2 {
/* Verdin UART_2 */
&uart3 {
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart3>;
+ pinctrl-0 = <&pinctrl_uart3>, <&pinctrl_uart3_cts>, <&pinctrl_uart3_rts>;
uart-has-rtscts;
};
@@ -1144,12 +1144,20 @@ pinctrl_uart2: uart2grp {
<MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX 0x146>; /* SODIMM 129 */
};
+ pinctrl_uart3_cts: uart3ctsgrp {
+ fsl,pins =
+ <MX8MM_IOMUXC_ECSPI1_SS0_UART3_DCE_RTS_B 0x146>; /* SODIMM 143 */
+ };
+
+ pinctrl_uart3_rts: uart3rtsgrp {
+ fsl,pins =
+ <MX8MM_IOMUXC_ECSPI1_MISO_UART3_DCE_CTS_B 0x146>; /* SODIMM 141 */
+ };
+
pinctrl_uart3: uart3grp {
fsl,pins =
- <MX8MM_IOMUXC_ECSPI1_MISO_UART3_DCE_CTS_B 0x146>, /* SODIMM 141 */
<MX8MM_IOMUXC_ECSPI1_MOSI_UART3_DCE_TX 0x146>, /* SODIMM 139 */
- <MX8MM_IOMUXC_ECSPI1_SCLK_UART3_DCE_RX 0x146>, /* SODIMM 137 */
- <MX8MM_IOMUXC_ECSPI1_SS0_UART3_DCE_RTS_B 0x146>; /* SODIMM 143 */
+ <MX8MM_IOMUXC_ECSPI1_SCLK_UART3_DCE_RX 0x146>; /* SODIMM 137 */
};
pinctrl_uart4: uart4grp {
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
From: Kevin Brodsky @ 2026-04-09 9:53 UTC (permalink / raw)
To: Catalin Marinas, Ryan Roberts
Cc: Will Deacon, David Hildenbrand (Arm), Dev Jain, Yang Shi,
Suzuki K Poulose, Jinjiang Tu, linux-arm-kernel, linux-kernel,
stable
In-Reply-To: <adTh8d9k3y5ybemL@arm.com>
On 07/04/2026 12:52, Catalin Marinas wrote:
>> if we have forced pte mapping then the value of
>> can_set_direct_map() is irrelevant - we will never need to split because we are
>> already pte-mapped.
> can_set_direct_map() is used in other places, so its value is
> relevant, e.g. sys_memfd_secret() is rejected if this function returns
> false.
Indeed, I have noticed this before: currently set_direct_map_*_noflush()
and other functions will either fail or do nothing if none of the
features (rodata=full, etc.) is enabled, even if we would be able to
split the linear map using BBML2-noabort.
What would make more sense to me is to enable the use of BBML2-noabort
unconditionally if !force_pte_mapping(). We can then have
can_set_direct_map() return true if we have BBML2-noabort, and we no
longer need to check it in map_mem().
This is a functional change that doesn't have anything to do with realms
so it should probably be a separate series - happy to take care of it
once the dust settles on the realm handling.
- Kevin
^ permalink raw reply
* Re: [PATCH v1] phy: rockchip-snps-pcie3:phy: Configure clkreq_n and PowerDown for all lanes
From: Niklas Cassel @ 2026-04-09 9:49 UTC (permalink / raw)
To: Anand Moon, Shawn Lin
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner,
open list:GENERIC PHY FRAMEWORK,
moderated list:ARM/Rockchip SoC support,
open list:ARM/Rockchip SoC support, open list
In-Reply-To: <20260409044939.7647-1-linux.amoon@gmail.com>
+Shawn
Hello Anand,
On Thu, Apr 09, 2026 at 10:19:30AM +0530, Anand Moon wrote:
> During the rk3588_p3phy_init sequence, the driver now explicitly
Please use imperative mood, active voice.
> configures each lane's CON0 register to ensure
> - PIPE 4.3 Compliance: clkreq_n (bit 6) is forced low (asserted) to meet
> sideband signal requirements.
> - Active Power State: PowerDown[3:0] (bits 11:8) is set to P0
> (Normal Operational State) to ensure the PHY is fully powered and ready
> for link training.
>
> These changes ensure that all lanes are consistently transitioned from
> reset into a known-good operational state, preventing undefined behavior
> and ensuring the PHY is ready for high-speed data transmission.
First describe the problem, then describe how you fix it.
Kind regards,
Niklas
^ permalink raw reply
* Re: [PATCH v3 0/7] arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
From: Vignesh Raghavendra @ 2026-04-09 9:46 UTC (permalink / raw)
To: Rob Herring, Markus Schneider-Pargmann (TI)
Cc: Nishanth Menon, devicetree, Conor Dooley, Tero Kristo,
Mathieu Poirier, Dhruva Gole, Akashdeep Kaur, Kevin Hilman,
Bjorn Andersson, linux-remoteproc, linux-kernel, Kendall Willis,
Vishal Mahaveer, Sebin Francis, Krzysztof Kozlowski,
linux-arm-kernel
In-Reply-To: <CAL_JsqJq=3z7SQX_26MGGRcmysnGHVke8aTwyDCesvOuQjEN+g@mail.gmail.com>
Hi Markus
On 08/04/26 20:33, Rob Herring wrote:
> On Wed, Mar 18, 2026 at 10:14 AM Markus Schneider-Pargmann (TI)
> <msp@baylibre.com> wrote:
>>
>> Hi,
>>
>> Split the firmware memory region in more specific parts so it is better
>> described where which information is stored. Specifically the LPM metadata
>> region is important as bootloader software like U-Boot has to know where
>> that data is to be able to read that data and resume from RAM.
>>
>> IO+DDR is a deep sleep state in which a few pins are set to be sensitive
>> for wakeup while the DDR is kept in self refresh. Everything else is
>> powered off.
>>
>> The changes in this series were suggested as part of the IO+DDR u-boot series:
>> https://lore.kernel.org/r/814c211f-a9eb-4311-bb84-165b1a69755f@ti.com
>>
>> There are currently no real users of the memory-region that is split in
>> this series. The size of the memory-region in total stays the same.
>> The new layout is derived from the software running on the r5f
>> processor:
>> https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/examples/drivers/ipc/ipc_rpmsg_echo_linux/am62ax-sk/r5fss0-0_freertos/ti-arm-clang/linker.cmd#L172
>> https://github.com/TexasInstruments/mcupsdk-core-k3/blob/k3_main/source/drivers/device_manager/sciclient.h#L459
>>
>> Additionally the two important devicetree nodes for resuming from IO+DDR
>> have the bootph-pre-ram flag added as this data needs to be read before
>> the RAM is in use.
>>
>> Best
>> Markus
>>
>> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
>> ---
>> Changes in v3:
>> - Squash the enforcement of the memory-region-names requirement in the
>> patch adding the memory-region-names, as suggested.
>> - Link to v2: https://lore.kernel.org/r/20260312-topic-am62a-ioddr-dt-v6-19-v2-0-37cb7ceec658@baylibre.com
>>
>> Changes in v2:
>> - Make memory-region-names required if memory-region is present
>> - Fixup memory-region and memory-region-names conditions. Require either
>> 2 or 6 regions for memory-region and memory-region-names
>> - Reword and restructure the binding documentation for memory-region and
>> memory-region-names
>> - Add memory-region-names to all uses of memory-region
>> - Link to v1: https://lore.kernel.org/r/20260303-topic-am62a-ioddr-dt-v6-19-v1-0-12fe72bb40d2@baylibre.com
>>
>> ---
>> Markus Schneider-Pargmann (TI) (7):
>> dt-bindings: remoteproc: k3-r5f: Split up memory regions
>> dt-bindings: remoteproc: k3-r5f: Add memory-region-names
>> arm64: dts: ti: k3: Use memory-region-names for r5f
>> arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
>> arm64: dts: ti: k3-am62p5-sk: Split r5f memory region
>> arm64: dts: ti: k3-am62a7-sk: Add r5f nodes to pre-ram bootphase
>> arm64: dts: ti: k3-am62p5-sk: Add r5f nodes to pre-ram bootphase
>
> TI folks, Please make sure these dts patches are picked up for 7.1.
> There's now a crap load of warnings in next with the binding change:
>
> 58 (ti,am62-r5fss): r5f@78000000: 'memory-region-names' is a
> required property
[...]
> If they aren't applied, making 'memory-region-names' required needs
> to be dropped from the binding.
>
This breaks DT backward compatibility. Why is memory-region-names now a
required item and cannot be assumed as "dma" and "firmware" as default?
Is that intentional (should have at least had a Fixes tag then if the
original definition was wrong)?
--
Regards
Vignesh
https://ti.com/opensource
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
From: Suzuki K Poulose @ 2026-04-09 9:38 UTC (permalink / raw)
To: Catalin Marinas
Cc: Ryan Roberts, Will Deacon, David Hildenbrand (Arm), Dev Jain,
Yang Shi, Jinjiang Tu, Kevin Brodsky, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <adU9KxLC7yKgmyJy@arm.com>
On 07/04/2026 18:21, Catalin Marinas wrote:
> On Tue, Apr 07, 2026 at 10:57:35AM +0100, Suzuki K Poulose wrote:
>> On 02/04/2026 21:43, Catalin Marinas wrote:
>>> On Mon, Mar 30, 2026 at 05:17:02PM +0100, Ryan Roberts wrote:
>>>> int split_kernel_leaf_mapping(unsigned long start, unsigned long end)
>>>> {
>>>> int ret;
>>>> - /*
>>>> - * !BBML2_NOABORT systems should not be trying to change permissions on
>>>> - * anything that is not pte-mapped in the first place. Just return early
>>>> - * and let the permission change code raise a warning if not already
>>>> - * pte-mapped.
>>>> - */
>>>> - if (!system_supports_bbml2_noabort())
>>>> - return 0;
>>>> -
>>>> /*
>>>> * If the region is within a pte-mapped area, there is no need to try to
>>>> * split. Additionally, CONFIG_DEBUG_PAGEALLOC and CONFIG_KFENCE may
>>>> * change permissions from atomic context so for those cases (which are
>>>> * always pte-mapped), we must not go any further because taking the
>>>> - * mutex below may sleep.
>>>> + * mutex below may sleep. Do not call force_pte_mapping() here because
>>>> + * it could return a confusing result if called from a secondary cpu
>>>> + * prior to finalizing caps. Instead, linear_map_requires_bbml2 gives us
>>>> + * what we need.
>>>> */
>>>> - if (force_pte_mapping() || is_kfence_address((void *)start))
>>>> + if (!linear_map_requires_bbml2 || is_kfence_address((void *)start))
>>>> return 0;
>>>> + if (!system_supports_bbml2_noabort()) {
>>>> + /*
>>>> + * !BBML2_NOABORT systems should not be trying to change
>>>> + * permissions on anything that is not pte-mapped in the first
>>>> + * place. Just return early and let the permission change code
>>>> + * raise a warning if not already pte-mapped.
>>>> + */
>>>> + if (system_capabilities_finalized())
>>>> + return 0;
>>>> +
>>>> + /*
>>>> + * Boot-time: split_kernel_leaf_mapping_locked() allocates from
>>>> + * page allocator. Can't split until it's available.
>>>> + */
>>>> + if (WARN_ON(!page_alloc_available))
>>>> + return -EBUSY;
>>>> +
>>>> + /*
>>>> + * Boot-time: Started secondary cpus but don't know if they
>>>> + * support BBML2_NOABORT yet. Can't allow splitting in this
>>>> + * window in case they don't.
>>>> + */
>>>> + if (WARN_ON(num_online_cpus() > 1))
>>>> + return -EBUSY;
>>>> + }
>>>
>>> I think sashiko is over cautions here
>>> (https://sashiko.dev/#/patchset/20260330161705.3349825-1-ryan.roberts@arm.com)
>>> but it has a somewhat valid point from the perspective of
>>> num_online_cpus() semantics. We have have num_online_cpus() == 1 while
>>> having a secondary CPU just booted and with its MMU enabled. I don't
>>> think we can have any asynchronous tasks running at that point to
>>> trigger a spit though. Even async_init() is called after smp_init().
>>>
>>> An option may be to attempt cpus_read_trylock() as this lock is taken by
>>> _cpu_up(). If it fails, return -EBUSY, otherwise check num_online_cpus()
>>> and unlock (and return -EBUSY if secondaries already started).
>>>
>>> Another thing I couldn't get my head around - IIUC is_realm_world()
>>> won't return true for map_mem() yet (if in a realm).
>>
>> That is correct. map_mem() comes from paginig_init(), which gets called
>> before arm64_rsi_init(). Realm check was delayed until psci_xx_init().
>> We had a version which parsed the DT for PSCI conduit early enough
>> to be able to make the SMC calls to detect the Realm. But there
>> were concerns around it.
>
> Ah, yes, I remember.
>
> Does it mean that commit 42be24a4178f ("arm64: Enable memory encrypt for
> Realms") was broken without rodata=full w.r.t. the linear map? Commit
Apparently, it looks like we missed this when we demoted the RSI
detection later.
> a166563e7ec3 ("arm64: mm: support large block mapping when rodata=full")
> introduced force_pte_mapping() but it just copied the logic in the
> existing can_set_direct_map(). Looking at the linear_map_requires_bbml2
> assignment, we get (!is_realm_world() && is_realm_world()) and it
> cancels out, no effect on it but we don't get pte mappings either (even
> if we don't have BBML2).
Yep, that's right.
>
> I think we need at least some safety checks:
>
> 1. BBML2_NOABORT support on the boot CPU - continue with the existing
> logic (as per Ryan's series)
>
> 2. !system_supports_bbml2_noabort() - split in
> linear_map_maybe_split_to_ptes(). This does not currently happen
> because linear_map_requires_bbml2 may be false in the absence of
> rodata=full. Not sure how to fix this without some variable telling
> us how the linear map was mapped. The requires_bbml2 flag doesn't
>
> 3. Panic in arm64_rsi_init() if !BBML2_NOABORT on the boot CPU _and_ we
> have block mappings already. People can avoid it with rodata=full
It looks like this will be a common case :-(
>
> 4. If (3) is a common case, a better alternative is to rewrite the
> linear map sometime after arm64_rsi_init() but before we call
> split_kernel_leaf_mapping().
We will explore this route.
The other option is to move the RSI detection (and the PSCI probe)
earlier to be able to make better decisions early on. I will play with
that a bit too.
Suzuki
>
^ permalink raw reply
* [PATCH v1] arm64: dts: freescale: imx95-verdin-ivy: fix RS485 RTS polarity
From: Francesco Dolcini @ 2026-04-09 9:33 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Francesco Dolcini, devicetree, imx, linux-arm-kernel,
linux-kernel
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Fix the RS485 functionality, the RS485 RTS signal is active high on Ivy.
Fixes: f33a1f9a942c ("arm64: dts: freescale: imx95-verdin: Add Ivy carrier board")
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
arch/arm64/boot/dts/freescale/imx95-verdin-ivy.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx95-verdin-ivy.dtsi b/arch/arm64/boot/dts/freescale/imx95-verdin-ivy.dtsi
index 8337c8b25f05..ff31f7c48cfb 100644
--- a/arch/arm64/boot/dts/freescale/imx95-verdin-ivy.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95-verdin-ivy.dtsi
@@ -452,7 +452,6 @@ &lpuart7 {
/* Verdin UART_2, through RS485 transceiver */
&lpuart8 {
- rs485-rts-active-low;
rs485-rx-during-tx;
linux,rs485-enabled-at-boot-time;
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] clk: clk-imx8mm: Initialize clocks in arch_initcall
From: Paul Geurts @ 2026-04-09 9:29 UTC (permalink / raw)
To: peng.fan
Cc: abelvesa, mturquette, sboyd, Frank.Li, s.hauer, kernel, festevam,
shawnguo, linux-clk, imx, linux-arm-kernel, linux-kernel,
martijn.de.gouw, paul.geurts
In-Reply-To: <addMdwvnDkCMJxhx@shlinux89>
> On Wed, Apr 08, 2026 at 12:13:13PM +0200, Paul Geurts wrote:
> >The i.MX8MM clock driver is implemented as module_platform_driver();,
> >which makes it initialize in device_initcall(). This means that all
> >drivers referencing the clock driver nodes in the device tree are
> >deferred by fw_devlink, which are most of the i.MX8M platform drivers.
> >
> >Explicitly initialize the clock driver in arch_initcall(), to make sure
> >the clock driver is ready when the rest of the drivers are probed.
>
> Let's keep as it is, changing to arch_initcall() is not allowed.
Why is it not allowed? This is an arch driver, so I think it should be
initialized in arch? I don't think the initcall system was intended to
initialize everything in late_initcall, which is effectively what this
problem is causing.
>
> Thanks,
> Peng
Thanks!
Paul
^ permalink raw reply
* Re: [PATCH] clk: clk-imx8mm: Initialize clocks in arch_initcall
From: Paul Geurts @ 2026-04-09 9:16 UTC (permalink / raw)
To: abelvesa, peng.fan, mturquette, sboyd, Frank.Li, s.hauer, kernel,
festevam, shawnguo, linux-clk, imx, linux-arm-kernel,
linux-kernel
Cc: martijn.de.gouw
In-Reply-To: <9f36af74-ef1a-4777-a1c3-ff13b68c2221@pengutronix.de>
> Hello Paul,
>
> On 4/8/26 12:13 PM, Paul Geurts wrote:
> > The i.MX8MM clock driver is implemented as module_platform_driver();,
> > which makes it initialize in device_initcall(). This means that all
> > drivers referencing the clock driver nodes in the device tree are
> > deferred by fw_devlink, which are most of the i.MX8M platform drivers.
> >
> > Explicitly initialize the clock driver in arch_initcall(), to make sure
> > the clock driver is ready when the rest of the drivers are probed.
> >
> > Fixes: af7e7ee0e428 ("clk: imx8mm: Switch to platform driver")
>
> Your commit message doesn't explain why this was a problem for you.
> Does it delay your boot? What makes this patch a fix?
Yes I could update that in the commit description. The problem is that because
of this, _all_ hardware is initialized in late_initcall, as that is where
deferred probes are handled. For embedded devices, some sign of life is
expected by most people during boot. Especially when an initrd needs to be
unpacked, this sign of life is going to take a very long time. Some display
controllers don't even get enough time to show the boot logo because of this.
I don't think the idea behind the initcall levels is that _everything_ is
initialized in late.
>
> > Signed-off-by: Paul Geurts <paul.geurts@prodrive-technologies.com>
> > ---
> > drivers/clk/imx/clk-imx8mm.c | 14 +++++++++++++-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
> > index 319af4deec01..7b2cf867b920 100644
> > --- a/drivers/clk/imx/clk-imx8mm.c
> > +++ b/drivers/clk/imx/clk-imx8mm.c
> > @@ -636,7 +636,19 @@ static struct platform_driver imx8mm_clk_driver = {
> > .of_match_table = imx8mm_clk_of_match,
> > },
> > };
> > -module_platform_driver(imx8mm_clk_driver);
> > +
> > +static int __init imx8mm_clk_init(void)
> > +{
> > + return platform_driver_register(&imx8mm_clk_driver);
> > +}
> > +arch_initcall(imx8mm_clk_init);
>
> What happens if you build the driver as module with your changes applied?
On module insertion, there is no initcall level, and initialization is
performed on insertion (AFAIK). Fact is that the system would probably
not boot when this is built as a module, as there are no peripheral clocks
without it.
>
> Cheers,
> Ahmad
>
> > +
> > +static void __exit imx8mm_clk_exit(void)
> > +{
> > + platform_driver_unregister(&imx8mm_clk_driver);
> > +}
> > +module_exit(imx8mm_clk_exit);
> > +
> > module_param(mcore_booted, bool, S_IRUGO);
> > MODULE_PARM_DESC(mcore_booted, "See Cortex-M core is booted or not");
> >
Thanks!
Paul
^ permalink raw reply
* [PATCH v2] arm64: dts: imx{91,93}-phyboard-segin: Add peb-av-18 overlays
From: Florijan Plohl @ 2026-04-09 9:01 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: imx, linux-arm-kernel, devicetree, linux-kernel, upstream
Add overlay for the PHYTEC Audio/Video adapter module PEB-AV-18 on
phyBOARD-Segin-i.MX91/93 boards. The supported AC220 display is
Powertip PH800480T032-ZHC19 panel with a backlight and Ilitek
touch-screen controller.
Signed-off-by: Florijan Plohl <florijan.plohl@norik.com>
---
Changes in v2:
- Link to v1: https://lore.kernel.org/all/20260402070826.970012-1-florijan.plohl@norik.com/
- Improve commit message to clarify what PEB-AV-18 is
- Move imx91-phyboard-segin-peb-av-18 dtb entry next to
the other imx91 phyboard-segin definition in Makefile
- Introduce common imx91-93-phyboard-segin-peb-av-18.dtsi
- Adjust drive-strength values
arch/arm64/boot/dts/freescale/Makefile | 6 ++
.../imx91-93-phyboard-segin-peb-av-18.dtsi | 93 +++++++++++++++++++
.../imx91-phyboard-segin-peb-av-18.dtso | 57 ++++++++++++
.../imx93-phyboard-segin-peb-av-18.dtso | 57 ++++++++++++
4 files changed, 213 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx91-93-phyboard-segin-peb-av-18.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index bae24b53bce6..574960280744 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -416,6 +416,10 @@ dtb-$(CONFIG_ARCH_MXC) += imx91-11x11-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx91-11x11-frdm.dtb
dtb-$(CONFIG_ARCH_MXC) += imx91-11x11-frdm-s.dtb
dtb-$(CONFIG_ARCH_MXC) += imx91-phyboard-segin.dtb
+
+imx91-phyboard-segin-peb-av-18-dtbs += imx91-phyboard-segin.dtb imx91-phyboard-segin-peb-av-18.dtbo
+dtb-$(CONFIG_ARCH_MXC) += imx91-phyboard-segin-peb-av-18.dtb
+
dtb-$(CONFIG_ARCH_MXC) += imx91-tqma9131-mba91xxca.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb.dtb
@@ -441,6 +445,7 @@ imx93-phyboard-nash-jtag-dtbs += imx93-phyboard-nash.dtb imx93-phyboard-nash-jta
imx93-phyboard-nash-peb-wlbt-07-dtbs += imx93-phyboard-nash.dtb imx93-phyboard-nash-peb-wlbt-07.dtbo
imx93-phyboard-nash-pwm-fan-dtbs += imx93-phyboard-nash.dtb imx93-phyboard-nash-pwm-fan.dtbo
imx93-phyboard-segin-peb-av-02-dtbs += imx93-phyboard-segin.dtb imx93-phyboard-segin-peb-av-02.dtbo
+imx93-phyboard-segin-peb-av-18-dtbs += imx93-phyboard-segin.dtb imx93-phyboard-segin-peb-av-18.dtbo
imx93-phyboard-segin-peb-eval-01-dtbs += imx93-phyboard-segin.dtb imx93-phyboard-segin-peb-eval-01.dtbo
imx93-phyboard-segin-peb-wlbt-05-dtbs += imx93-phyboard-segin.dtb imx93-phyboard-segin-peb-wlbt-05.dtbo
imx93-phycore-rpmsg-dtbs += imx93-phyboard-nash.dtb imx93-phyboard-segin.dtb imx93-phycore-rpmsg.dtbo
@@ -448,6 +453,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-nash-jtag.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-nash-peb-wlbt-07.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-nash-pwm-fan.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin-peb-av-02.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin-peb-av-18.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin-peb-eval-01.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phyboard-segin-peb-wlbt-05.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-phycore-rpmsg.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx91-93-phyboard-segin-peb-av-18.dtsi b/arch/arm64/boot/dts/freescale/imx91-93-phyboard-segin-peb-av-18.dtsi
new file mode 100644
index 000000000000..53d5cbcd798b
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx91-93-phyboard-segin-peb-av-18.dtsi
@@ -0,0 +1,93 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2026 PHYTEC Messtechnik GmbH
+ *
+ * Author: Florijan Plohl <florijan.plohl@norik.com>
+ */
+
+#include <dt-bindings/clock/imx93-clock.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/dts-v1/;
+/plugin/;
+
+&{/} {
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <5>;
+ power-supply = <®_vcc_3v3_con>;
+ pwms = <&pwm7 0 5000000 0>;
+ };
+
+ panel {
+ compatible = "powertip,ph800480t032-zhc19";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_panel>;
+
+ backlight = <&backlight>;
+ enable-gpios = <&gpio4 29 GPIO_ACTIVE_HIGH>;
+ power-supply = <®_vcc_3v3_con>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dpi_to_panel>;
+ };
+ };
+ };
+
+ pwm7: pwm-7 {
+ compatible = "pwm-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm7>;
+ gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>;
+ #pwm-cells = <3>;
+ };
+
+ reg_vcc_3v3_con: regulator-vcc-3v3-con {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC3V3_CON";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ };
+};
+
+&dpi_bridge {
+ status = "okay";
+};
+
+&dpi_to_panel {
+ remote-endpoint = <&panel_in>;
+ bus-width = <18>;
+};
+
+&lcdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcdif>;
+ assigned-clocks = <&clk IMX93_CLK_VIDEO_PLL>;
+ assigned-clock-rates = <27272728>;
+ status = "okay";
+};
+
+&lpi2c2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@41 {
+ compatible = "ilitek,ili2130";
+ reg = <0x41>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_touchscreen>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&gpio4 1 GPIO_ACTIVE_LOW>;
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ wakeup-source;
+ };
+};
+
+&media_blk_ctrl {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso b/arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso
new file mode 100644
index 000000000000..35edf9b0fb0f
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx91-phyboard-segin-peb-av-18.dtso
@@ -0,0 +1,57 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2026 PHYTEC Messtechnik GmbH
+ *
+ * Author: Florijan Plohl <florijan.plohl@norik.com>
+ */
+
+#include "imx91-pinfunc.h"
+#include "imx91-93-phyboard-segin-peb-av-18.dtsi"
+
+&iomuxc {
+ pinctrl_lcdif: lcdifgrp {
+ fsl,pins = <
+ MX91_PAD_GPIO_IO00__MEDIAMIX_DISP_CLK 0x57e
+ MX91_PAD_GPIO_IO01__MEDIAMIX_DISP_DE 0x51e
+ MX91_PAD_GPIO_IO02__MEDIAMIX_DISP_VSYNC 0x51e
+ MX91_PAD_GPIO_IO03__MEDIAMIX_DISP_HSYNC 0x51e
+ MX91_PAD_GPIO_IO04__MEDIAMIX_DISP_DATA0 0x51e
+ MX91_PAD_GPIO_IO05__MEDIAMIX_DISP_DATA1 0x51e
+ MX91_PAD_GPIO_IO06__MEDIAMIX_DISP_DATA2 0x51e
+ MX91_PAD_GPIO_IO07__MEDIAMIX_DISP_DATA3 0x51e
+ MX91_PAD_GPIO_IO08__MEDIAMIX_DISP_DATA4 0x51e
+ MX91_PAD_GPIO_IO09__MEDIAMIX_DISP_DATA5 0x51e
+ MX91_PAD_GPIO_IO10__MEDIAMIX_DISP_DATA6 0x51e
+ MX91_PAD_GPIO_IO11__MEDIAMIX_DISP_DATA7 0x51e
+ MX91_PAD_GPIO_IO12__MEDIAMIX_DISP_DATA8 0x51e
+ MX91_PAD_GPIO_IO13__MEDIAMIX_DISP_DATA9 0x51e
+ MX91_PAD_GPIO_IO14__MEDIAMIX_DISP_DATA10 0x51e
+ MX91_PAD_GPIO_IO15__MEDIAMIX_DISP_DATA11 0x51e
+ MX91_PAD_GPIO_IO16__MEDIAMIX_DISP_DATA12 0x51e
+ MX91_PAD_GPIO_IO17__MEDIAMIX_DISP_DATA13 0x51e
+ MX91_PAD_GPIO_IO18__MEDIAMIX_DISP_DATA14 0x51e
+ MX91_PAD_GPIO_IO19__MEDIAMIX_DISP_DATA15 0x51e
+ MX91_PAD_GPIO_IO20__MEDIAMIX_DISP_DATA16 0x51e
+ MX91_PAD_GPIO_IO21__MEDIAMIX_DISP_DATA17 0x51e
+ >;
+ };
+
+ pinctrl_panel: panelgrp {
+ fsl,pins = <
+ MX91_PAD_CCM_CLKO4__GPIO4_IO29 0x1133e
+ >;
+ };
+
+ pinctrl_pwm7: pwm7grp {
+ fsl,pins = <
+ MX91_PAD_CCM_CLKO3__GPIO4_IO28 0x1133e
+ >;
+ };
+
+ pinctrl_touchscreen: touchscreengrp {
+ fsl,pins = <
+ MX91_PAD_ENET1_MDIO__GPIO4_IO1 0x11e
+ MX91_PAD_ENET1_RD2__GPIO4_IO12 0x1133e
+ >;
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso b/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso
new file mode 100644
index 000000000000..11f7d7502be4
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-phyboard-segin-peb-av-18.dtso
@@ -0,0 +1,57 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2026 PHYTEC Messtechnik GmbH
+ *
+ * Author: Florijan Plohl <florijan.plohl@norik.com>
+ */
+
+#include "imx93-pinfunc.h"
+#include "imx91-93-phyboard-segin-peb-av-18.dtsi"
+
+&iomuxc {
+ pinctrl_lcdif: lcdifgrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO00__MEDIAMIX_DISP_CLK 0x57e
+ MX93_PAD_GPIO_IO02__MEDIAMIX_DISP_VSYNC 0x51e
+ MX93_PAD_GPIO_IO01__MEDIAMIX_DISP_DE 0x51e
+ MX93_PAD_GPIO_IO03__MEDIAMIX_DISP_HSYNC 0x51e
+ MX93_PAD_GPIO_IO04__MEDIAMIX_DISP_DATA00 0x51e
+ MX93_PAD_GPIO_IO05__MEDIAMIX_DISP_DATA01 0x51e
+ MX93_PAD_GPIO_IO06__MEDIAMIX_DISP_DATA02 0x51e
+ MX93_PAD_GPIO_IO07__MEDIAMIX_DISP_DATA03 0x51e
+ MX93_PAD_GPIO_IO08__MEDIAMIX_DISP_DATA04 0x51e
+ MX93_PAD_GPIO_IO09__MEDIAMIX_DISP_DATA05 0x51e
+ MX93_PAD_GPIO_IO10__MEDIAMIX_DISP_DATA06 0x51e
+ MX93_PAD_GPIO_IO11__MEDIAMIX_DISP_DATA07 0x51e
+ MX93_PAD_GPIO_IO12__MEDIAMIX_DISP_DATA08 0x51e
+ MX93_PAD_GPIO_IO13__MEDIAMIX_DISP_DATA09 0x51e
+ MX93_PAD_GPIO_IO14__MEDIAMIX_DISP_DATA10 0x51e
+ MX93_PAD_GPIO_IO15__MEDIAMIX_DISP_DATA11 0x51e
+ MX93_PAD_GPIO_IO16__MEDIAMIX_DISP_DATA12 0x51e
+ MX93_PAD_GPIO_IO17__MEDIAMIX_DISP_DATA13 0x51e
+ MX93_PAD_GPIO_IO18__MEDIAMIX_DISP_DATA14 0x51e
+ MX93_PAD_GPIO_IO19__MEDIAMIX_DISP_DATA15 0x51e
+ MX93_PAD_GPIO_IO20__MEDIAMIX_DISP_DATA16 0x51e
+ MX93_PAD_GPIO_IO21__MEDIAMIX_DISP_DATA17 0x51e
+ >;
+ };
+
+ pinctrl_panel: panelgrp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO4__GPIO4_IO29 0x1133e
+ >;
+ };
+
+ pinctrl_pwm7: pwm7grp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO3__GPIO4_IO28 0x1133e
+ >;
+ };
+
+ pinctrl_touchscreen: touchscreengrp {
+ fsl,pins = <
+ MX93_PAD_ENET1_MDIO__GPIO4_IO01 0x11e
+ MX93_PAD_ENET1_RD2__GPIO4_IO12 0x1133e
+ >;
+ };
+};
--
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