* Re: [PATCH v3 1/4] dt-bindings: usb: dwc3-xilinx: Add MMI USB support on Versal Gen2 platform
From: Pandey, Radhey Shyam @ 2026-05-20 11:55 UTC (permalink / raw)
To: Krzysztof Kozlowski, Radhey Shyam Pandey
Cc: gregkh, robh, krzk+dt, conor+dt, michal.simek, Thinh.Nguyen,
p.zabel, linux-usb, devicetree, linux-arm-kernel, linux-kernel,
git
In-Reply-To: <a51d0e53-3134-475d-a19f-67d7d0695cfe@kernel.org>
On 5/14/2026 9:30 PM, Krzysztof Kozlowski wrote:
> On 07/05/2026 21:01, Pandey, Radhey Shyam wrote:
>>> On Wed, Apr 29, 2026 at 11:00:47PM +0530, Radhey Shyam Pandey wrote:
>>>> additionalProperties: false
>>>>
>>>> examples:
>>>> @@ -156,3 +193,30 @@ examples:
>>>> };
>>>> };
>>>> };
>>>> + - |
>>>> + #include <dt-bindings/power/xlnx-zynqmp-power.h>
>>>> + #include <dt-bindings/reset/xlnx-zynqmp-resets.h>
>>>> + #include <dt-bindings/phy/phy.h>
>>>> + usb {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <1>;
>>> Please follow DTS coding style.
>> Thanks for the review. will fix it in next version.
>>>> + compatible = "xlnx,versal2-mmi-dwc3";
>>> I really doubt that DWC3 block comes without addressing space
>>> (registers), so either you just misrepresented things, like created a
>>> fake block and syscon, or forgot to combine DWC3 with the wrapper.
>>>
>>> And if you built with W=1 your DTS you would see errors. How do you see
>>> it now? Where do you place it? Wrapper must be outside of soc, but DWC3
>>> child must be inside. Did you read submitting patches and writing
>>> bindings documents?
>> Apologies for missing the DTS sanity check earlier. I am summarizing the
>> problem statement and possible solution. Please review.
>>
>> For MMI USB in current implementation it need a parent/child
>> representation. However, the parent IP is shared across DP, USB,
>> and HDCP, so it cannot have a USB-dedicated parent reg space.
>>
>> 1. Versal platform
>> - Parent: USB wrapper IP → has its own I/O space
>> - Child: USB DWC3
>>
>> 2. Versal Gen2 platform - MMI USB
>> - Parent subsystem combines DP, USB, and HDCP in a single I/O space
>> - Children:
>> - USB DWC3
>> - DP
>> - HDCP
>>
>> To model the Versal Gen2 MMI USB parent register space, I introduced
>> xlnx,usb-syscon, allowing the DWC3 driver to access parent registers
>> via a syscon handle, addressing the v1 review comment.
>
> Syscon phandle is not to express such relationsship.
>
>>
>> However, making reg optional satisfies schema validation but fails
>> DTB checks.
>>
>> versal2.dtsi:1: Warning (simple_bus_reg):
>> /axi/mmi-usb: missing or empty reg/ranges property
>
> Yep, exactly.
>
>>
>> To fix it i think we can switch from parent/child representation to
>> flat DT representation for the Versal Gen2 platform, similar to
>> existing implementations in qcom,snps-dwc3 and Google Tensor G5 DWC3
>> bindings[1].
>>
>> The Google Tensor DWC3 binding uses a syscon phandle to access USB
>> configuration registers, which aligns well with the Versal Gen2 MMI
>
> Not true. Just read the binding. If you refer to Tensor, then to access
> A FEW configuration registers. If you refer to LGA, then it has address
> space.
>
>> USB IP, where wrapper subsystem shares a common register space for
>> USB along with other IPs.
>
>
>
>>
>> If this approach looks fine , will create binding for MMI USB using
>> this flat representation and send out next version.
>>
>> usb@fe200000 {
>> compatible = "xlnx,versal2-mmi-dwc3";
>> reg = <0xfe200000 0x40000>;
>> xlnx,usb-syscon = <&udh_slcr 0x005c 0x0070 0x00c4 0x00f8>;
>> <snip>
>> };
>
> So I am confused. We ask, since long time, to have unified child.
> Several platforms were already converted. What are you discussing with
> in such case?
>
> Are you going to have unified node or not?
>
Yes, in next version will switch to a unified node representation for
Versal Gen2 MMI USB.
Based on your feedback:
-the fake wrapper hierarchy will be removed.
-parent node without reg will be dropped.
-syscon will not be used to model hierarchy.
Instead, I will introduce a separate unified-node binding for Versal
Gen2 MMI USB where: the USB controller register space is described
directly in the USB node, auxiliary USB configuration registers in
UDH SLCR are accessed through a syscon phandle only for sideband
configuration access.
New DT representation using single unified node.
usb@0xedec0000 {
compatible = "xlnx,versal2-mmi-dwc3", "snps,dwc3";
reg = <...>;
xlnx,usb-syscon = <&udh_slcr>;
<snip>
};
Thanks,
Radhey
^ permalink raw reply
* Re: [PATCH v02] mailbox: pcc: report errors for PCC clients
From: lihuisong (C) @ 2026-05-20 11:53 UTC (permalink / raw)
To: Sudeep Holla
Cc: Adam Young, Jassi Brar, linux-kernel, linux-hwmon,
Rafael J . Wysocki, Len Brown, linux-acpi, Andi Shyti,
Guenter Roeck, MyungJoo Ham, Kyungmin Park, Chanwoo Choi,
linux-arm-kernel
In-Reply-To: <20260519-outgoing-rough-fox-04daab@sudeepholla>
On 5/20/2026 12:25 AM, Sudeep Holla wrote:
> On Tue, May 19, 2026 at 09:54:47PM +0800, lihuisong (C) wrote:
>> On 5/19/2026 3:30 AM, Adam Young wrote:
>>> The tx_done callback function has a return code (rc) parameter
>>> that the tx_done callback can use to determine how to handle an error.
>>> However the IRQ handler was not setting that value if there is an error.
>>>
>>> The following clients are affected:
>>>
>>> drivers/acpi/cppc_acpi.c
>>> drivers/i2c/busses/i2c-xgene-slimpro.c
>>> drivers/hwmon/xgene-hwmon.c
>>> drivers/soc/hisilicon/kunpeng_hccs.c
>>> drivers/devfreq/hisi_uncore_freq.c
>>>
>>> All of these only use the error code to report, so they
>>> are expecting an error code to come thorugh, but they
>>> do not modify behavior based on this code.
>>>
>>> In the case of an error code in the IRQ, the handler was returning
>>> IRQ_NONE which is not correct: the IRQ handler was matched
>>> to the IRQ. This mean that multiple error codes returned from
>>> a PCC triggered interrupt would end up disabling the device.
>>>
>>> In addition, if the error code IRQ was coming from a Type4 Device that was
>>> expecting an IRQ response, that device would then be hung.
>>>
>>> Fixes: c45ded7e1135 ("mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4)")
>> Not fix above commit.
>> mbox_chan_txdone() was added in below patch.
>> Fixes: 9c753f7c953c (mailbox: pcc: Mark Tx as complete in PCC IRQ handler)
>>> Signed-off-by: Adam Young <admiyo@os.amperecomputing.com>
>>>
>>> ---
>>> ---
>>> drivers/mailbox/pcc.c | 9 +++++----
>>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
>>> index 636879ae1db7..16b9ce087b9e 100644
>>> --- a/drivers/mailbox/pcc.c
>>> +++ b/drivers/mailbox/pcc.c
>>> @@ -314,6 +314,7 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
>>> {
>>> struct pcc_chan_info *pchan;
>>> struct mbox_chan *chan = p;
>>> + int rc;
>>> pchan = chan->con_priv;
>>> @@ -327,8 +328,7 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
>>> if (!pcc_mbox_cmd_complete_check(pchan))
>>> return IRQ_NONE;
>>> - if (pcc_mbox_error_check_and_clear(pchan))
>>> - return IRQ_NONE;
>>> + rc = pcc_mbox_error_check_and_clear(pchan);
>> I think it is not necessary. This function just return -EIO on failure.
>>
>>> /*
>>> * Clear this flag after updating interrupt ack register and just
>>> @@ -337,8 +337,9 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
>>> * required to avoid any possible race in updatation of this flag.
>>> */
>>> pchan->chan_in_use = false;
>>> - mbox_chan_received_data(chan, NULL);
>>> - mbox_chan_txdone(chan, 0);
>>> + if (!rc)
>>> + mbox_chan_received_data(chan, NULL);
>>> + mbox_chan_txdone(chan, rc);
>> @Sudeep, I have always had doubts about the addition of this line of code in
>> the
>> commit 9c753f7c953c (mailbox: pcc: Mark Tx as complete in PCC IRQ handler).
>> The patch seems to avoid the timeouts in the mailbox core according to its
>> commit log.
>> Regardless of whether the command succeeds or fails, each mbox client
>> driver, like cppc_acpi/acpi_pcc，kunpeng_hccs and so on, is responsible to
>> call mbox_chan_txdone() to tell mailbox core.
> Few controller drivers do have mbox_chan_txdone(), so Tx complete is detected
Which controller driver?
> by PCC, so not sure why you think this is not the right place to do. The irq
Because many mbox client drivers call mbox_chan_txdone() after running
rx_callback() in mbox_chan_received_data().
These drivers doesn't set chan->cl->tx_block to true.
It seems that the client driver having tx_block need to set
chan->tx_complete in tx_tick().
Do you add this code for them?
> is to indicate the completion. I am confused as why you think otherwise.
> It is defined in include/linux/mailbox_controller.h for the same reason.
>
> The client drivers can you mbox_client_txdone() if they wish to as defined
> in include/linux/mailbox_client.h
mbox_client_txdone() is used in the case that txdone_method is
MBOX_TXDONE_BY_ACK.
And mbox clinte driver using IRQ method need to use mbox_chan_txdone().
It seems that all the current client drivers are used in this way.
These interface internal would verify chan->txdone_method.
In addition, I find that you also modify the txdone_irq/poll in the
commit 3349f800609e (mailbox: pcc: Set txdone_irq/txdone_poll based on
PCCT flags).
The txdone_method will change from MBOX_TXDONE_BY_ACK to
MBOX_TXDONE_BY_POLL on the platform using poll mode.
This may lead to the original mbox client driver printing exceptions in
mbox_client_txdone.
I haven't observed it based on the latest code yet, it's just code
analysis.
>
>> This is done after executing mbox_chan_received_data(). So I think this line
>> in this function is redundant.
> No, I think otherwise, see details above.
>
^ permalink raw reply
* Re: [PATCH v2 5/7] mm/vmalloc: map contiguous pages in batches for vmap() if possible
From: Mike Rapoport @ 2026-05-20 11:53 UTC (permalink / raw)
To: Wen Jiang
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, urezki,
baohua, Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, Wen Jiang
In-Reply-To: <20260514094108.2016201-6-jiangwen6@xiaomi.com>
On Thu, 14 May 2026 17:41:06 +0800, Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 516d406507e9..c30a7673e0ac 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3520,6 +3520,77 @@ void vunmap(const void *addr)
> [ ... skip 25 lines ... ]
> +
> + return order;
> +}
> +
> +static int __vmap_huge(unsigned long addr, unsigned long end,
> + pgprot_t prot, struct page **pages)
This won't necessaryly create huge mappings, maybe vmap_batched?
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH v2 4/7] mm/vmalloc: Extend page table walk to support larger page_shift sizes and eliminate page table rewalk
From: Mike Rapoport @ 2026-05-20 11:53 UTC (permalink / raw)
To: Wen Jiang
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, urezki,
baohua, Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, Wen Jiang
In-Reply-To: <20260514094108.2016201-5-jiangwen6@xiaomi.com>
On Thu, 14 May 2026 17:41:05 +0800, Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
Hi,
> vmap_pages_range_noflush_walk() (formerly vmap_small_pages_range_noflush())
> provides a clean interface by taking struct page **pages and mapping them
> via direct PTE iteration. This avoids the page table rewalk seen when
> using vmap_range_noflush() for page_shift values other than PAGE_SHIFT.
>
> Extend it to support larger page_shift values, and add PMD- and
> contiguous-PTE mappings as well. Rename it to vmap_pages_range_noflush_walk()
> since it now handles more than just small pages.
>
> For vmalloc() allocations with VM_ALLOW_HUGE_VMAP, we no longer need to
> iterate over pages one by one via vmap_range_noflush(), which would
> otherwise lead to page table rewalk. The code is now unified with the
> PAGE_SHIFT case by simply calling vmap_pages_range_noflush_walk().
After this patch we have two very simalar page table walkers:
vmap_pages_range_noflush_walk() and vmap_range_noflush().
The subtly differ at what levels they try huge mappings, how they
account page table modifucations and, at last vmap_range_noflush() is
left without support for contiguous mappings.
Is there a fundamental reason to have two page walkers?
Is there a reason not to support contiguous mappings in
vmap_range_noflush()?
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [RFC PATCH 1/2] KVM: arm64: Introduce S2 walker SKIP return options
From: Leonardo Bras @ 2026-05-20 11:49 UTC (permalink / raw)
To: Oliver Upton
Cc: Leonardo Bras, Will Deacon, Marc Zyngier, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Fuad Tabba,
Raghavendra Rao Ananta, linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <agzUZS1l-uHQoodG@kernel.org>
On Tue, May 19, 2026 at 02:21:41PM -0700, Oliver Upton wrote:
> On Tue, May 19, 2026 at 03:35:19PM +0100, Leonardo Bras wrote:
> > On Tue, May 19, 2026 at 02:15:41PM +0100, Will Deacon wrote:
> > > On Tue, May 19, 2026 at 01:56:48PM +0100, Leonardo Bras wrote:
> > > > On Tue, May 19, 2026 at 01:43:37PM +0100, Will Deacon wrote:
> > > > > > > I was wondering along similar lines, but maybe it would be useful just
> > > > > > > to pass a maximum level to the walker logic? That feels like the most
> > > > > > > general case without complicating the existing logic.
>
> FWIW, I had considered this too but decided that it requires a bit more
> churn since we cannot rely on zero initialization in the existing
> callsites (level 0 is a valid level).
>
> But that's extremely minor.
>
> > > > > > This proposal seems simpler for me to understand, and indeed looks like a
> > > > > > better solution than what I have proposed, taking care of the
> > > > > > 'already split' case with better performance, as it don't even walk a
> > > > > > single level-3 entry.
> > > > > >
> > > > > > On the 'splitting' case, it also works flawlessly if the memory is given in
> > > > > > level-2 blocks. There is only one case that I would like to address here:
> > > > > >
> > > > > > - Memory given in level-1 blocks (say 1GB)
> > > > > > - Walker flag says 'walk down to level-2 only'
> > > > > > - Split Walker on level-1 will break page down to (up to) level-3 entries.
> > > > > > - Walker will continue to be called on level-2 entries, even though it's
> > > > > > not necessary.
> > > > >
> > > > > If you're only visiting leaves, why would it be called on the level-2
> > > > > table entries?
> > > > >
> > > >
> > > > Because once the leaf is turned into a table by the splitting walker, it
> > > > gets reloaded and walked. This is an excerpt of __kvm_pgtable_visit():
> > >
> > > Sorry, I was musing about the semantics after adding something to limit
> > > the maximum level. I don't dispute what the current code would do.
> > >
> > > > Example:
> > > > - Split this level-1 leave:
> > > > - Walker creates the whole structure up to given level (currently 3)
> > > > - Walker returns, gets reloaded, table detected, go down on that one
> > > > - Level 2 entries walked (which is unnecessary)
> > > >
> > > > Please let me know if I am misunderstanding something.
> > >
> > > I just don't grok why this would happen if we limited the maximum level
> > > to '2' _and_ said we only wanted to visit the leaf entries. In that
> > > case, I wouldn't expect to descend into any of the L2 table entries
> > > (because that would imply going beyond level 2) and I wouldn't expect to
> > > be called for the table entries either (because we're only interested in
> > > leaves).
> >
> > Agree, if we specify to skip level-3 entries, it would only walk up to
> > level-2 entries, but take above example in detail:
> > - Split these level-1 leaves, up to level-3 leaves (regular)
> > - INFO: kvm_pgtable_walk will call walker:
> > - only up to level-2 entries (skip level-3)
> > - only on leaf entries
> > - Walk first level-1 leaf, calls walker
> > - walker will split the level-1 leaf in level-3 leaves
> > - walker return from that first level-1 leaf
> > - level-1 leaf is reloaded as a table
> > - level-2 entries of that table are also walked (unnecessary)
> > - on each of the level-2 table entries, level-3 entries are skipped
> >
> > To avoid the unecessary walk of the level-2 entries above, we would need to
> > specify 'skip level-2' that could be an issue if we have a mix of level-1
> > and level-2 leaves, as the level-2 leaves in that case would not be split.
> >
> > That's why I suggest something like "skip recently created table" as a flag
> > as well, so we can guarantee no newly created table gets walked
> > unecessarily.
> >
> > Please help me if I am missing something important.
>
> I'm not sure the added complexity of handling this case perfectly results
> in a measurable performance improvement. Just avoiding the level 3
> tables would be an exponential reduction (~ 512-8192x) in the number of
> walk steps.
>
Humm, I agree most of the improvement is due to skipping level-3 walks.
The added complexity would be, appart from a new flag, just a single line
change:
---
if (!table && (ctx.flags & KVM_PGTABLE_WALK_LEAF)) {
ret = kvm_pgtable_visitor_cb(data, &ctx, KVM_PGTABLE_WALK_LEAF);
- reload = true;
+ /* Do not reload if flagged to skip new table */
+ reload = !(ctx.flags & KVM_PGTABLE_WALK_SKIP_NEW_TABLE);
}
---
Even then, do you think it would not be worth having it?
Thanks!
Leo
^ permalink raw reply
* Re: (subset) [PATCH v8 1/4] dt-bindings: backlight: Add max25014 support
From: Lee Jones @ 2026-05-20 11:47 UTC (permalink / raw)
To: Frank Li
Cc: Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Liam Girdwood, Mark Brown, Maud Spierings, dri-devel, linux-leds,
devicetree, linux-kernel, linux-fbdev, imx, linux-arm-kernel
In-Reply-To: <agyxLnTYstqRwGva@lizhi-Precision-Tower-5810>
On Tue, 19 May 2026, Frank Li wrote:
> On Thu, Apr 30, 2026 at 02:53:40PM +0100, Lee Jones wrote:
> > On Tue, 07 Apr 2026 16:41:42 +0200, Maud Spierings wrote:
> > > The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
> > > with integrated boost controller.
> >
> > Applied, thanks!
> >
> > [1/4] dt-bindings: backlight: Add max25014 support
> > commit: 5fcbbedec9dfce78044eee922bf2030e1bd03faa
>
> Lee Jones:
>
> I have not seen it in linux-next. Anything wrong?
I don't know why Backlight hasn't been added to Linux Next.
Rest assured, it's applied to the Backlight tree.
--
Lee Jones
^ permalink raw reply
* Re: [PATCH] media: s5p-mfc: avoid double free on video register failure
From: Marek Szyprowski @ 2026-05-20 11:37 UTC (permalink / raw)
To: Guangshuo Li, Andrzej Hajda, Mauro Carvalho Chehab,
linux-arm-kernel, linux-media, linux-kernel
In-Reply-To: <20260518130929.1003652-1-lgs201920130244@gmail.com>
On 18.05.2026 15:09, Guangshuo Li wrote:
> s5p_mfc_probe() allocates video_device instances for both the decoder
> and encoder and releases them from the probe error paths if
> video_register_device() fails.
>
> This can double free a video_device when __video_register_device()
> reaches device_register() and that call fails:
>
> video_register_device()
> -> __video_register_device()
> -> device_register() fails
> -> put_device(&vdev->dev)
> -> v4l2_device_release()
> -> vdev->release(vdev)
> -> video_device_release(vdev)
>
> s5p_mfc_probe()
> -> err_dec_reg or err_enc_reg
> -> video_device_release(vdev)
>
> Use video_device_release_empty() while registering the decoder and encoder
> video devices so that registration failure paths do not free them through
> vdev->release(). s5p_mfc_probe() then releases each video_device exactly
> once from its error path. Restore video_device_release() after successful
> registration so the registered devices keep their normal lifetime
> handling.
>
> This issue was found by a static analysis tool I am developing.
>
> Fixes: d0ce898c39bf ("[media] s5p-mfc: Replaced commas with semicolons")
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Frankly speaking I don't like this dancing with video_device_release_empty() and
video_device_release(). I would rather make video_device struct a part of device
state and use common release function.
> ---
> drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
> index 32eb402d439c..75abb0a8b7a9 100644
> --- a/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/samsung/s5p-mfc/s5p_mfc.c
> @@ -1376,7 +1376,7 @@ static int s5p_mfc_probe(struct platform_device *pdev)
> }
> vfd->fops = &s5p_mfc_fops;
> vfd->ioctl_ops = get_dec_v4l2_ioctl_ops();
> - vfd->release = video_device_release;
> + vfd->release = video_device_release_empty;
> vfd->lock = &dev->mfc_mutex;
> vfd->v4l2_dev = &dev->v4l2_dev;
> vfd->vfl_dir = VFL_DIR_M2M;
> @@ -1395,7 +1395,7 @@ static int s5p_mfc_probe(struct platform_device *pdev)
> }
> vfd->fops = &s5p_mfc_fops;
> vfd->ioctl_ops = get_enc_v4l2_ioctl_ops();
> - vfd->release = video_device_release;
> + vfd->release = video_device_release_empty;
> vfd->lock = &dev->mfc_mutex;
> vfd->v4l2_dev = &dev->v4l2_dev;
> vfd->vfl_dir = VFL_DIR_M2M;
> @@ -1416,6 +1416,8 @@ static int s5p_mfc_probe(struct platform_device *pdev)
> v4l2_err(&dev->v4l2_dev, "Failed to register video device\n");
> goto err_dec_reg;
> }
> +
> + dev->vfd_dec->release = video_device_release;
> v4l2_info(&dev->v4l2_dev,
> "decoder registered as /dev/video%d\n", dev->vfd_dec->num);
>
> @@ -1424,6 +1426,8 @@ static int s5p_mfc_probe(struct platform_device *pdev)
> v4l2_err(&dev->v4l2_dev, "Failed to register video device\n");
> goto err_enc_reg;
> }
> +
> + dev->vfd_enc->release = video_device_release;
> v4l2_info(&dev->v4l2_dev,
> "encoder registered as /dev/video%d\n", dev->vfd_enc->num);
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH v2 2/3] arm64: dts: freescale: add Aquila iMX95 support
From: Franz Schnyder @ 2026-05-20 11:30 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel,
Francesco Dolcini, Franz Schnyder, João Paulo Gonçalves,
Emanuele Ghidoli, Francesco Dolcini, Antoine Gouby,
Ernest Van Hoecke
In-Reply-To: <20260520-add-aquila-imx95-v2-0-06424a51e33a@toradex.com>
From: João Paulo Gonçalves <joao.goncalves@toradex.com>
Add support for the Toradex Aquila iMX95 and its development carrier
board.
The module consists of an NXP i.MX95 family SoC, up to 16GB LPDDR5 RAM,
up to 128GB of storage, a USB 3.2 OTG and USB 2.0 Host, a Gigabit
Ethernet PHY, a 10 Gigabit Ethernet interface, an I2C EEPROM and
Temperature Sensor, an RX8130 RTC, one Quad lane CSI interface, one Quad
lane DSI or CSI interface, one LVDS interface (one or two channels), and
some optional addons: DisplayPort (through a DSI-DP bridge), TPM 2.0,
and a WiFi/BT module.
Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
Link: https://www.toradex.com/products/carrier-board/aquila-development-board-kit
Signed-off-by: João Paulo Gonçalves <joao.goncalves@toradex.com>
Co-developed-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Signed-off-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
Co-developed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Co-developed-by: Antoine Gouby <antoine.gouby@toradex.com>
Signed-off-by: Antoine Gouby <antoine.gouby@toradex.com>
Co-developed-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
Co-developed-by: Franz Schnyder <franz.schnyder@toradex.com>
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
v2: -Reordered iomux alphanumerically by node name
-Changed Francesco's tags to have the Toradex mail address
v1: https://lore.kernel.org/all/20260506-add-aquila-imx95-v1-2-69c8ee1c5413@toradex.com/
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
arch/arm64/boot/dts/freescale/imx95-aquila-dev.dts | 398 +++++++
arch/arm64/boot/dts/freescale/imx95-aquila.dtsi | 1160 ++++++++++++++++++++
3 files changed, 1559 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 513f61eb27b85..c8697b6ae01c5 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -523,6 +523,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk-sof.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx95-aquila-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-toradex-smarc-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-tqma9596sa-mb-smarc-2.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-var-dart-sonata.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx95-aquila-dev.dts b/arch/arm64/boot/dts/freescale/imx95-aquila-dev.dts
new file mode 100644
index 0000000000000..b2a53847d5079
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-aquila-dev.dts
@@ -0,0 +1,398 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
+ * https://www.toradex.com/products/carrier-board/aquila-development-board-kit
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/usb/pd.h>
+#include "imx95-aquila.dtsi"
+
+/ {
+ model = "Aquila iMX95 on Aquila Development Board";
+ compatible = "toradex,aquila-imx95-dev",
+ "toradex,aquila-imx95",
+ "fsl,imx95";
+
+ aliases {
+ eeprom1 = &carrier_eeprom;
+ };
+
+ dp_1_connector: dp0-connector {
+ compatible = "dp-connector";
+ dp-pwr-supply = <®_dp_3p3v>;
+ type = "full-size";
+
+ port {
+ dp_1_connector_in: endpoint {
+ remote-endpoint = <&dsi2dp_out>;
+ };
+ };
+ };
+
+ reg_carrier_1p8v: regulator-carrier-1p8v {
+ compatible = "regulator-fixed";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ regulator-name = "On-carrier 1V8";
+ };
+
+ reg_dp_3p3v: regulator-dp-3p3v {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_21_dp>;
+ /* Aquila GPIO_21_DP */
+ gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "DP_3V3";
+ startup-delay-us = <10000>;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,bitclock-master = <&codec_dai>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <&codec_dai>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,name = "aquila-wm8904";
+ simple-audio-card,routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "Microphone Jack", "MICBIAS",
+ "IN1L", "Microphone Jack",
+ "IN1R", "Digital Mic";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Microphone", "Digital Mic",
+ "Headphone", "Headphone Jack",
+ "Line", "Line In Jack";
+
+ codec_dai: simple-audio-card,codec {
+ sound-dai = <&wm8904_1a>;
+ };
+
+ simple-audio-card,cpu {
+ sound-dai = <&sai2>;
+ };
+ };
+};
+
+/* Aquila ADC_[1-4] */
+&adc1 {
+ status = "okay";
+};
+
+/* Aquila CTRL_WAKE1_MICO# */
+&aquila_key_wake {
+ status = "okay";
+};
+
+&dsi2dp_out {
+ remote-endpoint = <&dp_1_connector_in>;
+};
+
+/* Aquila ETH_1 */
+&enetc_port0 {
+ status = "okay";
+};
+
+/* Aquila CAN_1 */
+&flexcan1 {
+ status = "okay";
+};
+
+/* Aquila CAN_2 */
+&flexcan2 {
+ status = "okay";
+};
+
+/* Aquila CAN_3 */
+&flexcan3 {
+ status = "okay";
+};
+
+/* Aquila CAN_4 */
+&flexcan4 {
+ status = "okay";
+};
+
+/* Aquila QSPI_1 */
+&flexspi1 {
+ pinctrl-0 = <&pinctrl_flexspi1_4bit>,
+ <&pinctrl_qspi_cs1>;
+
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-max-frequency = <66000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
+ cdns,read-delay = <0>;
+ cdns,tchsh-ns = <3>;
+ cdns,tsd2d-ns = <10>;
+ cdns,tshsl-ns = <30>;
+ cdns,tslch-ns = <8>;
+ };
+};
+
+&gpio1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_8>;
+};
+
+&gpio4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_1>,
+ <&pinctrl_gpio_2>,
+ <&pinctrl_gpio_3>,
+ <&pinctrl_gpio_4>,
+ <&pinctrl_gpio_5>,
+ <&pinctrl_gpio_6>,
+ <&pinctrl_gpio_7>;
+};
+
+/* Aquila I2C_1 */
+&lpi2c2 {
+ status = "okay";
+
+ fan_controller: fan@18 {
+ compatible = "ti,amc6821";
+ reg = <0x18>;
+ #pwm-cells = <2>;
+
+ fan {
+ cooling-levels = <255>;
+ pwms = <&fan_controller 40000 PWM_POLARITY_INVERTED>;
+ };
+ };
+
+ wm8904_1a: audio-codec@1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai2_mclk>;
+ clocks = <&scmi_clk IMX95_CLK_SAI2>;
+ clock-names = "mclk";
+ #sound-dai-cells = <0>;
+ AVDD-supply = <®_carrier_1p8v>;
+ CPVDD-supply = <®_carrier_1p8v>;
+ DBVDD-supply = <®_carrier_1p8v>;
+ DCVDD-supply = <®_carrier_1p8v>;
+ MICVDD-supply = <®_carrier_1p8v>;
+ wlf,drc-cfg-names = "default", "peaklimiter";
+ /*
+ * Config registers per name, respectively:
+ * KNEE_IP = 0, KNEE_OP = 0, HI_COMP = 1, LO_COMP = 1
+ * KNEE_IP = -24, KNEE_OP = -6, HI_COMP = 1/4, LO_COMP = 1
+ */
+ wlf,drc-cfg-regs = /bits/ 16 <0x01af 0x3248 0x0000 0x0000>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x0408>;
+ /* GPIO1 = DMIC_CLK, don't touch others */
+ wlf,gpio-cfg = <0x0018>, <0xffff>, <0xffff>, <0xffff>;
+ wlf,in1r-as-dmicdat2;
+ };
+
+ /* Current measurement into module VCC */
+ hwmon@41 {
+ compatible = "ti,ina226";
+ reg = <0x41>;
+ shunt-resistor = <5000>;
+ };
+
+ temperature-sensor@4f {
+ compatible = "ti,tmp1075";
+ reg = <0x4f>;
+ };
+
+ /* USB-C OTG (TCPC USB PD PHY) */
+ tcpc@52 {
+ compatible = "nxp,ptn5110", "tcpci";
+ reg = <0x52>;
+ interrupt-parent = <&som_gpio_expander_1>;
+ interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
+
+ connector {
+ compatible = "usb-c-connector";
+ data-role = "dual";
+ op-sink-microwatt = <0>;
+ power-role = "dual";
+ self-powered;
+ sink-pdos = <PDO_FIXED(5000, 0, PDO_FIXED_USB_COMM)>;
+ source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ try-power-role = "sink";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ typec_con_hs: endpoint {
+ remote-endpoint = <&usb1_con_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ typec_con_ss: endpoint {
+ remote-endpoint = <&usb1_con_ss>;
+ };
+ };
+ };
+ };
+ };
+
+ carrier_eeprom: eeprom@57 {
+ compatible = "st,24c02", "atmel,24c02";
+ reg = <0x57>;
+ pagesize = <16>;
+ };
+};
+
+/* Aquila I2C_2 */
+&i3c2 {
+ status = "okay";
+};
+
+/* Aquila I2C_4_CSI1 */
+&lpi2c4 {
+ status = "okay";
+};
+
+/* Aquila I2C_6 */
+&lpi2c5 {
+ status = "okay";
+};
+
+/* Aquila I2C_3_DSI1/I2C_5_CSI2 */
+&lpi2c8 {
+ status = "okay";
+
+ i2c-mux@70 {
+ compatible = "nxp,pca9543";
+ reg = <0x70>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* I2C on DSI Connector Pin #4 and #6 */
+ i2c_dsi_0: i2c@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ /* I2C on DSI Connector Pin #52 and #54 */
+ i2c_dsi_1: i2c@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
+
+/* Aquila SPI_1 */
+&lpspi6 {
+ status = "okay";
+};
+
+/* Aquila UART_3, used as the Linux Console */
+&lpuart1 {
+ status = "okay";
+};
+
+/* Aquila UART_4 */
+&lpuart2 {
+ status = "okay";
+};
+
+/* Aquila UART_1 */
+&lpuart3 {
+ status = "okay";
+};
+
+/* Aquila UART_2 as RS485 */
+&lpuart7 {
+ linux,rs485-enabled-at-boot-time;
+ rs485-rts-active-low;
+ rs485-rx-during-tx;
+
+ status = "okay";
+};
+
+/* Aquila PCIE_1 */
+&pcie0 {
+ status = "okay";
+};
+
+/* Aquila I2S_1 */
+&sai2 {
+ status = "okay";
+};
+
+&som_dsi2dp_bridge {
+ status = "okay";
+};
+
+/* Aquila PWM_1 */
+&tpm3 {
+ status = "okay";
+};
+
+/* Aquila PWM_2 */
+&tpm6 {
+ status = "okay";
+};
+
+/* Aquila PWM_3_DSI and PWM_4_DP */
+&tpm5 {
+ status = "okay";
+};
+
+/* Aquila USB_2, optional Bluetooth USB */
+&usb2 {
+ status = "okay";
+};
+
+/* Aquila USB_1 */
+&usb3 {
+ status = "okay";
+};
+
+&usb3_dwc3 {
+ status = "okay";
+
+ port {
+ usb1_con_hs: endpoint {
+ remote-endpoint = <&typec_con_hs>;
+ };
+ };
+};
+
+&usb3_phy {
+ orientation-switch;
+
+ status = "okay";
+
+ port {
+ usb1_con_ss: endpoint {
+ remote-endpoint = <&typec_con_ss>;
+ };
+ };
+};
+
+/* Aquila SD_1 */
+&usdhc2 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx95-aquila.dtsi b/arch/arm64/boot/dts/freescale/imx95-aquila.dtsi
new file mode 100644
index 0000000000000..c6dc48852ac6c
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-aquila.dtsi
@@ -0,0 +1,1160 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
+ */
+
+#include <dt-bindings/net/ti-dp83867.h>
+#include "imx95.dtsi"
+
+/ {
+ aliases {
+ can0 = &flexcan1;
+ can1 = &flexcan2;
+ can2 = &flexcan3;
+ can3 = &flexcan4;
+ eeprom0 = &som_eeprom;
+ ethernet0 = &enetc_port0;
+ i2c0 = &lpi2c3;
+ i2c1 = &lpi2c2;
+ i2c2 = &i3c2;
+ i2c3 = &lpi2c8;
+ i2c4 = &lpi2c4;
+ i2c6 = &lpi2c5;
+ mmc0 = &usdhc1;
+ mmc1 = &usdhc2;
+ rtc0 = &rtc_i2c;
+ rtc1 = &scmi_bbm;
+ serial0 = &lpuart3;
+ serial1 = &lpuart7;
+ serial2 = &lpuart1;
+ serial3 = &lpuart2;
+ usb0 = &usb3;
+ usb1 = &usb2;
+ };
+
+ chosen {
+ stdout-path = "serial2:115200n8";
+ };
+
+ aquila_key_wake: gpio-key-wakeup {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ctrl_wake1_mico>;
+
+ status = "disabled";
+
+ key-wakeup {
+ /* Aquila CTRL_WAKE1_MICO# */
+ gpios = <&gpio5 11 GPIO_ACTIVE_LOW>;
+ label = "Wake Up";
+ wakeup-source;
+ linux,code = <KEY_WAKEUP>;
+ };
+ };
+
+ clk_dsi2dp_refclk: clock-dsi2dp-refclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <27000000>;
+ };
+
+ clk_dsi2dp_refclk_en: clock-dsi2dp-refclk-en {
+ compatible = "gpio-gate-clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ctrl_dp_clk_en>;
+ clocks = <&clk_dsi2dp_refclk>;
+ #clock-cells = <0>;
+ /* CTRL_DP_CLK_EN */
+ enable-gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
+ };
+
+ clk_serdes_eth_ref: clock-serdes-eth-ref {
+ compatible = "gpio-gate-clock";
+ #clock-cells = <0>;
+ /* CTRL_ETH_REF_CLK_STBY */
+ enable-gpios = <&som_gpio_expander_0 6 GPIO_ACTIVE_LOW>;
+ };
+
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ regulator-name = "On-module +V1.8";
+ };
+
+ reg_dp_1p2v: regulator-dp-1p2v {
+ compatible = "regulator-fixed";
+ /* CTRL_DP_BRIDGE_EN */
+ gpios = <&som_gpio_expander_0 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-always-on;
+ regulator-max-microvolt = <1200000>;
+ regulator-min-microvolt = <1200000>;
+ regulator-name = "On-module +V1.2_DP";
+ vin-supply = <®_1p8v>;
+ };
+
+ reg_usb1_vbus: regulator-usb1-vbus {
+ compatible = "regulator-fixed";
+ /* Aquila USB_1_EN */
+ gpios = <&som_gpio_expander_0 2 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-name = "USB_1_EN";
+ };
+
+ reg_usb2_vbus: regulator-usb2-vbus {
+ compatible = "regulator-fixed";
+ /* Aquila USB_2_EN */
+ gpios = <&som_gpio_expander_0 3 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-name = "USB_2_H_EN";
+ };
+
+ reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sd1_pwr_en>;
+ /* Aquila SD_1_PWR_EN */
+ gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ off-on-delay-us = <100000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "SD_1_PWR_EN";
+ startup-delay-us = <20000>;
+ };
+
+ reg_usdhc2_vqmmc: regulator-usdhc2-vqmmc {
+ compatible = "regulator-gpio";
+ /* PMIC_SD_1_VSEL */
+ gpios = <&som_gpio_expander_1 9 GPIO_ACTIVE_HIGH>;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <1800000>;
+ regulator-name = "PMIC_SD_1_VSEL";
+ states = <1800000 0x1>,
+ <3300000 0x0>;
+ };
+
+ remoteproc-cm7 {
+ compatible = "fsl,imx95-cm7";
+ mboxes = <&mu7 0 1 &mu7 1 1 &mu7 3 1>;
+ mbox-names = "tx", "rx", "rxdb";
+ memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
+ <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>, <&m7_reserved>;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ linux_cma: linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0 0x3c000000>;
+ alloc-ranges = <0 0x80000000 0 0x7f000000>;
+ linux,cma-default;
+ };
+
+ m7_reserved: memory@80000000 {
+ reg = <0 0x80000000 0 0x1000000>;
+ no-map;
+ };
+
+ rsc_table: rsc-table@88220000 {
+ reg = <0 0x88220000 0 0x1000>;
+ no-map;
+ };
+
+ vdev0vring0: vdev0vring0@88000000 {
+ reg = <0 0x88000000 0 0x8000>;
+ no-map;
+ };
+
+ vdev0vring1: vdev0vring1@88008000 {
+ reg = <0 0x88008000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring0: vdev1vring0@88010000 {
+ reg = <0 0x88010000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring1: vdev1vring1@88018000 {
+ reg = <0 0x88018000 0 0x8000>;
+ no-map;
+ };
+
+ vdevbuffer: vdevbuffer@88020000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x88020000 0 0x100000>;
+ no-map;
+ };
+ };
+};
+
+/* Aquila ADC_[1-4] */
+&adc1 {
+ vref-supply = <®_1p8v>;
+};
+
+/* Aquila ETH_1 */
+&enetc_port0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enetc0>;
+ phy-handle = <ðphy1>;
+ phy-mode = "rgmii-id";
+};
+
+/* Aquila CAN_1 */
+&flexcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+};
+
+/* Aquila CAN_2 */
+&flexcan2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+};
+
+/* Aquila CAN_3 */
+&flexcan3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan3>;
+};
+
+/* Aquila CAN_4 */
+&flexcan4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan4>;
+};
+
+/* Aquila QSPI_1 */
+&flexspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexspi1_8bit>,
+ <&pinctrl_qspi_cs1>;
+};
+
+&gpio1 {
+ gpio-line-names = "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "AQUILA_C24", /* 10 */
+ "",
+ "AQUILA_B17",
+ "CTRL_GPIO_EXP_INT#",
+ "AQUILA_B18";
+
+ status = "okay";
+};
+
+&gpio2 {
+ gpio-line-names = "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "AQUILA_B42",
+ "",
+ "AQUILA_B43";
+};
+
+&gpio3 {
+ gpio-line-names = "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "AQUILA_A11",
+ "", /* 20 */
+ "AQUILA_B57",
+ "AQUILA_B19";
+};
+
+&gpio4 {
+ gpio-line-names = "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "AQUILA_C22",
+ "AQUILA_C21",
+ "AQUILA_C20",
+ "", /* 20 */
+ "",
+ "",
+ "AQUILA_C23",
+ "AQUILA_D23",
+ "AQUILA_D24",
+ "",
+ "AQUILA_D25";
+};
+
+&gpio5 {
+ gpio-line-names = "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "AQUILA_B44",
+ "AQUILA_B45";
+};
+
+/* Aquila I2C_2 */
+&i3c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i3c2>;
+ i2c-scl-hz = <100000>;
+};
+
+/* Aquila I2C_1 */
+&lpi2c2 {
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c2>;
+ pinctrl-1 = <&pinctrl_lpi2c2_gpio>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ scl-gpios = <&gpio1 2 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio1 3 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+};
+
+/* On-module I2C - I2C_SOM */
+&lpi2c3 {
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c3>, <&pinctrl_ctrl_gpio_exp_int>;
+ pinctrl-1 = <&pinctrl_lpi2c3_gpio>, <&pinctrl_ctrl_gpio_exp_int>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <400000>;
+ scl-gpios = <&gpio2 29 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 28 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+
+ status = "okay";
+
+ som_gpio_expander_0: gpio@20 {
+ compatible = "nxp,pcal6408";
+ reg = <0x20>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-line-names =
+ "AQUILA_C38", /* 0 */
+ "PCIE_2_RESET#",
+ "AQUILA_B77",
+ "USB_2_H_EN",
+ "BT_DISABLE#",
+ "WIFI_DISABLE#",
+ "CTRL_ETH_REF_CLK_STBY",
+ "CTRL_DP_BRIDGE_EN";
+ };
+
+ som_gpio_expander_1: gpio@21 {
+ compatible = "nxp,pcal6416";
+ reg = <0x21>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ interrupt-parent = <&gpio1>;
+ interrupts = <13 IRQ_TYPE_LEVEL_LOW>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-line-names =
+ "AQUILA_C1", /* 0 */
+ "AQUILA_C2",
+ "AQUILA_C3",
+ "AQUILA_C4",
+ "AQUILA_C36",
+ "AQUILA_B74",
+ "AQUILA_B75",
+ "USB_2_H_OC#",
+ "AQUILA_B81",
+ "PMIC_SD_1_VSEL",
+ "ETH_1_INT#", /* 10 */
+ "CTRL_TPM_INT#",
+ "SPI_2_CS2_TPM",
+ "PCIE_WAKE_WIFI#",
+ "WIFI_WAKE_BT",
+ "WIFI_WAKEUP_HOST";
+ };
+
+ som_dsi2dp_bridge: bridge@2c {
+ compatible = "ti,sn65dsi86";
+ reg = <0x2c>;
+ clocks = <&clk_dsi2dp_refclk_en>;
+ clock-names = "refclk";
+ vcc-supply = <®_dp_1p2v>;
+ vcca-supply = <®_dp_1p2v>;
+ vccio-supply = <®_1p8v>;
+ vpll-supply = <®_1p8v>;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dsi2dp_in: endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ dsi2dp_out: endpoint {
+ data-lanes = <3 2 1 0>;
+ };
+ };
+ };
+ };
+
+ rtc_i2c: rtc@32 {
+ compatible = "epson,rx8130";
+ reg = <0x32>;
+ };
+
+ temperature-sensor@48 {
+ compatible = "ti,tmp1075";
+ reg = <0x48>;
+ };
+
+ som_eeprom: eeprom@50 {
+ compatible = "st,24c02", "atmel,24c02";
+ reg = <0x50>;
+ pagesize = <16>;
+ };
+};
+
+/* Aquila I2C_4_CSI1 */
+&lpi2c4 {
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c4>;
+ pinctrl-1 = <&pinctrl_lpi2c4_gpio>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ scl-gpios = <&gpio2 31 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 30 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+};
+
+/* Aquila I2C_6 */
+&lpi2c5 {
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c5>;
+ pinctrl-1 = <&pinctrl_lpi2c5_gpio>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ scl-gpios = <&gpio2 23 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 22 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+};
+
+/* Aquila I2C_3_DSI1/I2C_5_CSI2 */
+&lpi2c8 {
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c8>;
+ pinctrl-1 = <&pinctrl_lpi2c8_gpio>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ scl-gpios = <&gpio2 13 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 12 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+};
+
+/* Aquila SPI_2 */
+&lpspi4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi4>;
+ cs-gpios = <&gpio2 18 GPIO_ACTIVE_LOW>,
+ <&som_gpio_expander_1 12 GPIO_ACTIVE_LOW>;
+
+ status = "okay";
+
+ som_tpm: tpm@1 {
+ compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+ reg = <0x1>;
+ interrupt-parent = <&som_gpio_expander_1>;
+ interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
+ /*
+ * Maximum TPM-supported speed is 18.5 MHz, limited to 12 MHz
+ * here as lpspi4's per-clock (2x the max speed) is 24 MHz.
+ */
+ spi-max-frequency = <12000000>;
+ };
+};
+
+/* Aquila SPI_1 */
+&lpspi6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi6>;
+ cs-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
+};
+
+/* Aquila UART_3, used as the Linux Console */
+&lpuart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+};
+
+/* Aquila UART_4 */
+&lpuart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+};
+
+/* Aquila UART_1 */
+&lpuart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ uart-has-rtscts;
+};
+
+/* Aquila UART_2 */
+&lpuart7 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart7>;
+ uart-has-rtscts;
+};
+
+&mu7 {
+ status = "okay";
+};
+
+/* Aquila ETH_2_XGMII_MDIO, shared between all ethernet ports */
+&netc_emdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_emdio>;
+
+ status = "okay";
+
+ ethphy1: ethernet-phy@1 {
+ reg = <1>;
+ interrupt-parent = <&som_gpio_expander_1>;
+ interrupts = <10 IRQ_TYPE_EDGE_FALLING>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
+ };
+};
+
+&netcmix_blk_ctrl {
+ status = "okay";
+};
+
+&netc_blk_ctrl {
+ status = "okay";
+};
+
+&netc_timer {
+ status = "okay";
+};
+
+/* Aquila PCIE_1 */
+&pcie0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie0>;
+ reset-gpios = <&som_gpio_expander_0 0 GPIO_ACTIVE_LOW>;
+};
+
+/* On-module Wi-Fi or Aquila PCIE_2 */
+&pcie1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie1>;
+ reset-gpios = <&som_gpio_expander_0 1 GPIO_ACTIVE_LOW>;
+
+ status = "okay";
+};
+
+/* Aquila I2S_1 */
+&sai2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai2>;
+ assigned-clocks = <&scmi_clk IMX95_CLK_AUDIOPLL1_VCO>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2_VCO>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL1>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL2>,
+ <&scmi_clk IMX95_CLK_SAI2>;
+ assigned-clock-parents = <0>, <0>, <0>, <0>,
+ <&scmi_clk IMX95_CLK_AUDIOPLL1>;
+ assigned-clock-rates = <3932160000>,
+ <3612672000>, <393216000>,
+ <361267200>, <12288000>;
+ #sound-dai-cells = <0>;
+ fsl,sai-mclk-direction-output;
+};
+
+&scmi_bbm {
+ linux,code = <KEY_POWER>;
+};
+
+&thermal_zones {
+ /* PF09 Main PMIC */
+ pf09-thermal {
+ polling-delay = <2000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&scmi_sensor 2>;
+
+ trips {
+ trip0 {
+ hysteresis = <2000>;
+ temperature = <155000>;
+ type = "critical";
+ };
+ };
+ };
+
+ /* PF53 VDD_ARM PMIC */
+ pf53-arm-thermal {
+ polling-delay = <2000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&scmi_sensor 4>;
+
+ trips {
+ trip0 {
+ hysteresis = <2000>;
+ temperature = <155000>;
+ type = "critical";
+ };
+ };
+ };
+
+ /* PF53 VDD_SOC PMIC */
+ pf53-soc-thermal {
+ polling-delay = <2000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&scmi_sensor 3>;
+
+ trips {
+ trip0 {
+ hysteresis = <2000>;
+ temperature = <155000>;
+ type = "critical";
+ };
+ };
+ };
+};
+
+/* Aquila PWM_1 */
+&tpm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+};
+
+/* Aquila PWM_2 */
+&tpm6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm2>;
+};
+
+/* Aquila PWM_3_DSI and PWM_4_DP */
+&tpm5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm3_dsi>, <&pinctrl_pwm4_dp>;
+};
+
+/* Aquila USB_2, optional Bluetooth USB */
+&usb2 {
+ dr_mode = "host";
+ vbus-supply = <®_usb2_vbus>;
+};
+
+/* Aquila USB_1 */
+&usb3 {
+ fsl,disable-port-power-control;
+};
+
+&usb3_dwc3 {
+ dr_mode = "otg";
+ adp-disable;
+ hnp-disable;
+ srp-disable;
+ usb-role-switch;
+};
+
+&usb3_phy {
+ vbus-supply = <®_usb1_vbus>;
+};
+
+/* On-module eMMC */
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ bus-width = <8>;
+ non-removable;
+ no-sdio;
+ no-sd;
+
+ status = "okay";
+};
+
+/* Aquila SD_1 */
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_sd1_cd_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2>, <&pinctrl_sd1_cd_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>,<&pinctrl_sd1_cd_gpio>;
+ pinctrl-3 = <&pinctrl_usdhc2_sleep>, <&pinctrl_sd1_cd_gpio>;
+ cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <®_usdhc2_vmmc>;
+ vqmmc-supply = <®_usdhc2_vqmmc>;
+};
+
+&wdog3 {
+ fsl,ext-reset-output;
+
+ status = "okay";
+};
+
+&scmi_iomuxc {
+ /* Aquila CTRL_WAKE1_MICO# */
+ pinctrl_ctrl_wake1_mico: ctrlwake1micogrp {
+ fsl,pins = <IMX95_PAD_XSPI1_SS1_B__GPIO5_IO_BIT11 0x31e>; /* Aquila D6 */
+ };
+
+ pinctrl_ctrl_dp_clk_en: dpclkengrp {
+ fsl,pins = <IMX95_PAD_SAI1_TXFS__AONMIX_TOP_GPIO1_IO_BIT11 0x11e>; /* CTRL_DP_CLK_EN */
+ };
+
+ /* Aquila ETH_2_XGMII_MDIO */
+ pinctrl_emdio: emdiogrp {
+ fsl,pins = <IMX95_PAD_ENET2_MDC__NETCMIX_TOP_NETC_MDC 0x57e>, /* Aquila B90 */
+ <IMX95_PAD_ENET2_MDIO__NETCMIX_TOP_NETC_MDIO 0x97e>; /* Aquila B89 */
+ };
+
+ /* Aquila ETH_1 */
+ pinctrl_enetc0: enetc0grp {
+ fsl,pins = <IMX95_PAD_ENET1_TX_CTL__NETCMIX_TOP_ETH0_RGMII_TX_CTL 0x57e>, /* ENET1_TX_CTL */
+ <IMX95_PAD_ENET1_TXC__NETCMIX_TOP_ETH0_RGMII_TX_CLK 0x58e>, /* ENET1_TXC */
+ <IMX95_PAD_ENET1_TD0__NETCMIX_TOP_ETH0_RGMII_TD0 0x50e>, /* ENET1_TDO */
+ <IMX95_PAD_ENET1_TD1__NETCMIX_TOP_ETH0_RGMII_TD1 0x50e>, /* ENET1_TD1 */
+ <IMX95_PAD_ENET1_TD2__NETCMIX_TOP_ETH0_RGMII_TD2 0x50e>, /* ENET1_TD2 */
+ <IMX95_PAD_ENET1_TD3__NETCMIX_TOP_ETH0_RGMII_TD3 0x50e>, /* ENET1_TD3 */
+ <IMX95_PAD_ENET1_RX_CTL__NETCMIX_TOP_ETH0_RGMII_RX_CTL 0x57e>, /* ENET1_RX_CTL */
+ <IMX95_PAD_ENET1_RXC__NETCMIX_TOP_ETH0_RGMII_RX_CLK 0x58e>, /* ENET1_RXC */
+ <IMX95_PAD_ENET1_RD0__NETCMIX_TOP_ETH0_RGMII_RD0 0x57e>, /* ENET1_RD0 */
+ <IMX95_PAD_ENET1_RD1__NETCMIX_TOP_ETH0_RGMII_RD1 0x57e>, /* ENET1_RD1 */
+ <IMX95_PAD_ENET1_RD2__NETCMIX_TOP_ETH0_RGMII_RD2 0x57e>, /* ENET1_RD2 */
+ <IMX95_PAD_ENET1_RD3__NETCMIX_TOP_ETH0_RGMII_RD3 0x57e>; /* ENET1_RD3 */
+ };
+
+ /* Aquila CAN_1 */
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <IMX95_PAD_PDM_CLK__AONMIX_TOP_CAN1_TX 0x39e>, /* Aquila B48 */
+ <IMX95_PAD_PDM_BIT_STREAM0__AONMIX_TOP_CAN1_RX 0x39e>; /* Aquila B49 */
+ };
+
+ /* Aquila CAN_2 */
+ pinctrl_flexcan2: flexcan2grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO25__CAN2_TX 0x39e>, /* Aquila B50 */
+ <IMX95_PAD_GPIO_IO27__CAN2_RX 0x39e>; /* Aquila B51 */
+ };
+
+ /* Aquila CAN_3 */
+ pinctrl_flexcan3: flexcan3grp {
+ fsl,pins = <IMX95_PAD_CCM_CLKO3__CAN3_TX 0x39e>, /* Aquila B53 */
+ <IMX95_PAD_CCM_CLKO4__CAN3_RX 0x39e>; /* Aquila B54 */
+ };
+
+ /* Aquila CAN_4 */
+ pinctrl_flexcan4: flexcan4grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO04__CAN4_TX 0x39e>, /* Aquila B55 */
+ <IMX95_PAD_GPIO_IO05__CAN4_RX 0x39e>; /* Aquila B56 */
+ };
+
+ /* Aquila QSPI_1 (8 bit) */
+ pinctrl_flexspi1_8bit: flexspi18bitgrp {
+ fsl,pins = <IMX95_PAD_XSPI1_SCLK__FLEXSPI1_A_SCLK 0x3fe>, /* Aquila B65 */
+ <IMX95_PAD_XSPI1_DATA0__FLEXSPI1_A_DATA_BIT0 0x3fe>, /* Aquila B68 */
+ <IMX95_PAD_XSPI1_DATA1__FLEXSPI1_A_DATA_BIT1 0x3fe>, /* Aquila B67 */
+ <IMX95_PAD_XSPI1_DATA2__FLEXSPI1_A_DATA_BIT2 0x3fe>, /* Aquila B61 */
+ <IMX95_PAD_XSPI1_DATA3__FLEXSPI1_A_DATA_BIT3 0x3fe>, /* Aquila B60 */
+ <IMX95_PAD_XSPI1_DATA4__FLEXSPI1_A_DATA_BIT4 0x3fe>, /* Aquila B70 */
+ <IMX95_PAD_XSPI1_DATA5__FLEXSPI1_A_DATA_BIT5 0x3fe>, /* Aquila B71 */
+ <IMX95_PAD_XSPI1_DATA6__FLEXSPI1_A_DATA_BIT6 0x3fe>, /* Aquila B72 */
+ <IMX95_PAD_XSPI1_DATA7__FLEXSPI1_A_DATA_BIT7 0x3fe>, /* Aquila B73 */
+ <IMX95_PAD_XSPI1_DQS__FLEXSPI1_A_DQS 0x3fe>; /* Aquila B63 */
+ };
+
+ /* Aquila QSPI_1 (4 bit) */
+ pinctrl_flexspi1_4bit: flexspi18bitgrp {
+ fsl,pins = <IMX95_PAD_XSPI1_SCLK__FLEXSPI1_A_SCLK 0x3fe>, /* Aquila B65 */
+ <IMX95_PAD_XSPI1_DATA0__FLEXSPI1_A_DATA_BIT0 0x3fe>, /* Aquila B68 */
+ <IMX95_PAD_XSPI1_DATA1__FLEXSPI1_A_DATA_BIT1 0x3fe>, /* Aquila B67 */
+ <IMX95_PAD_XSPI1_DATA2__FLEXSPI1_A_DATA_BIT2 0x3fe>, /* Aquila B61 */
+ <IMX95_PAD_XSPI1_DATA3__FLEXSPI1_A_DATA_BIT3 0x3fe>, /* Aquila B60 */
+ <IMX95_PAD_XSPI1_DQS__FLEXSPI1_A_DQS 0x3fe>; /* Aquila B63 */
+ };
+
+ /* Aquila GPIO_01 */
+ pinctrl_gpio_1: gpio1grp {
+ fsl,pins = <IMX95_PAD_ENET2_RD0__GPIO4_IO_BIT24 0x31e>; /* Aquila D23 */
+ };
+
+ /* Aquila GPIO_02 */
+ pinctrl_gpio_2: gpio2grp {
+ fsl,pins = <IMX95_PAD_ENET2_RD1__GPIO4_IO_BIT25 0x31e>; /* Aquila D24 */
+ };
+
+ /* Aquila GPIO_03 */
+ pinctrl_gpio_3: gpio3grp {
+ fsl,pins = <IMX95_PAD_ENET2_RD3__GPIO4_IO_BIT27 0x31e>; /* Aquila D25 */
+ };
+
+ /* Aquila GPIO_04 */
+ pinctrl_gpio_4: gpio4grp {
+ fsl,pins = <IMX95_PAD_ENET2_TD0__GPIO4_IO_BIT19 0x31e>; /* Aquila C20 */
+ };
+
+ /* Aquila GPIO_05 */
+ pinctrl_gpio_5: gpio5grp {
+ fsl,pins = <IMX95_PAD_ENET2_TD1__GPIO4_IO_BIT18 0x31e>; /* Aquila C21 */
+ };
+
+ /* Aquila GPIO_06 */
+ pinctrl_gpio_6: gpio6grp {
+ fsl,pins = <IMX95_PAD_ENET2_TD2__GPIO4_IO_BIT17 0x31e>; /* Aquila C22 */
+ };
+
+ /* Aquila GPIO_07 */
+ pinctrl_gpio_7: gpio7grp {
+ fsl,pins = <IMX95_PAD_ENET2_RXC__GPIO4_IO_BIT23 0x31e>; /* Aquila C23 */
+ };
+
+ /* Aquila GPIO_08 */
+ pinctrl_gpio_8: gpio8grp {
+ fsl,pins = <IMX95_PAD_PDM_BIT_STREAM1__AONMIX_TOP_GPIO1_IO_BIT10 0x31e>; /* Aquila C24 */
+ };
+
+ /* Aquila GPIO_09_CSI_1 */
+ pinctrl_gpio_9_csi_1: gpio9csi1grp {
+ fsl,pins = <IMX95_PAD_SAI1_TXC__AONMIX_TOP_GPIO1_IO_BIT12 0x31e>; /* Aquila B17 */
+ };
+
+ /* Aquila GPIO_10_CSI_1 */
+ pinctrl_gpio_10_csi_1: gpio10csi1grp {
+ fsl,pins = <IMX95_PAD_SAI1_RXD0__AONMIX_TOP_GPIO1_IO_BIT14 0x31e>; /* Aquila B18 */
+ };
+
+ /* Aquila GPIO_11_CSI_1 */
+ pinctrl_gpio_11_csi_1: gpio11csi1grp {
+ fsl,pins = <IMX95_PAD_SD2_VSELECT__GPIO3_IO_BIT19 0x31e>; /* Aquila A11*/
+ };
+
+ /* Aquila GPIO_12_CSI_1 */
+ pinctrl_gpio_12_csi_1: gpio12csi1grp {
+ fsl,pins = <IMX95_PAD_SD3_DATA0__GPIO3_IO_BIT22 0x31e>; /* Aquila B19 */
+ };
+
+ /* Aquila GPIO_17_DSI_1 */
+ pinctrl_gpio_17_dsi_1: gpio17dsi1grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO07__GPIO2_IO_BIT7 0x31e>; /* Aquila B42 */
+ };
+
+ /* Aquila GPIO_18_DSI_1 */
+ pinctrl_gpio_18_dsi_1: gpio18dsi1grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO09__GPIO2_IO_BIT9 0x31e>; /* Aquila B43 */
+ };
+
+ /* Aquila GPIO_19_DSI_1 */
+ pinctrl_gpio_19_dsi_1: gpio19dsi1grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO33__GPIO5_IO_BIT13 0x31e>; /* Aquila B44 */
+ };
+
+ /* Aquila GPIO_20_DSI_1 */
+ pinctrl_gpio_20_dsi_1: gpio20dsi1grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO34__GPIO5_IO_BIT14 0x31e>; /* Aquila B45 */
+ };
+
+ /* Aquila GPIO_21_DP */
+ pinctrl_gpio_21_dp: gpio21dpgrp {
+ fsl,pins = <IMX95_PAD_SD3_CMD__GPIO3_IO_BIT21 0x31e>; /* Aquila B57 */
+ };
+
+ pinctrl_ctrl_gpio_exp_int: gpioexpintgrp {
+ fsl,pins = <IMX95_PAD_SAI1_TXD0__AONMIX_TOP_GPIO1_IO_BIT13 0x31e>; /* CTRL_GPIO_EXP_INT# */
+ };
+
+ /* Aquila I2C_2 */
+ pinctrl_i3c2: i3c2cgrp {
+ fsl,pins = <IMX95_PAD_ENET1_MDC__I3C2_SCL 0x40001186>, /* Aquila C17 */
+ <IMX95_PAD_ENET1_MDIO__I3C2_SDA 0x40001186>; /* Aquila C16 */
+ };
+
+ /* Aquila I2C_1 as GPIOs */
+ pinctrl_lpi2c2_gpio: lpi2c2gpiogrp {
+ fsl,pins = <IMX95_PAD_I2C2_SCL__AONMIX_TOP_GPIO1_IO_BIT2 0x40001b9e>, /* Aquila D8 */
+ <IMX95_PAD_I2C2_SDA__AONMIX_TOP_GPIO1_IO_BIT3 0x40001b9e>; /* Aquila D7 */
+ };
+
+ /* Aquila I2C_1 */
+ pinctrl_lpi2c2: lpi2c2grp {
+ fsl,pins = <IMX95_PAD_I2C2_SCL__AONMIX_TOP_LPI2C2_SCL 0x40001b9e>, /* Aquila D8 */
+ <IMX95_PAD_I2C2_SDA__AONMIX_TOP_LPI2C2_SDA 0x40001b9e>; /* Aquila D7 */
+ };
+
+ /* On-module I2C as GPIOs */
+ pinctrl_lpi2c3_gpio: lpi2c3gpiogrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO28__GPIO2_IO_BIT28 0x40001b9e>, /* I2C_SOM_SDA */
+ <IMX95_PAD_GPIO_IO29__GPIO2_IO_BIT29 0x40001b9e>; /* I2C_SOM_SCL */
+ };
+
+ /* On-module I2C */
+ pinctrl_lpi2c3: lpi2c3grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO28__LPI2C3_SDA 0x40001b9e>, /* I2C_SOM_SDA */
+ <IMX95_PAD_GPIO_IO29__LPI2C3_SCL 0x40001b9e>; /* I2C_SOM_SCL */
+ };
+
+ /* Aquila I2C_4_CSI1 as GPIO */
+ pinctrl_lpi2c4_gpio: lpi2c4gpiogrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO30__GPIO2_IO_BIT30 0x40001b9e>, /* Aquila A12 */
+ <IMX95_PAD_GPIO_IO31__GPIO2_IO_BIT31 0x40001b9e>; /* Aquila A13 */
+ };
+
+ /* Aquila I2C_4_CSI1 */
+ pinctrl_lpi2c4: lpi2c4grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO30__LPI2C4_SDA 0x40001b9e>, /* Aquila A12 */
+ <IMX95_PAD_GPIO_IO31__LPI2C4_SCL 0x40001b9e>; /* Aquila A13 */
+ };
+
+ /* Aquila I2C_6 as GPIO */
+ pinctrl_lpi2c5_gpio: lpi2c5gpiogrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO22__GPIO2_IO_BIT22 0x40001b9e>, /* Aquila C18 */
+ <IMX95_PAD_GPIO_IO23__GPIO2_IO_BIT23 0x40001b9e>; /* Aquila C19 */
+ };
+
+ /* Aquila I2C_6 */
+ pinctrl_lpi2c5: lpi2c5grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO22__LPI2C5_SDA 0x40001b9e>, /* Aquila C18 */
+ <IMX95_PAD_GPIO_IO23__LPI2C5_SCL 0x40001b9e>; /* Aquila C19 */
+ };
+
+ /* Aquila I2C_3_DSI1/I2C_5_CSI2 as GPIO */
+ pinctrl_lpi2c8_gpio: lpi2c8gpiogrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO12__GPIO2_IO_BIT12 0x40001b9e>, /* Aquila C5/B40 */
+ <IMX95_PAD_GPIO_IO13__GPIO2_IO_BIT13 0x40001b9e>; /* Aquila C6/B41 */
+ };
+
+ /* Aquila I2C_3_DSI1/I2C_5_CSI2 */
+ pinctrl_lpi2c8: lpi2c8grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO12__LPI2C8_SDA 0x40001b9e>, /* Aquila C5/B40 */
+ <IMX95_PAD_GPIO_IO13__LPI2C8_SCL 0x40001b9e>; /* Aquila C6/B41 */
+ };
+
+ /* Aquila SPI_2 */
+ pinctrl_lpspi4: lpspi4grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO18__GPIO2_IO_BIT18 0x3fe>, /* Aquila D16 */
+ <IMX95_PAD_GPIO_IO19__LPSPI4_SIN 0x3fe>, /* Aquila D15 */
+ <IMX95_PAD_GPIO_IO20__LPSPI4_SOUT 0x3fe>, /* Aquila D17 */
+ <IMX95_PAD_GPIO_IO21__LPSPI4_SCK 0x3fe>; /* Aquila D14 */
+ };
+
+ /* Aquila SPI_1 */
+ pinctrl_lpspi6: lpspi6grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO00__GPIO2_IO_BIT0 0x3fe>, /* Aquila D9 */
+ <IMX95_PAD_GPIO_IO01__LPSPI6_SIN 0x3fe>, /* Aquila D10 */
+ <IMX95_PAD_GPIO_IO02__LPSPI6_SOUT 0x3fe>, /* Aquila D11 */
+ <IMX95_PAD_GPIO_IO03__LPSPI6_SCK 0x3fe>; /* Aquila D12 */
+ };
+
+ /* Aquila PCIE_1 */
+ pinctrl_pcie0: pcie0grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO32__HSIOMIX_TOP_PCIE1_CLKREQ_B 0x40001b1e>; /* Aquila C37 */
+ };
+
+ /* Aquila PCIE_2 */
+ pinctrl_pcie1: pcie1grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO35__HSIOMIX_TOP_PCIE2_CLKREQ_B 0x40001b1e>; /* Aquila C34 */
+ };
+
+ /* Aquila QSPI_1_CS1# */
+ pinctrl_qspi_cs1: qspics1grp {
+ fsl,pins = <IMX95_PAD_XSPI1_SS0_B__FLEXSPI1_A_SS0_B 0x3fe>; /* Aquila B66 */
+ };
+
+ /* Aquila QSPI_1_CS2# as GPIO */
+ pinctrl_qspi_cs2_gpio: qspics2gpiogrp {
+ fsl,pins = <IMX95_PAD_CCM_CLKO2__GPIO3_IO_BIT27 0x3fe>; /* Aquila B62 */
+ };
+
+ /* Aquila I2S_1 */
+ pinctrl_sai2: sai2grp {
+ fsl,pins = <IMX95_PAD_ENET2_TX_CTL__NETCMIX_TOP_SAI2_TX_SYNC 0x11e>, /* Aquila B21 */
+ <IMX95_PAD_ENET2_TXC__NETCMIX_TOP_SAI2_TX_BCLK 0x11e>, /* Aquila B20 */
+ <IMX95_PAD_ENET2_TD3__NETCMIX_TOP_SAI2_RX_DATA_BIT0 0x11e>, /* Aquila B23 */
+ <IMX95_PAD_ENET2_RX_CTL__NETCMIX_TOP_SAI2_TX_DATA_BIT0 0x11e>; /* Aquila B22 */
+ };
+
+ pinctrl_sai2_mclk: sai2mclkgrp {
+ fsl,pins = <IMX95_PAD_ENET2_RD2__NETCMIX_TOP_SAI2_MCLK 0x31e>; /* Aquila B24 */
+ };
+
+ /* Aquila SD_1_CD# as GPIO */
+ pinctrl_sd1_cd_gpio: sd1cdgpiogrp {
+ fsl,pins = <IMX95_PAD_SD2_CD_B__GPIO3_IO_BIT0 0x1100>; /* Aquila A1 */
+ };
+
+ /* Aquila SD_1_PWR_EN */
+ pinctrl_sd1_pwr_en: sd1pwrengpiogrp {
+ fsl,pins = <IMX95_PAD_SD2_RESET_B__GPIO3_IO_BIT7 0x11e>; /* Aquila A6 */
+ };
+
+ /* Aquila PWM_1 */
+ pinctrl_pwm1: tpm3ch3grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO24__TPM3_CH3 0x11e>; /* Aquila C25 */
+ };
+
+ /* Aquila PWM_3_DSI as GPIO */
+ pinctrl_pwm3_dsi_gpio: tpm5ch0gpiogrp {
+ fsl,pins = <IMX95_PAD_GPIO_IO06__GPIO2_IO_BIT6 0x11e>; /* Aquila B46 */
+ };
+
+ /* Aquila PWM_3_DSI */
+ pinctrl_pwm3_dsi: tpm5ch0grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO06__TPM5_CH0 0x11e>; /* Aquila B46 */
+ };
+
+ /* Aquila PWM_4_DP */
+ pinctrl_pwm4_dp: tpm5ch3grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO26__TPM5_CH3 0x11e>; /* Aquila B58 */
+ };
+
+ /* Aquila PWM_2 */
+ pinctrl_pwm2: tpm6ch0grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO08__TPM6_CH0 0x11e>; /* Aquila C26 */
+ };
+
+ /* Aquila UART_3 */
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <IMX95_PAD_UART1_TXD__AONMIX_TOP_LPUART1_TX 0x31e>, /* Aquila D20 */
+ <IMX95_PAD_UART1_RXD__AONMIX_TOP_LPUART1_RX 0x31e>; /* Aquila D19 */
+ };
+
+ /* Aquila UART_4 */
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <IMX95_PAD_UART2_TXD__AONMIX_TOP_LPUART2_TX 0x31e>, /* Aquila D22 */
+ <IMX95_PAD_UART2_RXD__AONMIX_TOP_LPUART2_RX 0x31e>; /* Aquila D21 */
+ };
+
+ /* Aquila UART_1 */
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO14__LPUART3_TX 0x31e>, /* Aquila B37 */
+ <IMX95_PAD_GPIO_IO15__LPUART3_RX 0x31e>, /* Aquila B35 */
+ <IMX95_PAD_GPIO_IO16__LPUART3_CTS_B 0x31e>, /* Aquila B36 */
+ <IMX95_PAD_GPIO_IO17__LPUART3_RTS_B 0x31e>; /* Aquila B38 */
+ };
+
+ /* Aquila UART_2 */
+ pinctrl_uart7: uart7grp {
+ fsl,pins = <IMX95_PAD_GPIO_IO36__LPUART7_TX 0x31e>, /* Aquila B33 */
+ <IMX95_PAD_GPIO_IO37__LPUART7_RX 0x31e>, /* Aquila B31 */
+ <IMX95_PAD_GPIO_IO10__LPUART7_CTS_B 0x31e>, /* Aquila B32 */
+ <IMX95_PAD_GPIO_IO11__LPUART7_RTS_B 0x31e>; /* Aquila B34 */
+ };
+
+ /* On-module eMMC */
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x158e>, /* eMMC_CLK */
+ <IMX95_PAD_SD1_CMD__USDHC1_CMD 0x138e>, /* eMMC_CMD */
+ <IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x138e>, /* eMMC_DATA0 */
+ <IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x138e>, /* eMMC_DATA1 */
+ <IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x138e>, /* eMMC_DATA2 */
+ <IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x138e>, /* eMMC_DATA3 */
+ <IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x138e>, /* eMMC_DATA4 */
+ <IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x138e>, /* eMMC_DATA5 */
+ <IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x138e>, /* eMMC_DATA6 */
+ <IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x138e>, /* eMMC_DATA7 */
+ <IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x158e>; /* eMMC_STROBE */
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+ fsl,pins = <IMX95_PAD_SD1_CLK__USDHC1_CLK 0x15fe>, /* eMMC_CLK */
+ <IMX95_PAD_SD1_CMD__USDHC1_CMD 0x13fe>, /* eMMC_CMD */
+ <IMX95_PAD_SD1_DATA0__USDHC1_DATA0 0x13fe>, /* eMMC_DATA0 */
+ <IMX95_PAD_SD1_DATA1__USDHC1_DATA1 0x13fe>, /* eMMC_DATA1 */
+ <IMX95_PAD_SD1_DATA2__USDHC1_DATA2 0x13fe>, /* eMMC_DATA2 */
+ <IMX95_PAD_SD1_DATA3__USDHC1_DATA3 0x13fe>, /* eMMC_DATA3 */
+ <IMX95_PAD_SD1_DATA4__USDHC1_DATA4 0x13fe>, /* eMMC_DATA4 */
+ <IMX95_PAD_SD1_DATA5__USDHC1_DATA5 0x13fe>, /* eMMC_DATA5 */
+ <IMX95_PAD_SD1_DATA6__USDHC1_DATA6 0x13fe>, /* eMMC_DATA6 */
+ <IMX95_PAD_SD1_DATA7__USDHC1_DATA7 0x13fe>, /* eMMC_DATA7 */
+ <IMX95_PAD_SD1_STROBE__USDHC1_STROBE 0x15fe>; /* eMMC_STROBE */
+ };
+
+ /* Aquila SD_1 */
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x158e>, /* Aquila A5 */
+ <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x138e>, /* Aquila A7 */
+ <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x138e>, /* Aquila A3 */
+ <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x138e>, /* Aquila A2 */
+ <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x138e>, /* Aquila A10 */
+ <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x138e>; /* Aquila A8 */
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x15fe>, /* Aquila A5 */
+ <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x13fe>, /* Aquila A7 */
+ <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x13fe>, /* Aquila A3 */
+ <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x13fe>, /* Aquila A2 */
+ <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x13fe>, /* Aquila A10 */
+ <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x13fe>; /* Aquila A8 */
+ };
+
+ pinctrl_usdhc2_sleep: usdhc2-sleepgrp {
+ fsl,pins = <IMX95_PAD_SD2_CLK__USDHC2_CLK 0x400>, /* Aquila A5 */
+ <IMX95_PAD_SD2_CMD__USDHC2_CMD 0x400>, /* Aquila A7 */
+ <IMX95_PAD_SD2_DATA0__USDHC2_DATA0 0x400>, /* Aquila A3 */
+ <IMX95_PAD_SD2_DATA1__USDHC2_DATA1 0x400>, /* Aquila A2 */
+ <IMX95_PAD_SD2_DATA2__USDHC2_DATA2 0x400>, /* Aquila A10 */
+ <IMX95_PAD_SD2_DATA3__USDHC2_DATA3 0x400>; /* Aquila A8 */
+ };
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: arm: fsl: add Aquila iMX95
From: Franz Schnyder @ 2026-05-20 11:30 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel,
Francesco Dolcini, Franz Schnyder, Conor Dooley
In-Reply-To: <20260520-add-aquila-imx95-v2-0-06424a51e33a@toradex.com>
From: Franz Schnyder <franz.schnyder@toradex.com>
Add DT compatible strings for the Aquila i.MX95 SoM and its supported
carrier boards: the Aquila Development Board and the Clover carrier
board.
Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
Link: https://www.toradex.com/products/carrier-board/aquila-development-board-kit
Link: https://www.toradex.com/products/carrier-board/clover
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
v2: Added Conor's acked-by
v1: https://lore.kernel.org/all/20260506-add-aquila-imx95-v1-1-69c8ee1c5413@toradex.com/
---
Documentation/devicetree/bindings/arm/fsl.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 59f7f168bf7c4..ea4cc98dadebc 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1507,6 +1507,14 @@ properties:
- const: phytec,imx95-phycore-fpsc # phyCORE-i.MX 95 FPSC
- const: fsl,imx95
+ - description: Toradex Boards with Aquila iMX95 Modules
+ items:
+ - enum:
+ - toradex,aquila-imx95-clover # Aquila iMX95 Module on Clover Board
+ - toradex,aquila-imx95-dev # Aquila iMX95 Module on Aquila Development Board
+ - const: toradex,aquila-imx95 # Aquila iMX95 Module
+ - const: fsl,imx95
+
- description: Toradex Boards with SMARC iMX95 Modules
items:
- const: toradex,smarc-imx95-dev # Toradex SMARC iMX95 on Toradex SMARC Development Board
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/3] arm64: dts: freescale: imx95-aquila: Add Clover carrier board
From: Franz Schnyder @ 2026-05-20 11:30 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel,
Francesco Dolcini, Franz Schnyder, Antoine Gouby
In-Reply-To: <20260520-add-aquila-imx95-v2-0-06424a51e33a@toradex.com>
From: Antoine Gouby <antoine.gouby@toradex.com>
Add support for the Aquila i.MX95 SoM mated with the Clover carrier
board. Clover is a low-cost carrier board for the Aquila family
featuring a small form factor (Nano-ITX 120mm x 120mm) and built for
volume production.
Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
Link: https://www.toradex.com/products/carrier-board/clover
Signed-off-by: Antoine Gouby <antoine.gouby@toradex.com>
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
v2: no changes
v1: https://lore.kernel.org/all/20260506-add-aquila-imx95-v1-3-69c8ee1c5413@toradex.com/
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../boot/dts/freescale/imx95-aquila-clover.dts | 294 +++++++++++++++++++++
2 files changed, 295 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index c8697b6ae01c5..3ce082c121036 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -523,6 +523,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk-sof.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx95-aquila-clover.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-aquila-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-toradex-smarc-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-tqma9596sa-mb-smarc-2.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx95-aquila-clover.dts b/arch/arm64/boot/dts/freescale/imx95-aquila-clover.dts
new file mode 100644
index 0000000000000..021d437763412
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-aquila-clover.dts
@@ -0,0 +1,294 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
+ * https://www.toradex.com/products/carrier-board/clover
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/usb/pd.h>
+#include "imx95-aquila.dtsi"
+
+/ {
+ model = "Aquila iMX95 on Aquila Clover Board";
+ compatible = "toradex,aquila-imx95-clover",
+ "toradex,aquila-imx95",
+ "fsl,imx95";
+
+ aliases {
+ eeprom1 = &carrier_eeprom;
+ };
+
+ dp_1_connector: dp0-connector {
+ compatible = "dp-connector";
+ dp-pwr-supply = <®_dp_3p3v>;
+ type = "full-size";
+
+ port {
+ dp_1_connector_in: endpoint {
+ remote-endpoint = <&dsi2dp_out>;
+ };
+ };
+ };
+
+ reg_dp_3p3v: regulator-dp-3p3v {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_21_dp>;
+ /* Aquila GPIO_21_DP */
+ gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "DP_3V3";
+ startup-delay-us = <10000>;
+ };
+};
+
+/* Aquila ADC_[1-4] */
+&adc1 {
+ status = "okay";
+};
+
+/* Aquila CTRL_WAKE1_MICO# */
+&aquila_key_wake {
+ status = "okay";
+};
+
+&dsi2dp_out {
+ remote-endpoint = <&dp_1_connector_in>;
+};
+
+/* Aquila ETH_1 */
+&enetc_port0 {
+ status = "okay";
+};
+
+/* Aquila CAN_1 */
+&flexcan1 {
+ status = "okay";
+};
+
+/* Aquila CAN_2 */
+&flexcan2 {
+ status = "okay";
+};
+
+/* Aquila CAN_3 */
+&flexcan3 {
+ status = "okay";
+};
+
+/* Aquila CAN_4 */
+&flexcan4 {
+ status = "okay";
+};
+
+/* Aquila QSPI_1 */
+&flexspi1 {
+ pinctrl-0 = <&pinctrl_flexspi1_4bit>,
+ <&pinctrl_qspi_cs1>;
+
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-max-frequency = <66000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
+ cdns,read-delay = <0>;
+ cdns,tchsh-ns = <3>;
+ cdns,tsd2d-ns = <10>;
+ cdns,tshsl-ns = <30>;
+ cdns,tslch-ns = <8>;
+ };
+};
+
+&gpio4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_1>,
+ <&pinctrl_gpio_2>,
+ <&pinctrl_gpio_3>,
+ <&pinctrl_gpio_4>;
+};
+
+/* Aquila I2C_2 */
+&i3c2 {
+ status = "okay";
+};
+
+/* Aquila I2C_1 */
+&lpi2c2 {
+ status = "okay";
+
+ fan_controller: fan@18 {
+ compatible = "ti,amc6821";
+ reg = <0x18>;
+ #pwm-cells = <2>;
+
+ fan {
+ cooling-levels = <255>;
+ pwms = <&fan_controller 40000 PWM_POLARITY_INVERTED>;
+ };
+ };
+
+ temperature-sensor@4f {
+ compatible = "ti,tmp1075";
+ reg = <0x4f>;
+ };
+
+ /* USB-C OTG (TCPC USB PD PHY) */
+ tcpc@52 {
+ compatible = "nxp,ptn5110", "tcpci";
+ reg = <0x52>;
+ interrupt-parent = <&som_gpio_expander_1>;
+ interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
+
+ connector {
+ compatible = "usb-c-connector";
+ data-role = "dual";
+ op-sink-microwatt = <0>;
+ power-role = "dual";
+ self-powered;
+ sink-pdos = <PDO_FIXED(5000, 0, PDO_FIXED_USB_COMM)>;
+ source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ try-power-role = "sink";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ typec_con_hs: endpoint {
+ remote-endpoint = <&usb1_con_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ typec_con_ss: endpoint {
+ remote-endpoint = <&usb1_con_ss>;
+ };
+ };
+ };
+ };
+ };
+
+ carrier_eeprom: eeprom@57 {
+ compatible = "st,24c02", "atmel,24c02";
+ reg = <0x57>;
+ pagesize = <16>;
+ };
+};
+
+/* Aquila I2C_6 */
+&lpi2c5 {
+ status = "okay";
+};
+
+/* Aquila SPI_1 */
+&lpspi6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi6 &pinctrl_gpio_5>;
+ cs-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>, <&gpio4 18 GPIO_ACTIVE_LOW>;
+
+ status = "okay";
+
+ tpm@1 {
+ compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+ reg = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_6>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
+ spi-max-frequency = <12000000>;
+ };
+};
+
+/* Aquila UART_3, used as the Linux Console */
+&lpuart1 {
+ status = "okay";
+};
+
+/* Aquila UART_4 */
+&lpuart2 {
+ status = "okay";
+};
+
+/* Aquila UART_1 */
+&lpuart3 {
+ status = "okay";
+};
+
+/* Aquila UART_2 */
+&lpuart7 {
+ status = "okay";
+};
+
+/* Aquila PCIE_1 */
+&pcie0 {
+ status = "okay";
+};
+
+&som_dsi2dp_bridge {
+ status = "okay";
+};
+
+/* Aquila PWM_1 */
+&tpm3 {
+ status = "okay";
+};
+
+/* Aquila PWM_3_DSI and PWM_4_DP */
+&tpm5 {
+ status = "okay";
+};
+
+/* Aquila PWM_2 */
+&tpm6 {
+ status = "okay";
+};
+
+/* Aquila USB_2, optional Bluetooth USB */
+&usb2 {
+ status = "okay";
+};
+
+/* Aquila USB_1 */
+&usb3 {
+ status = "okay";
+};
+
+&usb3_dwc3 {
+ status = "okay";
+
+ port {
+ usb1_con_hs: endpoint {
+ remote-endpoint = <&typec_con_hs>;
+ };
+ };
+};
+
+&usb3_phy {
+ orientation-switch;
+
+ status = "okay";
+
+ port {
+ usb1_con_ss: endpoint {
+ remote-endpoint = <&typec_con_ss>;
+ };
+ };
+};
+
+/* Aquila SD_1 */
+&usdhc2 {
+ status = "okay";
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/3] arm64: dts: freescale: add Toradex Aquila iMX95
From: Franz Schnyder @ 2026-05-20 11:30 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel,
Francesco Dolcini, Franz Schnyder, Conor Dooley,
João Paulo Gonçalves, Emanuele Ghidoli,
Francesco Dolcini, Antoine Gouby, Ernest Van Hoecke
This patch series adds support for the Toradex Aquila i.MX95 SoM and its
currently available carrier boards: the Aquila Development Board and the
Clover carrier board.
The module consists of an NXP i.MX95 family SoC, up to 16GB LPDDR5 RAM,
up to 128GB of storage, a USB 3.2 OTG and USB 2.0 Host, a Gigabit
Ethernet PHY, a 10 Gigabit Ethernet interface, an I2C EEPROM and
Temperature Sensor, an RX8130 RTC, one Quad lane CSI interface, one Quad
lane DSI or CSI interface, one LVDS interface (one or two channels), and
some optional addons: DisplayPort (through a DSI-DP bridge), TPM 2.0,
and a WiFi/BT module.
Link: https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95
Link: https://www.toradex.com/products/carrier-board/aquila-development-board-kit
Link: https://www.toradex.com/products/carrier-board/clover
Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com>
---
Changes in v2:
- Add 'acked-by' tag from Conor to the bindings patch
- Reordering iomux by node name
- Changed Francesco's tags to have the Toradex mail address
- Link to v1: https://lore.kernel.org/r/20260506-add-aquila-imx95-v1-0-69c8ee1c5413@toradex.com
---
Antoine Gouby (1):
arm64: dts: freescale: imx95-aquila: Add Clover carrier board
Franz Schnyder (1):
dt-bindings: arm: fsl: add Aquila iMX95
João Paulo Gonçalves (1):
arm64: dts: freescale: add Aquila iMX95 support
Documentation/devicetree/bindings/arm/fsl.yaml | 8 +
arch/arm64/boot/dts/freescale/Makefile | 2 +
.../boot/dts/freescale/imx95-aquila-clover.dts | 294 +++++
arch/arm64/boot/dts/freescale/imx95-aquila-dev.dts | 398 +++++++
arch/arm64/boot/dts/freescale/imx95-aquila.dtsi | 1160 ++++++++++++++++++++
5 files changed, 1862 insertions(+)
---
base-commit: 596d0f9f4fefffbf783ab26cfa90cf50f5dd6bb0
change-id: 20260501-add-aquila-imx95-423256af3d21
Best regards,
--
Franz Schnyder <franz.schnyder@toradex.com>
^ permalink raw reply
* [PATCH v4 1/1] dt-bindings: remoteproc: mtk,scp: Allow multiple memory regions for MT8188
From: Arnab Layek @ 2026-05-20 11:26 UTC (permalink / raw)
To: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
andersson, mathieu.poirier, linux-remoteproc,
Project_Global_Chrome_Upstream_Group, Arnab Layek
In-Reply-To: <20260520112629.3420612-1-arnab.layek@mediatek.com>
The MT8188 SCP can use either one or two reserved memory regions:
- Required: Main SCP SRAM memory region (mandatory for SCP operation)
- Optional: SCP L1TCM memory region (Level 1 Tightly Coupled Memory,
used for performance optimization when available, but not required
for basic SCP functionality)
Other MediaTek SoCs (MT8183, MT8186, MT8192, MT8195) use only a single
memory region and must remain restricted to one region for backward
compatibility.
Update the base schema to allow 1-2 memory regions (minItems: 1,
maxItems: 2), following the pattern used by other MediaTek dt-bindings
like mediatek,vcodec-encoder.yaml where the base property defines a
permissive range accommodating all device variants.
Add two conditionals:
1. Explicitly restrict non-MT8188 devices to maxItems: 1
2. Document MT8188's two regions with descriptions (minItems: 1 makes
the L1TCM region optional, allowing boards to specify 1-2 regions
based on hardware configuration)
This approach maintains backward compatibility while enabling MT8188 to
specify 1-2 memory regions depending on board design and performance
requirements.
Signed-off-by: Arnab Layek <arnab.layek@mediatek.com>
---
.../bindings/remoteproc/mtk,scp.yaml | 45 ++++++++++++++++++-
1 file changed, 43 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
index bdbb12118da4..fca9b0675eae 100644
--- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
@@ -55,7 +55,8 @@ properties:
initializing SCP.
memory-region:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
cros-ec-rpmsg:
$ref: /schemas/embedded-controller/google,cros-ec.yaml
@@ -123,7 +124,8 @@ patternProperties:
initializing sub cores of multi-core SCP.
memory-region:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
cros-ec-rpmsg:
$ref: /schemas/embedded-controller/google,cros-ec.yaml
@@ -205,6 +207,45 @@ allOf:
items:
- const: cfg
- const: l1tcm
+ - if:
+ properties:
+ compatible:
+ enum:
+ - mediatek,mt8183-scp
+ - mediatek,mt8186-scp
+ - mediatek,mt8192-scp
+ - mediatek,mt8195-scp
+ - mediatek,mt8195-scp-dual
+ then:
+ properties:
+ memory-region:
+ maxItems: 1
+ patternProperties:
+ "^scp@[a-f0-9]+$":
+ properties:
+ memory-region:
+ maxItems: 1
+ - if:
+ properties:
+ compatible:
+ enum:
+ - mediatek,mt8188-scp
+ - mediatek,mt8188-scp-dual
+ then:
+ properties:
+ memory-region:
+ minItems: 1
+ items:
+ - description: Main SCP SRAM memory region
+ - description: Optional SCP L1TCM memory region
+ patternProperties:
+ "^scp@[a-f0-9]+$":
+ properties:
+ memory-region:
+ minItems: 1
+ items:
+ - description: Main SCP SRAM memory region
+ - description: Optional SCP L1TCM memory region
additionalProperties: false
--
2.45.2
^ permalink raw reply related
* [PATCH v4 0/1] dt-bindings: remoteproc: mtk,scp: Allow multiple memory regions for MT8188
From: Arnab Layek @ 2026-05-20 11:26 UTC (permalink / raw)
To: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
andersson, mathieu.poirier, linux-remoteproc,
Project_Global_Chrome_Upstream_Group, Arnab Layek
This patch updates the mtk,scp dt-binding schema to support MT8188's
requirement for 1-2 memory regions while maintaining strict backward
compatibility for other MediaTek SoCs.
The MT8188 SCP requires a main SRAM region and optionally supports an
L1TCM (Level 1 Tightly Coupled Memory) region for performance
optimization. L1TCM is optional because basic SCP functionality works
with only SRAM, but L1TCM provides faster memory access when the board
hardware configuration includes it.
The base schema uses minItems: 1, maxItems: 2 (permissive range),
following the pattern established in other MediaTek dt-bindings like
mediatek,vcodec-encoder.yaml where the base accommodates all variants.
Conditionals then narrow the constraints per device.
Changes in v4:
- Improved commit message clarity per kernel submission guidelines:
* Added bullet-point explanation of the two memory regions
* Explained WHY L1TCM is optional (performance optimization, not
required for basic functionality)
* Explicitly listed which SoCs remain single-region
* Clarified the two-conditional approach
* Explained how minItems: 1 allows board-specific configuration
- Cover letter updated to explain L1TCM optional reasoning
Changes in v3:
- Removed "Tested on..." line (bindings cannot be tested)
- Added minItems: 1 to MT8188 conditional to make L1TCM truly optional
- Referenced mediatek,vcodec-encoder.yaml iommus pattern explicitly
- Base schema: minItems: 1, maxItems: 2 (permissive range)
- Non-MT8188: explicitly restricted to maxItems: 1
- MT8188: documented with item descriptions for both regions
Changes in v2:
- Added conditional schema for MT8188 to allow 1-2 memory regions
- Added descriptions for each memory region
- Did not work: base maxItems: 1 conflicted with conditional
Arnab Layek (1):
dt-bindings: remoteproc: mtk,scp: Allow multiple memory regions for
MT8188
.../bindings/remoteproc/mtk,scp.yaml | 45 ++++++++++++++++++-
1 file changed, 43 insertions(+), 2 deletions(-)
--
2.45.2
^ permalink raw reply
* Re: [PATCH] arm64/entry: Don't disable preemption in debug_exception_enter() with RT kernel
From: Luis Claudio R. Goncalves @ 2026-05-20 11:23 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: Mark Rutland, Catalin Marinas, linux-rt-devel, linux-kernel,
Steven Rostedt, linux-arm-kernel, Waiman Long, Will Deacon,
Clark Williams
In-Reply-To: <20260520061920.XCqBHe0x@linutronix.de>
On Wed, May 20, 2026 at 08:19:20AM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-05-19 18:25:24 [-0400], Waiman Long wrote:
> > Commit d8bb6718c4db ("arm64: Make debug exception handlers visible from
> > RCU") introduces debug_exception_enter() and debug_exception_exit()
> > where preemption is explicitly disabled. With a PREEMPT_RT debug kernel,
> > the following bug report can happen.
> …
>
> What kernel is this? I have backport (which is being tested) for v6.6
> and v6.12, the patches are from v6.17-rc1.
Sebastian, hardware breakpoint and watchpoint handlers still call
debug_exception_exit() and disable preemption on aarch64. That should
happen on v7.1-rc4 indeed. The suggestion was to mimic what x86_64 does
with notify_die() -> hw_breakpoint_exceptions_notify(). In ARM
hw_breakpoint_exceptions_notify() is a stub that always returns
NOTIFY_DONE.
Luis
> Sebastian
>
---end quoted text---
^ permalink raw reply
* [PATCH AUTOSEL 7.0-5.10] fbdev: ipu-v3: clean up kernel-doc warnings
From: Sasha Levin @ 2026-05-20 11:19 UTC (permalink / raw)
To: patches, stable
Cc: Randy Dunlap, Philipp Zabel, Helge Deller, Sasha Levin, Frank.Li,
linux-fbdev, dri-devel, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: Randy Dunlap <rdunlap@infradead.org>
[ Upstream commit f1fb23a0a0fcbdb66672da51d7d63a259f6396ca ]
Correct all kernel-doc warnings:
- fix a typedef kernel-doc comment
- mark a list_head as private
- use Returns: for function return values
Warning: include/video/imx-ipu-image-convert.h:31 struct member 'list' not
described in 'ipu_image_convert_run'
Warning: include/video/imx-ipu-image-convert.h:40 function parameter
'ipu_image_convert_cb_t' not described in 'void'
Warning: include/video/imx-ipu-image-convert.h:40 expecting prototype for
ipu_image_convert_cb_t(). Prototype was for void() instead
Warning: include/video/imx-ipu-image-convert.h:66 No description found for
return value of 'ipu_image_convert_verify'
Warning: include/video/imx-ipu-image-convert.h:90 No description found for
return value of 'ipu_image_convert_prepare'
Warning: include/video/imx-ipu-image-convert.h:125 No description found for
return value of 'ipu_image_convert_queue'
Warning: include/video/imx-ipu-image-convert.h:163 No description found for
return value of 'ipu_image_convert'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit Message Forensics
Step 1.1 Record: subsystem `fbdev: ipu-v3`; action verb `clean up`;
intent is to correct kernel-doc warnings in `include/video/imx-ipu-
image-convert.h`.
Step 1.2 Record: tags in committed message are `Signed-off-by: Randy
Dunlap <rdunlap@infradead.org>`, `Reviewed-by: Philipp Zabel
<p.zabel@pengutronix.de>`, and `Signed-off-by: Helge Deller
<deller@gmx.de>`. No `Fixes:`, `Reported-by:`, `Tested-by:`, `Acked-
by:`, `Link:`, or `Cc: stable@vger.kernel.org` tag is present in the
committed message.
Step 1.3 Record: the described problem is seven kernel-doc warnings: one
undocumented/private list member, malformed typedef documentation, and
missing `Returns:` sections. The visible symptom is documentation
tooling warnings, not a runtime crash, hang, data corruption, or
security issue. No affected kernel version is stated. Root cause is
incorrect kernel-doc comment syntax.
Step 1.4 Record: this is not a hidden runtime bug fix. The body and diff
both show a documentation/comment-only cleanup.
## Phase 2: Diff Analysis
Step 2.1 Record: one file changed: `include/video/imx-ipu-image-
convert.h`, 11 insertions and 5 deletions. Modified documentation covers
`struct ipu_image_convert_run`, `ipu_image_convert_cb_t`,
`ipu_image_convert_verify()`, `ipu_image_convert_prepare()`,
`ipu_image_convert_queue()`, and `ipu_image_convert()`. Scope is single-
file, header-only, surgical.
Step 2.2 Record: hunk behavior:
- `struct ipu_image_convert_run`: before, `list` was documented neither
as a member nor private; after, `/* private: */` tells kernel-doc to
ignore it as an API member.
- `ipu_image_convert_cb_t`: before, kernel-doc treated the typedef
comment as a function prototype mismatch; after, it is marked as a
typedef comment.
- Return docs: before, several returns were plain prose or missing;
after, they use kernel-doc `Returns:` syntax.
- `ipu_image_convert_prepare()`: before, the V4L2 usage note followed
the return prose; after, the return section is last and formatted for
kernel-doc.
Step 2.3 Record: bug category is documentation/kernel-doc warning
cleanup. No error-path, synchronization, refcount, memory-safety,
initialization, type, logic, or hardware workaround change exists.
Step 2.4 Record: fix quality is high for the stated documentation issue:
small, obviously correct kernel-doc syntax changes. Runtime regression
risk is effectively zero because no C declarations, types, function
bodies, data layout, or APIs are changed. Documentation rendering risk
is very low.
## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows the affected header comments and
declarations came from `cd98e85a6b786d` by Steve Longerbeam, dated
2016-09-17. `git describe --contains cd98e85a6b786d` reports it as
present by `v4.9-rc1~41^2~24^2`.
Step 3.2 Record: no `Fixes:` tag is present, so there is no tagged
introducing commit to follow. Blame identifies `cd98e85a6b786d` as the
source of the documented preimage; `git show` confirms that commit added
queued IPU image conversion support and the API documentation.
Step 3.3 Record: recent local history for the file shows `96e9d754b35e8`
removing unused `ipu_image_convert_*` functions, `c942fddf8793b` adding
SPDX boilerplate conversion, and `cd98e85a6b786d` adding the header/API.
No prerequisite commit is needed for this documentation-only patch.
Step 3.4 Record: `git log --author='Randy Dunlap'` under fbdev/include
areas shows Randy has related cleanup/documentation work such as `fbdev:
hgafb: fix kernel-doc comments` and `fbdev: fbmon: fix function name in
kernel-doc`. The patch was reviewed by Philipp Zabel and committed by
Helge Deller, verified from the commit and lore thread.
Step 3.5 Record: no dependencies found. The diff changes only comments
and applies locally with `git apply --check`.
## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c f1fb23a0a0fcbdb66672da51d7d63a259f6396ca`
failed to find a lore match by patch-id, author/subject, or in-body
From. External fetch found the v3 discussion at
`https://yhbt.net/lore/dri-
devel/20260427183236.656902-1-rdunlap@infradead.org/T/`. The v3 thread
has Helge Deller replying “applied to fbdev git tree.” Web search/fetch
also found v2 and a v2 ping. No NAKs or objections were found.
Step 4.2 Record: `b4 dig -w` also failed for the same reason. The v3
lore mirror shows recipients included `dri-devel`, Philipp Zabel, DRM
maintainers, `imx`, `linux-arm-kernel`, Helge Deller, and `linux-fbdev`.
Step 4.3 Record: no `Reported-by:` or bug-report `Link:` tags exist. No
external crash/security bug report applies.
Step 4.4 Record: this is a standalone one-patch documentation cleanup.
v2 added the reviewed-by and updated Cc list; v3 rebased and resent.
Step 4.5 Record: direct `lore.kernel.org/stable` fetch was blocked by
Anubis. Web search for the exact subject plus `stable` found patch-
thread results but no stable-specific discussion or stable nomination.
## Phase 5: Code Semantic Analysis
Step 5.1 Record: modified documented symbols are
`ipu_image_convert_run`, `ipu_image_convert_cb_t`,
`ipu_image_convert_verify()`, `ipu_image_convert_prepare()`,
`ipu_image_convert_queue()`, and `ipu_image_convert()`.
Step 5.2 Record: `rg` found callers in `drivers/staging/media/imx/imx-
media-csc-scaler.c` for `ipu_image_convert_abort()`,
`ipu_image_convert_queue()`, `ipu_image_convert_adjust()`,
`ipu_image_convert_unprepare()`, and `ipu_image_convert_prepare()`.
Runtime callers are unaffected because only comments changed.
Step 5.3 Record: reading `drivers/gpu/ipu-v3/ipu-image-convert.c`
confirms the documented functions perform image format
adjustment/verification, context allocation, queueing, abort/unprepare,
and single conversion setup. None of those function bodies are touched.
Step 5.4 Record: runtime path is reachable through IPU image conversion
users, but the patch changes no runtime path. The affected path for the
fix is kernel-doc/documentation generation.
Step 5.5 Record: no related same-header kernel-doc fix was found by `git
log --grep='kernel-doc' -- include/video/imx-ipu-image-convert.h`.
## Phase 6: Stable Tree Analysis
Step 6.1 Record: version tags `v5.10`, `v5.15`, `v6.1`, `v6.6`, `v6.12`,
`v6.15`, `v6.16`, and `v6.17` all contain `include/video/imx-ipu-image-
convert.h` with the old kernel-doc text. The API was introduced before
`v4.9-rc1`, so active stable trees checked contain the documentation
issue.
Step 6.2 Record: expected backport difficulty is clean or minor. `git
apply --check` succeeds against the current local tree, and the checked
stable tags contain representative preimage lines. Full per-stable
worktree application was not run.
Step 6.3 Record: no related stable fix for this header was found in
local `git log --grep` searches.
## Phase 7: Subsystem Context
Step 7.1 Record: subsystem is fbdev/gpu IPU-v3 image conversion
documentation in an include header. Runtime criticality is
peripheral/driver-specific; documentation-build criticality is low.
Step 7.2 Record: local subsystem history shows ongoing cleanup/removal
activity in `drivers/gpu/ipu-v3` and the header, including unused-
function removals and treewide cleanup. This patch is not part of a
required functional series.
## Phase 8: Impact And Risk
Step 8.1 Record: affected population is kernel documentation builders,
maintainers, and users consuming generated kernel-doc. Runtime users of
IPU-v3 are not affected by behavior.
Step 8.2 Record: trigger is running kernel-doc/documentation tooling
over this header. It is not triggered by boot, device probe, syscalls,
or ordinary runtime use. Unprivileged runtime trigger does not apply.
Step 8.3 Record: failure mode is documentation warnings only. Severity
is LOW. I did not verify any configuration where these warnings are
fatal, so that does not drive the decision.
Step 8.4 Record: benefit is low but real under the documentation-fix
exception: it makes stable documentation builds cleaner. Risk is
extremely low because only comments change. Risk/benefit is favorable if
stable accepts documentation corrections.
## Phase 9: Final Synthesis
Step 9.1 Record: evidence for backporting: pure documentation
correction, explicitly fixes listed kernel-doc warnings, tiny single-
file patch, reviewed by Philipp Zabel, applied by Helge Deller, old text
exists in active stable tags checked, and documentation/comment fixes
are an allowed stable exception. Evidence against: no runtime bug, no
crash/security/data-corruption impact, no stable nomination found, and
b4 could not match the thread. Unresolved: direct stable-lore search was
blocked; full apply checks on every stable branch were not run.
Step 9.2 Record:
1. Obviously correct and tested? Mostly yes for documentation syntax;
reviewed and applied, but no `Tested-by`.
2. Fixes a real bug that affects users? Yes, a real kernel-doc warning
issue; not a runtime bug.
3. Important issue? No runtime severity; LOW documentation-build
severity.
4. Small and contained? Yes, 11 additions and 5 deletions in one header.
5. No new features or APIs? Yes, comments only.
6. Can apply to stable trees? Likely yes; local apply check passed and
stable tags checked contain the preimage.
Step 9.3 Record: exception category applies: documentation/comment fix.
This is the main reason to accept despite lack of runtime impact.
Step 9.4 Decision: backporting is appropriate under the stable
documentation-fix exception. It is not a stability/security fix, but it
is a correct, reviewed, zero-runtime-risk cleanup of real kernel-doc
warnings in code present across active stable trees.
## Verification
- Phase 1: fetched and inspected committed metadata for
`f1fb23a0a0fcbdb66672da51d7d63a259f6396ca`; confirmed tags and
message.
- Phase 2: `git show --stat --patch` confirmed one header, 11
insertions, 5 deletions, comments only.
- Phase 3: `git blame` confirmed changed comment preimage from
`cd98e85a6b786d`; `git describe --contains` placed it before
`v4.9-rc1`; `git show cd98e85a6b786d` confirmed original API addition.
- Phase 3: `git log` on the header/subsystem found no prerequisite
functional series.
- Phase 4: `b4 dig`, `b4 dig -a`, and `b4 dig -w` all failed to match;
recorded as a tool limitation/failure.
- Phase 4: WebFetch of the v3 lore mirror confirmed the patch thread and
Helge Deller’s applied reply; Spinics fetch confirmed v2 and a later
ping.
- Phase 5: `rg` found runtime users; `ReadFile` of implementation
confirmed function bodies exist but are not changed.
- Phase 6: tag checks confirmed the header and old doc text in `v5.10`,
`v5.15`, `v6.1`, `v6.6`, `v6.12`, `v6.15`, `v6.16`, and `v6.17`; `git
apply --check` succeeded locally.
- Phase 8: severity/risk assessment is derived from the verified
comments-only diff.
- UNVERIFIED: direct `lore.kernel.org/stable` search content was blocked
by Anubis; no actual `make htmldocs` run was performed; full patch
application against every individual stable branch was not performed.
**YES**
include/video/imx-ipu-image-convert.h | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/video/imx-ipu-image-convert.h b/include/video/imx-ipu-image-convert.h
index 003b3927ede5c..6b77968a6a150 100644
--- a/include/video/imx-ipu-image-convert.h
+++ b/include/video/imx-ipu-image-convert.h
@@ -27,12 +27,13 @@ struct ipu_image_convert_run {
int status;
+ /* private: */
/* internal to image converter, callers don't touch */
struct list_head list;
};
/**
- * ipu_image_convert_cb_t - conversion callback function prototype
+ * typedef ipu_image_convert_cb_t - conversion callback function prototype
*
* @run: the completed conversion run pointer
* @ctx: a private context pointer for the callback
@@ -60,7 +61,7 @@ void ipu_image_convert_adjust(struct ipu_image *in, struct ipu_image *out,
* @out: output image format
* @rot_mode: rotation mode
*
- * Returns 0 if the formats and rotation mode meet IPU restrictions,
+ * Returns: 0 if the formats and rotation mode meet IPU restrictions,
* -EINVAL otherwise.
*/
int ipu_image_convert_verify(struct ipu_image *in, struct ipu_image *out,
@@ -77,11 +78,11 @@ int ipu_image_convert_verify(struct ipu_image *in, struct ipu_image *out,
* @complete: run completion callback
* @complete_context: a context pointer for the completion callback
*
- * Returns an opaque conversion context pointer on success, error pointer
+ * In V4L2, drivers should call ipu_image_convert_prepare() at streamon.
+ *
+ * Returns: an opaque conversion context pointer on success, error pointer
* on failure. The input/output formats and rotation mode must already meet
* IPU retrictions.
- *
- * In V4L2, drivers should call ipu_image_convert_prepare() at streamon.
*/
struct ipu_image_convert_ctx *
ipu_image_convert_prepare(struct ipu_soc *ipu, enum ipu_ic_task ic_task,
@@ -122,6 +123,8 @@ void ipu_image_convert_unprepare(struct ipu_image_convert_ctx *ctx);
* In V4L2, drivers should call ipu_image_convert_queue() while
* streaming to queue the conversion of a received input buffer.
* For example mem2mem devices this would be called in .device_run.
+ *
+ * Returns: 0 on success or -errno on error.
*/
int ipu_image_convert_queue(struct ipu_image_convert_run *run);
@@ -155,6 +158,9 @@ void ipu_image_convert_abort(struct ipu_image_convert_ctx *ctx);
* On successful return the caller can queue more run requests if needed, using
* the prepared context in run->ctx. The caller is responsible for unpreparing
* the context when no more conversion requests are needed.
+ *
+ * Returns: pointer to the created &struct ipu_image_convert_run that has
+ * been queued on success; an ERR_PTR(errno) on error.
*/
struct ipu_image_convert_run *
ipu_image_convert(struct ipu_soc *ipu, enum ipu_ic_task ic_task,
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.12] KVM: arm64: nv: Consider the DS bit when translating TCR_EL2
From: Sasha Levin @ 2026-05-20 11:18 UTC (permalink / raw)
To: patches, stable
Cc: Wei-Lin Chang, Marc Zyngier, Sasha Levin, oupton, catalin.marinas,
will, linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: Wei-Lin Chang <weilin.chang@arm.com>
[ Upstream commit 8d9b9d985ad3a81c751a6b97edaf1d3c0780af7c ]
When running an nVHE L1, TCR_EL2 is mapped to TCR_EL1. Writes to the
register are trapped and written to TCR_EL1 after a translation.
Booting an nVHE L1 with 52-bit VA isn't working because the translation
was ignoring the DS bit set by the guest, hence causing repeating level
0 faults. Add it in the translation function.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
Link: https://patch.msgid.link/20260505144735.1496530-1-weilin.chang@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Stable Backport Analysis
### Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem is `KVM: arm64: nv`; action verb is
“Consider”; intent is to preserve the `DS` bit when translating
`TCR_EL2` into `TCR_EL1` for nested virtualization.
Step 1.2 Record: Tags present are:
- `Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>`
- `Link: https://patch.msgid.link/20260505144735.1496530-1-
weilin.chang@arm.com`
- `Signed-off-by: Marc Zyngier <maz@kernel.org>`
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
or `Cc: stable@vger.kernel.org` tags are present.
Step 1.3 Record: The bug is that an nVHE L1 guest using 52-bit VA cannot
boot because trapped writes to `TCR_EL2` are translated to `TCR_EL1`
without carrying over the guest’s `DS` bit. The recorded failure mode is
repeated level 0 faults. No affected kernel version is stated in the
message. Root cause is an incomplete EL2-to-EL1 TCR translation.
Step 1.4 Record: This is not hidden as cleanup; it is a direct
correctness fix for guest boot failure.
### Phase 2: Diff Analysis
Step 2.1 Record: One file changed:
`arch/arm64/include/asm/kvm_nested.h`, 1 insertion, 0 deletions.
Function modified: `translate_tcr_el2_to_tcr_el1()`. Scope is a single-
file surgical fix.
Step 2.2 Record: Before, `translate_tcr_el2_to_tcr_el1()` preserved
`TBI`, physical size, granule, cacheability, shareability, and `T0SZ`,
but ignored `TCR_EL2_DS`. After, it adds `TCR_DS` to the EL1 value when
`TCR_EL2_DS` is set. This affects the normal path where KVM programs the
physical EL1 `TCR` while running an nVHE L1.
Step 2.3 Record: Bug category is logic/correctness. The specific
mechanism is a missing architectural bit translation: `TCR_EL2_DS` is
bit 32, while `TCR_EL1.DS` is bit 59, so it cannot be preserved by the
existing mask-copy operations and must be explicitly mapped.
Step 2.4 Record: The fix is obviously correct and minimal. Regression
risk is very low: it only sets `TCR_EL1.DS` when the guest already set
the corresponding `TCR_EL2.DS` bit.
### Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows `translate_tcr_el2_to_tcr_el1()` was
introduced by `3606e0b2e46216` (“KVM: arm64: nv: Add non-VHE-EL2->EL1
translation helpers”), first contained in `v6.8-rc1`. The buggy omission
is long-lived relative to current stable trees.
Step 3.2 Record: No `Fixes:` tag is present, so there is no tagged
introducer to follow. The blame commit above is the practical introducer
of the incomplete translation.
Step 3.3 Record: Recent history of `arch/arm64/include/asm/kvm_nested.h`
shows active nested-virt development, including 52-bit PA/LPA2 related
work. No prerequisite patch for this one-line change was identified
beyond the existing definitions already present in stable tags checked.
Step 3.4 Record: Wei-Lin Chang has multiple recent `KVM: arm64`/nested-
virt commits. Marc Zyngier, listed in `MAINTAINERS` as a KVM/arm64
maintainer, committed the patch.
Step 3.5 Record: `git log --grep=translate_tcr_el2_to_tcr_el1` found no
other commits mentioning the helper. The patch applies cleanly to the
current checked-out stable tree with `git apply --check`.
### Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 8d9b9d985ad3a81c751a6b97edaf1d3c0780af7c`
found the original submission at the provided patch link. `b4 dig -a`
found only v1. The thread includes Marc Zyngier’s “Applied to fixes”
reply and no objections.
Step 4.2 Record: `b4 dig -w` shows the patch was sent to `linux-arm-
kernel`, `kvmarm`, `linux-kernel`, and KVM/arm64 maintainers/reviewers
including Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, and Will Deacon.
Step 4.3 Record: No separate bug report or syzbot report was found in
the commit tags or b4 thread. The commit message itself gives the
observed boot failure.
Step 4.4 Record: The patch is standalone, single-patch v1; no multi-
patch series dependency was found.
Step 4.5 Record: No stable-specific discussion was found. WebFetch to
lore was blocked by Anubis, but b4 successfully retrieved the thread.
### Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified function: `translate_tcr_el2_to_tcr_el1()`.
Step 5.2 Record: Callers found:
- `locate_register()` maps `TCR_EL2` to `TCR_EL1` with this translation
for loaded nVHE hyp context.
- `__sysreg_restore_vel2_state()` restores nVHE virtual EL2 state by
translating guest `TCR_EL2` before writing physical `SYS_TCR`.
Step 5.3 Record: Key callees are `tcr_el2_ps_to_tcr_el1_ips()` and the
bit definitions/macros for `TCR_EL2_*` and `TCR_*`. The function has no
allocation, locking, or complex side effects; it returns a composed
register value.
Step 5.4 Record: Reachability is verified through guest sysreg traps:
`ESR_ELx_EC_SYS64` goes to `kvm_handle_sys_reg()`, then
`perform_access()`, then the `TCR_EL2` descriptor with `access_rw()`,
then `vcpu_write_sys_reg()`, which applies `loc.xlate()` when the mapped
register is loaded. This is reachable by an L1 guest using EL2.
Step 5.5 Record: Similar translation helpers exist for `SCTLR_EL2`,
`CPTR_EL2`, and `TTBR0_EL2`; this patch fixes the missing special-case
bit in the TCR helper. `TCR_EL1.DS` and `TCR_EL2.DS` are at different
bit positions, so the existing mask copying cannot handle it.
### Phase 6: Stable Tree Analysis
Step 6.1 Record: The helper commit is present in checked tags `v6.12`,
`v6.18`, `v6.19`, and `v7.0`. The LPA2 DS field definitions are also
present in those tags. The 52-bit PA helper commit checked is present in
`v6.18`, `v6.19`, and `v7.0`, but not `v6.12`.
Step 6.2 Record: Expected backport difficulty is low for trees with this
helper. `b4 am` reported “Base: applies clean to current tree”, and `git
apply --check` succeeded on the current `v7.0.9` checkout.
Step 6.3 Record: No related fix for “Consider the DS bit” is in `v7.0`
or `v7.0.9`; `git merge-base --is-ancestor` returned absent for the
candidate in those tags.
### Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: Subsystem is KVM/arm64 nested virtualization.
Criticality is IMPORTANT: it affects ARM64 KVM users running nested
virtualization with nVHE L1 guests and 52-bit VA.
Step 7.2 Record: Subsystem is actively maintained; recent
`arch/arm64/kvm` history contains multiple KVM/arm64 fixes, and
`MAINTAINERS` marks KVM/arm64 as maintained by Marc Zyngier and Oliver
Upton.
### Phase 8: Impact And Risk Assessment
Step 8.1 Record: Affected population is platform/config-specific: ARM64
KVM users with nested virtualization and an nVHE L1 using 52-bit VA.
Step 8.2 Record: Trigger is booting or running such an nVHE L1 with
`TCR_EL2.DS` set. The path is guest-triggerable through EL2 sysreg
writes, but only for VMs configured with nested virtualization support.
Step 8.3 Record: Failure mode is repeated level 0 faults and failed L1
boot. Severity is HIGH for affected users because the guest hypervisor
cannot boot correctly.
Step 8.4 Record: Benefit is high for affected nested virtualization
users. Risk is very low: one line, no API change, no locking, no data
structure change, and only changes behavior when the guest sets
`TCR_EL2_DS`.
### Phase 9: Final Synthesis
Step 9.1 Record:
Evidence for backporting:
- Fixes a real boot failure for nVHE L1 guests with 52-bit VA.
- One-line, contained architectural bit translation.
- Existing definitions verify this is a required bit-position mapping,
not a feature addition.
- Maintainer applied it to the KVM/arm64 fixes branch.
- Applies cleanly to the current stable checkout.
- Buggy helper exists in active stable-era tags checked.
Evidence against backporting:
- No `Fixes:`, `Reported-by:`, `Tested-by:`, or explicit stable tag.
- Affected population is narrower than core KVM users.
- Exact user-visible 52-bit VA nested scenario was not fully proven for
every older stable branch, especially `v6.12`.
Unresolved:
- I did not build-test or boot-test.
- I did not verify clean application to every stable branch
individually.
- WebFetch could not read lore directly due Anubis, though b4 retrieved
the thread.
Step 9.2 Stable rules:
1. Obviously correct and tested? Obviously correct by code inspection;
no explicit Tested-by found.
2. Fixes a real bug? Yes, commit message and code path verify a missing
required register bit translation causing L1 boot failure.
3. Important issue? Yes, boot failure/repeated translation faults for
affected nested virtualization guests.
4. Small and contained? Yes, 1 line in one helper.
5. No new features/APIs? Yes.
6. Can apply to stable trees? Yes for current checked stable tree;
likely straightforward for trees containing this helper.
Step 9.3 Exception category: None. This is not a device ID, quirk, DT,
build, or documentation exception; it is a direct bug fix.
Step 9.4 Decision: Backport. The fix is small, technically clear, and
corrects an architectural register translation bug that prevents a
supported nested-virtualization configuration from booting.
## Verification
- Phase 1: Parsed `git show` for candidate
`8d9b9d985ad3a81c751a6b97edaf1d3c0780af7c`; confirmed subject, body,
and tags.
- Phase 2: Inspected exact diff; confirmed 1 insertion in
`translate_tcr_el2_to_tcr_el1()`.
- Phase 2: Verified `TCR_EL2_DS` is bit 32 in
`arch/arm64/include/asm/kvm_arm.h`.
- Phase 2: Verified `TCR_EL1.DS` is bit 59 in `arch/arm64/tools/sysreg`
and `TCR_DS` aliases it in `arch/arm64/include/asm/pgtable-hwdef.h`.
- Phase 3: `git blame` identified `3606e0b2e46216` as introducer of the
helper.
- Phase 3: `git describe --contains 3606e0b2e46216` reported first
containment at `v6.8-rc1`.
- Phase 3: `git log` on affected files found related nested-virt/LPA2
activity and no required adjacent patch.
- Phase 4: `b4 dig -c` found the original patch by patch-id.
- Phase 4: `b4 dig -a` found only v1.
- Phase 4: `b4 dig -w` confirmed KVM/arm64 maintainers and lists were
included.
- Phase 4: `b4 mbox -c -o -` retrieved Marc Zyngier’s applied-to-fixes
reply.
- Phase 5: `rg` found callers in `sys_regs.c` and `hyp/vhe/sysreg-sr.c`.
- Phase 5: Read trap path from `handle_exit.c`, `sys_regs.c`, and
`arm.c`; verified guest sysreg traps can reach the translation.
- Phase 6: `git merge-base --is-ancestor` confirmed the helper and DS
definitions are present in `v6.12`, `v6.18`, `v6.19`, and `v7.0`.
- Phase 6: `git apply --check` succeeded on the current stable checkout.
- Phase 7: Read `MAINTAINERS`; confirmed Marc Zyngier and Oliver Upton
maintain KVM/arm64.
- Phase 8: Failure mode verified from commit message and code path;
exact boot reproduction was not run.
- UNVERIFIED: No build or boot test was performed.
- UNVERIFIED: Clean application to every individual stable branch was
not tested.
- UNVERIFIED: Exact impact on older stable trees lacking later 52-bit PA
helper work was not fully established.
**YES**
arch/arm64/include/asm/kvm_nested.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/include/asm/kvm_nested.h b/arch/arm64/include/asm/kvm_nested.h
index 091544e6af442..dc2957662ff20 100644
--- a/arch/arm64/include/asm/kvm_nested.h
+++ b/arch/arm64/include/asm/kvm_nested.h
@@ -23,6 +23,7 @@ static inline u64 tcr_el2_ps_to_tcr_el1_ips(u64 tcr_el2)
static inline u64 translate_tcr_el2_to_tcr_el1(u64 tcr)
{
return TCR_EPD1_MASK | /* disable TTBR1_EL1 */
+ ((tcr & TCR_EL2_DS) ? TCR_DS : 0) |
((tcr & TCR_EL2_TBI) ? TCR_TBI0 : 0) |
tcr_el2_ps_to_tcr_el1_ips(tcr) |
(tcr & TCR_EL2_TG0_MASK) |
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v15 7/9] drm/rockchip: cdn-dp: Add multiple bridges to support PHY port selection
From: Heiko Stuebner @ 2026-05-20 11:12 UTC (permalink / raw)
To: Heikki Krogerus, Greg Kroah-Hartman, Dmitry Baryshkov, Peter Chen,
Luca Ceresoli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Kishon Vijay Abraham I, Sandy Huang, Andy Yan,
Yubing Zhang, Frank Wang, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Amit Sunil Dhamne, Dragan Simic, Johan Jonker,
Diederik de Haas, Peter Robinson, Hugh Cole-Baker, Chaoyi Chen
Cc: linux-usb, devicetree, linux-kernel, linux-phy, linux-arm-kernel,
linux-rockchip, dri-devel, Chaoyi Chen
In-Reply-To: <20260304094152.92-8-kernel@airkyi.com>
Am Mittwoch, 4. März 2026, 10:41:50 Mitteleuropäische Sommerzeit schrieb Chaoyi Chen:
> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
> The RK3399 has two USB/DP combo PHY and one CDN-DP controller. And
> the CDN-DP can be switched to output to one of the PHYs. If both ports
> are plugged into DP, DP will select the first port for output.
>
> This patch adds support for multiple bridges, enabling users to flexibly
> select the output port. For each PHY port, a separate encoder and bridge
> are registered.
>
> The change is based on the DRM AUX HPD bridge, rather than the
> extcon approach. This requires the DT to correctly describe the
> connections between the first bridge in bridge chain and DP
> controller. For example, the bridge chain may be like this:
>
> PHY aux birdge -> fsa4480 analog audio switch bridge ->
> onnn,nb7vpq904m USB reminder bridge -> USB-C controller AUX HPD bridge
>
> In this case, the connection relationships among the PHY aux bridge
> and the DP contorller need to be described in DT.
>
> In addition, the cdn_dp_parse_next_bridge_dt() will parses it and
> determines whether to register one or two bridges.
>
> Since there is only one DP controller, only one of the PHY ports can
> output at a time. The key is how to switch between different PHYs,
> which is handled by cdn_dp_switch_port() and cdn_dp_enable().
>
> There are two cases:
>
> 1. Neither bridge is enabled. In this case, both bridges can
> independently read the EDID, and the PHY port may switch before
> reading the EDID.
>
> 2. One bridge is already enabled. In this case, other bridges are not
> allowed to read the EDID. So we will try to return the cached EDID.
>
> Since the scenario of two ports plug in at the same time is rare,
> I don't have a board which support two TypeC connector to test this.
> Therefore, I tested forced switching on a single PHY port, as well as
> output using a fake PHY port alongside a real PHY port.
>
> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH v4 4/6] media: synopsys: Add PHY stopstate wait for i.MX93
From: Alexander Stein @ 2026-05-20 11:12 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil, Guoniu Zhou
Cc: linux-media, linux-kernel, devicetree, imx, linux-arm-kernel,
linux-rockchip, Guoniu Zhou
In-Reply-To: <20260519-csi2_imx95-v4-4-84ea4bb78a88@oss.nxp.com>
Hi,
Am Dienstag, 19. Mai 2026, 04:07:41 CEST schrieb Guoniu Zhou:
> Implement waiting for D-PHY lanes to enter stop state on i.MX93. This
> ensures proper PHY initialization by verifying that the clock lane and
> all active data lanes have entered the stop state before proceeding with
> further operations.
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
> Changes in v2:
> - Removes redundant register availability check
> - Uses read_poll_timeout() with dw_mipi_csi2rx_read() instead of
> readl_poll_timeout() with direct register address
> - Fixes stopstate condition logic
> - Check PHY stopstate after sensor enable instead of before to ensure
> correct timing.
> - Optimize PHY stopstate polling parameters (1000us->10us, 2s->1ms) to
> balance performance and responsiveness.
> ---
> drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 36 ++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> index 92178a3dec5d..8a34aec550ad 100644
> --- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> +++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> @@ -11,6 +11,7 @@
> #include <linux/clk.h>
> #include <linux/delay.h>
> #include <linux/io.h>
> +#include <linux/iopoll.h>
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/phy/phy.h>
> @@ -35,6 +36,8 @@
> #define DW_REG_EXIST BIT(31)
> #define DW_REG(x) (DW_REG_EXIST | (x))
>
> +#define DPHY_STOPSTATE_CLK_LANE BIT(16)
> +
> #define DPHY_TEST_CTRL0_TEST_CLR BIT(0)
>
> #define IPI_VCID_VC(x) FIELD_PREP(GENMASK(1, 0), (x))
> @@ -65,6 +68,7 @@ enum dw_mipi_csi2rx_regs_index {
> DW_MIPI_CSI2RX_PHY_TST_CTRL0,
> DW_MIPI_CSI2RX_PHY_TST_CTRL1,
> DW_MIPI_CSI2RX_PHY_SHUTDOWNZ,
> + DW_MIPI_CSI2RX_PHY_STOPSTATE,
> DW_MIPI_CSI2RX_IPI_DATATYPE,
> DW_MIPI_CSI2RX_IPI_MEM_FLUSH,
> DW_MIPI_CSI2RX_IPI_MODE,
> @@ -87,6 +91,7 @@ struct dw_mipi_csi2rx_drvdata {
> void (*dphy_assert_reset)(struct dw_mipi_csi2rx_device *csi2);
> void (*dphy_deassert_reset)(struct dw_mipi_csi2rx_device *csi2);
> void (*ipi_enable)(struct dw_mipi_csi2rx_device *csi2);
> + int (*wait_for_phy_stopstate)(struct dw_mipi_csi2rx_device *csi2);
> };
>
> struct dw_mipi_csi2rx_format {
> @@ -139,6 +144,7 @@ static const u32 imx93_regs[DW_MIPI_CSI2RX_MAX] = {
> [DW_MIPI_CSI2RX_PHY_SHUTDOWNZ] = DW_REG(0x40),
> [DW_MIPI_CSI2RX_DPHY_RSTZ] = DW_REG(0x44),
> [DW_MIPI_CSI2RX_PHY_STATE] = DW_REG(0x48),
> + [DW_MIPI_CSI2RX_PHY_STOPSTATE] = DW_REG(0x4c),
> [DW_MIPI_CSI2RX_PHY_TST_CTRL0] = DW_REG(0x50),
> [DW_MIPI_CSI2RX_PHY_TST_CTRL1] = DW_REG(0x54),
> [DW_MIPI_CSI2RX_IPI_MODE] = DW_REG(0x80),
> @@ -556,10 +562,19 @@ static int dw_mipi_csi2rx_enable_streams(struct v4l2_subdev *sd,
> if (ret)
> goto err_csi_stop;
>
> + if (!csi2->enabled_streams &&
> + csi2->drvdata->wait_for_phy_stopstate) {
> + ret = csi2->drvdata->wait_for_phy_stopstate(csi2);
> + if (ret)
> + goto err_disable_streams;
> + }
> +
> csi2->enabled_streams |= streams_mask;
>
> return 0;
>
> +err_disable_streams:
> + v4l2_subdev_disable_streams(remote_sd, remote_pad->index, mask);
> err_csi_stop:
> /* Stop CSI hardware if no streams are enabled */
> if (!csi2->enabled_streams)
> @@ -871,11 +886,32 @@ static void imx93_csi2rx_dphy_ipi_enable(struct dw_mipi_csi2rx_device *csi2)
> dw_mipi_csi2rx_write(csi2, DW_MIPI_CSI2RX_IPI_MODE, val);
> }
>
> +static int imx93_csi2rx_wait_for_phy_stopstate(struct dw_mipi_csi2rx_device *csi2)
> +{
> + struct device *dev = csi2->dev;
> + u32 stopstate_mask;
> + u32 val;
> + int ret;
> +
> + stopstate_mask = DPHY_STOPSTATE_CLK_LANE | GENMASK(csi2->lanes_num - 1, 0);
> +
> + ret = read_poll_timeout(dw_mipi_csi2rx_read, val,
> + (val & stopstate_mask) == stopstate_mask,
> + 10, 1000, true,
> + csi2, DW_MIPI_CSI2RX_PHY_STOPSTATE);
> + if (ret)
> + dev_err(dev, "lanes are not in stop state: %#x, expected %#x\n",
> + val, stopstate_mask);
Did you actually test this on imx93? I'm trying to get my imx327 sensor to
run, but only run into this error message:
dw-mipi-csi2rx 4ae00000.mipi-csi: lanes are not in stop state: 0x0, expected 0x10003
Currently I'm using this DT node:
--8<--
mipi_csi: mipi-csi@4ae00000 {
compatible = "fsl,imx93-mipi-csi2";
reg = <0x4ae00000 0x10000>;
interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk IMX93_CLK_MIPI_CSI_GATE>,
<&clk IMX93_CLK_CAM_PIX>;
clock-names = "per", "pixel";
assigned-clocks = <&clk IMX93_CLK_CAM_PIX>;
assigned-clock-parents = <&clk IMX93_CLK_VIDEO_PLL>;
assigned-clock-rates = <140000000>;
power-domains = <&media_blk_ctrl IMX93_MEDIABLK_PD_MIPI_CSI>;
phys = <&dphy_rx>;
phy-names = "dphy-rx";
status = "disabled";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
mipi_from_sensor: endpoint {
data-lanes = <1 2>;
bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
};
};
port@1 {
reg = <1>;
mipi_to_isi: endpoint {
remote-endpoint = <&isi_in>;
};
};
};
};
--8<--
Am I'm missing something?
best regards,
Alexander
> +
> + return ret;
> +}
> +
> static const struct dw_mipi_csi2rx_drvdata imx93_drvdata = {
> .regs = imx93_regs,
> .dphy_assert_reset = imx93_csi2rx_dphy_assert_reset,
> .dphy_deassert_reset = imx93_csi2rx_dphy_deassert_reset,
> .ipi_enable = imx93_csi2rx_dphy_ipi_enable,
> + .wait_for_phy_stopstate = imx93_csi2rx_wait_for_phy_stopstate,
> };
>
> static const struct of_device_id dw_mipi_csi2rx_of_match[] = {
>
>
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
^ permalink raw reply
* Re: [PATCH v15 6/9] drm/rockchip: cdn-dp: Support handle lane info without extcon
From: Heiko Stuebner @ 2026-05-20 11:10 UTC (permalink / raw)
To: Heikki Krogerus, Greg Kroah-Hartman, Dmitry Baryshkov, Peter Chen,
Luca Ceresoli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Kishon Vijay Abraham I, Sandy Huang, Andy Yan,
Yubing Zhang, Frank Wang, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Amit Sunil Dhamne, Dragan Simic, Johan Jonker,
Diederik de Haas, Peter Robinson, Hugh Cole-Baker, Chaoyi Chen
Cc: linux-usb, devicetree, linux-kernel, linux-phy, linux-arm-kernel,
linux-rockchip, dri-devel, Chaoyi Chen
In-Reply-To: <20260304094152.92-7-kernel@airkyi.com>
Am Mittwoch, 4. März 2026, 10:41:49 Mitteleuropäische Sommerzeit schrieb Chaoyi Chen:
> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
> This patch add support for get PHY lane info without help of extcon.
>
> There is no extcon needed if the Type-C controller is present. In this
> case, the lane info can be get from PHY instead of extcon.
>
> The extcon device should still be supported if Type-C controller is
> not present.
>
> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* [PATCH] dt-bindings: arm-smmu: Correct and add constraints for Hawi, Shikra and Kaanapali
From: Krzysztof Kozlowski @ 2026-05-20 11:09 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, iommu,
devicetree, linux-kernel
Cc: Krzysztof Kozlowski
Previous commit 75949eb02653 ("dt-bindings: arm-smmu: Constrain clocks
for newer Qualcomm variants") duplicated constraints for
qcom,sm6350-smmu-500 and qcom,sm6375-smmu-500 - these are already part
of previous "if:" block.
It also missed enforcing one clock for qcom,kaanapali-smmu-500 in GPU
case and missed simultaneously added Shikra and Hawi.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index ed0d10157bd6..5103adeee6d4 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -568,6 +568,8 @@ allOf:
items:
- enum:
- qcom,glymur-smmu-500
+ - qcom,hawi-smmu-500
+ - qcom,kaanapali-smmu-500
- qcom,sm8750-smmu-500
- const: qcom,adreno-smmu
- const: qcom,smmu-500
@@ -614,15 +616,15 @@ allOf:
- enum:
- qcom,eliza-smmu-500
- qcom,glymur-smmu-500
+ - qcom,hawi-smmu-500
- qcom,kaanapali-smmu-500
- qcom,milos-smmu-500
- qcom,qcs615-smmu-500
- qcom,qcs8300-smmu-500
- qcom,sa8775p-smmu-500
+ - qcom,shikra-smmu-500
- qcom,sm6115-smmu-500
- qcom,sm6125-smmu-500
- - qcom,sm6350-smmu-500
- - qcom,sm6375-smmu-500
- qcom,sm8150-smmu-500
- qcom,sm8250-smmu-500
- qcom,sm8350-smmu-500
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v15 9/9] arm64: dts: rockchip: rk3399-evb-ind: Add support for DisplayPort
From: Heiko Stuebner @ 2026-05-20 11:06 UTC (permalink / raw)
To: Heikki Krogerus, Greg Kroah-Hartman, Dmitry Baryshkov, Peter Chen,
Luca Ceresoli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Kishon Vijay Abraham I, Sandy Huang, Andy Yan,
Yubing Zhang, Frank Wang, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Amit Sunil Dhamne, Dragan Simic, Johan Jonker,
Diederik de Haas, Peter Robinson, Hugh Cole-Baker, Chaoyi Chen
Cc: linux-usb, devicetree, linux-kernel, linux-phy, linux-arm-kernel,
linux-rockchip, dri-devel, Chaoyi Chen
In-Reply-To: <20260304094152.92-10-kernel@airkyi.com>
Am Mittwoch, 4. März 2026, 10:41:52 Mitteleuropäische Sommerzeit schrieb Chaoyi Chen:
> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
> The RK3399 EVB IND board has a Type-C interface DisplayPort.
> It use fusb302 chip as Type-C controller.
>
> fusb302 chip ---> USB/DP PHY0 <----> CDN-DP controller
>
> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Apart from what I replied to the cover-letter, it might be
nice to split this into
- patch adding the fusb and general type-c parts
- patch adding the dp altmode
To make each part a bit shorter.
Heiko
^ permalink raw reply
* Re: [PATCH v15 0/9] Add Type-C DP support for RK3399 EVB IND board
From: Heiko Stuebner @ 2026-05-20 11:03 UTC (permalink / raw)
To: Heikki Krogerus, Chaoyi Chen, Dmitry Baryshkov, Luca Ceresoli,
Neil Armstrong
Cc: Chaoyi Chen, Greg Kroah-Hartman, Peter Chen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul,
Kishon Vijay Abraham I, Sandy Huang, Andy Yan, Yubing Zhang,
Frank Wang, Andrzej Hajda, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Amit Sunil Dhamne,
Dragan Simic, Johan Jonker, Diederik de Haas, Peter Robinson,
Hugh Cole-Baker, linux-usb, devicetree, linux-kernel, linux-phy,
linux-arm-kernel, linux-rockchip, dri-devel
In-Reply-To: <c0bc4796-afe5-40ff-8816-9605a6114d23@rock-chips.com>
Hi,
Am Mittwoch, 20. Mai 2026, 03:13:25 Mitteleuropäische Sommerzeit schrieb Chaoyi Chen:
> Hello Heikki,
>
> On 5/19/2026 9:43 PM, Heikki Krogerus wrote:
> > Hi,
> >
> > On Wed, Mar 04, 2026 at 05:41:43PM +0800, Chaoyi Chen wrote:
> >> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
> >>
> >> This series focuses on adding Type-C DP support for USBDP PHY and DP
> >> driver. The USBDP PHY and DP will perceive the changes in cable status
> >> based on the USB PD and Type-C state machines provided by TCPM. Before
> >> this, the USBDP PHY and DP controller of RK3399 sensed cable state
> >> changes through extcon, and devices such as the RK3399 Gru-Chromebook
> >> rely on them. This series should not break them.
> >
> > What's the status with this series?
> > Are these inteded to go via the DRM tree?
> >
> > thanks,
> >
>
> Thank you very much for your continued attention to this series.
> The maintainers seem quite busy... Despite there being no further review
> comments, this series have yet to be merged into the DRM tree.
>
> And some of my other patches are in the same situation.
> Do you happen to know what the next steps should be? Thank you.
For this series, I would think it'd be best to split it a bit.
- Make patches 1, 2, 5-7 its own series
* patch 5 _should_ be included here, needs an Ack from the phy-maintainer
to go through the drm-tree. It does look independent from the other
phy changes (code changes themself), but needs the function from patch 2.
- Make patches 3+4 its own series, so that phy maintainers notice
The code-changes themself seem independent of the rest
* Reference the drm-series and explicity note that the phy-patch in it
needs an Ack from the phy maintainer to through the drm-tree
Hopefully helps to get that
* patch 1 has a Reviewed-by from the type-c side, but needs someone
knowing drm-bridge internals to agree
- Makes patches 8+9 its own series, reference both series from above
as dependencies.
That would be my take here, to have the right maintainers notice they
should do something.
Heiko
^ permalink raw reply
* Re: [PATCH v2 2/2] KVM: arm64: nv: Don't save/restore FP register during a nested ERET or exception
From: Joey Gouly @ 2026-05-20 11:02 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, linux-arm-kernel, kvm, Steffen Eiden, Suzuki K Poulose,
Oliver Upton, Zenghui Yu, Mark Rutland, Will Deacon, Fuad Tabba
In-Reply-To: <20260520085036.541666-3-maz@kernel.org>
Hi Marc,
On Wed, May 20, 2026 at 09:50:36AM +0100, Marc Zyngier wrote:
> When switching between L1 and L2, we save the old state using
> kvm_arch_vcpu_put(), mutate the state in memory, then load the new
> state using kvm_arch_vcpu_load(). Any live FPSIMD/SVE state is saved
> and unbound, such that it can be lazily restored on a subsequent trap.
>
> The FPSIMD/SVE state is shared by exception levels, and only a handful
> of related control registers need to be changed when transitioning
> between L1 and L2. The save/restore of the common state is needless
> overhead, especially as trapping becomes exponentially more expensive
> with nesting.
>
> Avoid this overhead by leaving the common FPSIMD/SVE state live on the
> CPU, and only switching the state that is distinct for L1 and L2:
To make sure I understand this part:
L1 sets up L2's FP state live on the CPU
L1 erets
eret traps to L0/host
preemption disabled
kvm_arch_vcpu_put()
kvm_arch_vcpu_put_fp() <-- actually saves the state of the live registers
.. set elr etc ..
kvm_arch_vcpu_load()
kvm_arch_vcpu_load_fp() <-- doesn't actually restore state, but ensures
the CPTR trap will be set
.. returns to L2 (traps on first use of FP and state will be restored)
So this patch is (effectively) removing the put_fp()/load_fp(), because the FP
state is common/shared between L1 and L2, so whatever L1 put into that state
before the eret, L2 was going to see.
If my understanding is correct:
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Thanks,
Joey
>
> - the trap controls: the effective values are recomputed on each entry
> into the guest to take the EL into account and merge the L0 and L1
> configuration if in a nested context, or directly use the L0 configuration
> in non-nested context (see __activate_traps()).
>
> - the VL settings: the effective values are are also recomputed on each
> entry into the guest (see fpsimd_lazy_switch_to_guest()).
>
> Since we appear to cover all bases, use the vcpu flags indicating the
> handling of a nested ERET or exception delivery to avoid the whole FP
> save/restore shenanigans. SME will have to be similarly dealt with when
> it eventually gets supported.
>
> For an EL1 L3 guest where L1 and L2 have this optimisation, this
> results in at least a 10% wall clock reduction when running an I/O
> heavy workload, generating a high rate of nested exceptions.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kvm/fpsimd.c | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> index 15e17aca1dec0..aca98752a6e42 100644
> --- a/arch/arm64/kvm/fpsimd.c
> +++ b/arch/arm64/kvm/fpsimd.c
> @@ -28,6 +28,20 @@ void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu)
> if (!system_supports_fpsimd())
> return;
>
> + /*
> + * Avoid needless save/restore of the guest's common
> + * FPSIMD/SVE/SME regs during transitions between L1/L2.
> + *
> + * These transitions only happens in a non-preemptible context
> + * where the host regs have already been saved and unbound. The
> + * live registers are either free or owned by the guest.
> + */
> + if (vcpu_get_flag(vcpu, IN_NESTED_ERET) ||
> + vcpu_get_flag(vcpu, IN_NESTED_EXCEPTION)) {
> + WARN_ON_ONCE(host_owns_fp_regs());
> + return;
> + }
> +
> /*
> * Ensure that any host FPSIMD/SVE/SME state is saved and unbound such
> * that the host kernel is responsible for restoring this state upon
> @@ -102,6 +116,15 @@ void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
> {
> unsigned long flags;
>
> + /*
> + * See comment in kvm_arch_vcpu_load_fp().
> + */
> + if (vcpu_get_flag(vcpu, IN_NESTED_ERET) ||
> + vcpu_get_flag(vcpu, IN_NESTED_EXCEPTION)) {
> + WARN_ON_ONCE(host_owns_fp_regs());
> + return;
> + }
> +
> local_irq_save(flags);
>
> if (guest_owns_fp_regs()) {
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm-smmu: qcom: Constrain clocks for Hawi SoC
From: Krzysztof Kozlowski @ 2026-05-20 10:57 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Will Deacon, Joerg Roedel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robin Murphy, linux-arm-kernel, iommu, devicetree,
linux-kernel
In-Reply-To: <20260520073447.2138384-1-mukesh.ojha@oss.qualcomm.com>
On Wed, May 20, 2026 at 01:04:47PM +0530, Mukesh Ojha wrote:
> The Hawi SoC has two SMMU instances with different clock requirements.
> The Adreno GPU SMMU uses the qcom,adreno-smmu fallback and requires a
> single HLOS vote clock, matching the pattern already established for
> Glymur and SM8750. The Application Processor SMMU (APSS) uses the
> qcom,smmu-500 fallback and has no controllable clocks.
>
> Add qcom,hawi-smmu-500 to the single-clock constraint block for the
> Adreno GPU SMMU and to the no-clocks constraint block for the APSS SMMU,
> following the pattern how it is done for other SoCs.
If you decided to make a competitive simultaneous work, you could at
least tell me that.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 7/7] mm/vmalloc: Stop scanning for compound pages after encountering small pages in vmap
From: Wen Jiang @ 2026-05-20 10:56 UTC (permalink / raw)
To: Uladzislau Rezki
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, baohua,
Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel
In-Reply-To: <ag2CeHWDLLglCF7t@milan>
Sure, will do.
Thanks,
Wen Jiang
On Wed, 20 May 2026 at 17:44, Uladzislau Rezki <urezki@gmail.com> wrote:
>
> On Thu, May 14, 2026 at 05:41:08PM +0800, Wen Jiang wrote:
> > From: "Barry Song (Xiaomi)" <baohua@kernel.org>
> >
> > Users typically allocate memory in descending orders, e.g.
> > 8 → 4 → 0. Once an order-0 page is encountered, subsequent
> > pages are likely to also be order-0, so we stop scanning
> > for compound pages at that point.
> >
> > Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> > Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> > Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> > ---
> > mm/vmalloc.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index b3389c8f1..60579bfbf 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -3576,6 +3576,12 @@ static int __vmap_huge(unsigned long addr, unsigned long end,
> > map_addr = addr;
> > idx = i;
> > }
> > + /*
> > + * Once small pages are encountered, the remaining pages
> > + * are likely small as well
> > + */
> > + if (shift == PAGE_SHIFT)
> > + break;
> >
> > addr += 1UL << shift;
> > i += 1U << (shift - PAGE_SHIFT);
> > --
> > 2.34.1
> >
> Can we squash this patch with
> "mm/vmalloc: map contiguous pages in batches for vmap() if possible"?
>
> --
> Uladzislau Rezki
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox