* Re: [PATCH v3 2/3] iio: adc: xilinx-ams: use guard(mutex) for automatic locking
From: Salih Erim @ 2026-05-12 14:25 UTC (permalink / raw)
To: Guilherme Ivo Bozi, Conall O'Griofa, Jonathan Cameron,
Michal Simek
Cc: David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
linux-arm-kernel, linux-kernel, Andy Shevchenko
In-Reply-To: <20260414224245.8493-3-guilherme.bozi@usp.br>
Hi,
On 4/14/2026 11:40 PM, Guilherme Ivo Bozi wrote:
> Replace open-coded mutex_lock()/mutex_unlock() pairs with
> guard(mutex) to simplify locking and ensure proper unlock on
> all control flow paths.
>
> This removes explicit unlock handling, reduces boilerplate,
> and avoids potential mistakes in error paths while keeping
> the behavior unchanged.
>
> Signed-off-by: Guilherme Ivo Bozi <guilherme.bozi@usp.br>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> ---
> drivers/iio/adc/xilinx-ams.c | 24 ++++++++----------------
> 1 file changed, 8 insertions(+), 16 deletions(-)
Same indentation issue -- spaces instead of tabs on all new lines.
Salih
^ permalink raw reply
* Re: [PATCH v3 1/3] iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event handling
From: Salih Erim @ 2026-05-12 14:22 UTC (permalink / raw)
To: Guilherme Ivo Bozi, Conall O'Griofa, Jonathan Cameron,
Michal Simek
Cc: David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260414224245.8493-2-guilherme.bozi@usp.br>
Hi Guilherme,
Replies are inline.
On 4/14/2026 11:40 PM, Guilherme Ivo Bozi wrote:
> ams_event_to_channel() may return a pointer past the end of
> dev->channels when no matching scan_index is found. This can lead
> to invalid memory access in ams_handle_event().
>
> Add a bounds check in ams_event_to_channel() and return NULL when
> no channel is found. Also guard the caller to safely handle this
> case.
>
> Fixes: d5c70627a794 ("iio: adc: Add Xilinx AMS driver")
> Signed-off-by: Guilherme Ivo Bozi <guilherme.bozi@usp.br>
> ---
> drivers/iio/adc/xilinx-ams.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/iio/adc/xilinx-ams.c b/drivers/iio/adc/xilinx-ams.c
> index 124470c92529..6191cd1b29a5 100644
> --- a/drivers/iio/adc/xilinx-ams.c
> +++ b/drivers/iio/adc/xilinx-ams.c
> @@ -871,6 +871,9 @@ static const struct iio_chan_spec *ams_event_to_channel(struct iio_dev *dev,
> if (dev->channels[i].scan_index == scan_index)
> break;
>
> + if (i == dev->num_channels)
> + return NULL;
> +
The added lines use spaces for indentation instead of tabs.
Salih
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: iio: adc: Convert xilinx-xadc bindings to YAML schema
From: Michal Simek @ 2026-05-12 14:21 UTC (permalink / raw)
To: David Lechner, Rob Herring
Cc: Jonathan Cameron, Pramod Maurya, Nuno Sá, Andy Shevchenko,
Krzysztof Kozlowski, Conor Dooley, Lars-Peter Clausen, linux-iio,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <db7fc677-56bb-4421-969d-6116a0a57d77@baylibre.com>
On 5/12/26 16:16, David Lechner wrote:
> On 5/12/26 9:10 AM, Michal Simek wrote:
>>
>>
>> On 5/12/26 15:58, David Lechner wrote:
>>> On 5/12/26 7:14 AM, Rob Herring wrote:
>>>> On Mon, May 11, 2026 at 11:24 AM David Lechner <dlechner@baylibre.com> wrote:
>>>>>
>>>>> On 5/11/26 11:15 AM, Jonathan Cameron wrote:
>>>>>> On Sun, 10 May 2026 08:01:36 -0400
>>>>>> Pramod Maurya <pramod.nexgen@gmail.com> wrote:
>>>>>>
>>>>>>> Convert the Xilinx XADC and UltraScale System Monitor device tree binding
>>>>>>> from the legacy plain-text format to a YAML schema, enabling automated
>>>>>>> validation with dt-schema.
>>>>>>>
>>>>>>> The new binding covers the same hardware and compatible strings:
>>>>>>> - xlnx,zynq-xadc-1.00.a (ZYNQ hardmacro)
>>>>>>> - xlnx,axi-xadc-1.00.a (AXI softmacro)
>>>>>>> - xlnx,system-management-wiz-1.3 (UltraScale System Management Wizard)
>>>>>>>
>>>>>>> Signed-off-by: Pramod Maurya <pramod.nexgen@gmail.com>
>>>>>> Hi Pramod,
>>>>>>
>>>>>> Something went wrong with your sending of v3. I have two versions sent
>>>>>> half a day apart and no idea how they are related.
>>>>>>
>>>>>> Anyhow one of them got feedback from Rob's bot so I'll assume we are
>>>>>> getting a v4 and wait for that.
>>>>>>
>>>>>> Jonathan
>>>>>
>>>>> I think Rob will have to fix the bot to make an exception for the
>>>>> legacy bindings. This should have been called out in the commit message
>>>>> as requested in a previous revision.
>>>>
>>>> The bot is not the problem. It just runs validation. The schemas will
>>>> have to either drop this check (comma's in nodenames) or exclude just
>>>> this property.
>>>>
>>>>
>>>> Rob
>>>
>>> Even though this is an existing text-based schema that has been around
>>> for 12 years with this name already? Changing it could be a breaking
>>> change to existing users. Although there aren't any in any .dts in the
>>> kernel source.
>>
>> Zynq has it described.
>> arch/arm/boot/dts/xilinx/zynq-7000.dtsi:111: compatible = "xlnx,zynq-xadc-1.00.a";
>>
>> And make no sense to describe programmable logic which are that other two.
>>
>> Thanks,
>> Michal
>
> The issue is with the xlnx,channels property name. Searching only shows
> this in the driver and in the examples in the bindings .txt file.
Because it depends on HW design configuration. Different configuration have
different channels exposed. We are using device tree generator which take
current design configuration and describe them. zynq-7000.dtsi is generic for
all boards. I can't remember all details but I wouldn't be surprise if no
channel is exported on minimal/default designs which are described.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v3 0/3] iio: adc: xilinx-ams: refactor alarm handling to table-driven design
From: Salih Erim @ 2026-05-12 14:18 UTC (permalink / raw)
To: Guilherme Ivo Bozi, Conall O'Griofa, Jonathan Cameron,
Michal Simek
Cc: David Lechner, Nuno Sá, Andy Shevchenko, linux-iio,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260414224245.8493-1-guilherme.bozi@usp.br>
Hi Guilherme,
Thanks for working on this. The refactoring approach looks good overall,
but all three patches have indentation issues and patch 3 has one
semantic issue. Please see my comments on each patch.
On 4/14/2026 11:40 PM, Guilherme Ivo Bozi wrote:
> This series addresses significant code duplication in alarm handling
> logic across the Xilinx AMS IIO driver.
>
> To address this, the series introduces a centralized table-driven
> mapping (alarm_map) that replaces multiple switch statements spread
> across the driver.
>
> This improves:
> - maintainability (single source of truth for mappings)
> - readability (removes repeated switch logic)
> - extensibility (new alarms require only table updates)
>
> No functional changes are intended.
>
> Series overview:
> - Patch 1: fix out-of-bounds channel lookup
> - Patch 2: convert mutex handling to guard(mutex)
> - Patch 3: introduce table-driven alarm mapping
>
> v1 -> v2:
> - Fixed Fixes tag format
> - Replaced AMS_ALARM_INVALID with AMS_ALARM_NONE
> - Changed alarm_map base_offset type
>
> v2 -> v3:
> - Replace 'i >= num_channels' with 'i == num_channels'
> - Add missing trailing comma in alarm_map array initializer
>
> Guilherme Ivo Bozi (3):
> iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event
> handling
> iio: adc: xilinx-ams: use guard(mutex) for automatic locking
> iio: adc: xilinx-ams: refactor alarm mapping to table-driven approach
>
> drivers/iio/adc/xilinx-ams.c | 190 +++++++++++++----------------------
> 1 file changed, 71 insertions(+), 119 deletions(-)
>
> --
> 2.47.3
>
Salih
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: iio: adc: Convert xilinx-xadc bindings to YAML schema
From: David Lechner @ 2026-05-12 14:16 UTC (permalink / raw)
To: Michal Simek, Rob Herring
Cc: Jonathan Cameron, Pramod Maurya, Nuno Sá, Andy Shevchenko,
Krzysztof Kozlowski, Conor Dooley, Lars-Peter Clausen, linux-iio,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <cc26edcf-3218-4294-a522-ffafdaf41070@amd.com>
On 5/12/26 9:10 AM, Michal Simek wrote:
>
>
> On 5/12/26 15:58, David Lechner wrote:
>> On 5/12/26 7:14 AM, Rob Herring wrote:
>>> On Mon, May 11, 2026 at 11:24 AM David Lechner <dlechner@baylibre.com> wrote:
>>>>
>>>> On 5/11/26 11:15 AM, Jonathan Cameron wrote:
>>>>> On Sun, 10 May 2026 08:01:36 -0400
>>>>> Pramod Maurya <pramod.nexgen@gmail.com> wrote:
>>>>>
>>>>>> Convert the Xilinx XADC and UltraScale System Monitor device tree binding
>>>>>> from the legacy plain-text format to a YAML schema, enabling automated
>>>>>> validation with dt-schema.
>>>>>>
>>>>>> The new binding covers the same hardware and compatible strings:
>>>>>> - xlnx,zynq-xadc-1.00.a (ZYNQ hardmacro)
>>>>>> - xlnx,axi-xadc-1.00.a (AXI softmacro)
>>>>>> - xlnx,system-management-wiz-1.3 (UltraScale System Management Wizard)
>>>>>>
>>>>>> Signed-off-by: Pramod Maurya <pramod.nexgen@gmail.com>
>>>>> Hi Pramod,
>>>>>
>>>>> Something went wrong with your sending of v3. I have two versions sent
>>>>> half a day apart and no idea how they are related.
>>>>>
>>>>> Anyhow one of them got feedback from Rob's bot so I'll assume we are
>>>>> getting a v4 and wait for that.
>>>>>
>>>>> Jonathan
>>>>
>>>> I think Rob will have to fix the bot to make an exception for the
>>>> legacy bindings. This should have been called out in the commit message
>>>> as requested in a previous revision.
>>>
>>> The bot is not the problem. It just runs validation. The schemas will
>>> have to either drop this check (comma's in nodenames) or exclude just
>>> this property.
>>>
>>>
>>> Rob
>>
>> Even though this is an existing text-based schema that has been around
>> for 12 years with this name already? Changing it could be a breaking
>> change to existing users. Although there aren't any in any .dts in the
>> kernel source.
>
> Zynq has it described.
> arch/arm/boot/dts/xilinx/zynq-7000.dtsi:111: compatible = "xlnx,zynq-xadc-1.00.a";
>
> And make no sense to describe programmable logic which are that other two.
>
> Thanks,
> Michal
The issue is with the xlnx,channels property name. Searching only shows
this in the driver and in the examples in the bindings .txt file.
^ permalink raw reply
* Re: [PATCH v5 16/29] media: rockchip: rga: split flip and rotate into separate function
From: Nicolas Dufresne @ 2026-05-12 14:15 UTC (permalink / raw)
To: Sven Püschel, Jacob Chen, Ezequiel Garcia,
Mauro Carvalho Chehab, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans Verkuil
Cc: linux-media, linux-rockchip, linux-arm-kernel, linux-kernel,
devicetree, kernel, sebastian.reichel
In-Reply-To: <1f447423-8c63-4545-a4f7-d8d5ef821255@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 7379 bytes --]
Le mardi 12 mai 2026 à 16:08 +0200, Sven Püschel a écrit :
> Hi Nicolas,
>
> On 5/9/26 12:11 AM, Nicolas Dufresne wrote:
> > Le mardi 28 avril 2026 à 11:00 +0200, Sven Püschel a écrit :
> > > Split the flip and rotate command configuration into a separate
> > > function in preparation of filling the command stream at streamon.
> > > As the userspace can change the flipping and rotation controls while
> > > streaming, we have to update them with each new frame to prevent the
> > > user being unable to change them while streaming.
> > >
> > > Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
> > For code point of view, everything seems fine, but the commit message leave me a
> > bit wondering. Any rotation that isn't 180 degree will cause the width and
> > height to be reversed, and a new stride is needed to present the buffer
> > correctly. Meaning the capture format can be affected by this change.
>
> Sorry for missing to properly communicate my intention with this patch.
>
> I've stumbled over the RGA pulling a spin lock on the controls, when
> starting the next job [1]. This made me realize that the driver allows
> changing the controls while streaming, which my change to move the
> command buffer setup to streamon breaks (as a potential rotation isn't
> updated until the next streamon).
>
> This commit is the result of trying to not break the old behavior by
> moving the relevant code parts to be run on every frame instead of being
> only run at streamon. I didn't think about the 90 degree rotation
> problems, which are also present in the current RGA state.
>
> sashiko.dev also pointed out that my simple code move didn't work for
> the mirroring case [2], as the relevant command buffer is ore'd with the
> mirroring flags. Also I've noticed that the rotation mode affects the
> scaling factor. To avoid these footguns, I've got the idea to set a flag
> to raise when the controls change. Then I can fully re-initialize the
> command buffer on the next frame and fully avoid these kind of problems.
Thanks for the update, thanks for looking into that.
>
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/rockchip/rga/rga.c?id=50897c955902c93ae71c38698abb910525ebdc89#n41
>
> [2]
> https://sashiko.dev/#/patchset/20260428-spu-rga3-v5-0-eb7f5d019d86%40pengutronix.de?part=16
>
> >
> > To stick with the spec, the capture format needs to be updated, and it needs to
> > happen in a way user can be able to read it back for the correct frame if
> > userspace make use of the queues. I see 3 options, let me know what you think,
> > or what is later implemented if you already thought about that.
> >
> > 1. Synchronously update the capture format width/height, document in the
> > respective control this behaviour, leaving to userspace to remember which frames
> > the change will apply to.
> >
> > This works nicely for this type of HW, but would be a bit complicated for a
> > deinterlacer, since the buffering might be HW specific. It also make usage of
> > queues harder, less independent.
> >
> > 2. Force a drain/stop/start for any 90 degree rotation
> >
> > This might impose a longer idle time for the converter core, and is kind of
> > opposite of your commit message. But requires no spec work.
> >
> > 3. Emit SRC_CH, implement the drain procedure typical to decoder resolution
> > change.
> >
> > Typically it means userspace can keep buffering on the OUTPUT queue, and once
> > the LAST buffer is met, it can simply read the new format (and new stride, since
> > due to alignment, this might be hardware specific) and toggle streamoff/on only
> > on capture queue to reactivate the processing.
> >
> > The 3. is more complex for the driver, but its a proven race-free method for
> > decoders already. 2 would be statusquo to get this series in, and we could post-
> > poned more advance work for seamless 90degree rorations. 1., I don't really like
> > that solution, it not quite generic enough.
>
> I'll go with option 2 for now to keep it simple and improve the status
> quo a bit.
Works for me.
Nicolas
>
> Sincerely
> Sven
>
> > feedback welcome,
> > Nicolas
> >
> > > ---
> > > drivers/media/platform/rockchip/rga/rga-hw.c | 57 +++++++++++++++++-----------
> > > 1 file changed, 34 insertions(+), 23 deletions(-)
> > >
> > > diff --git a/drivers/media/platform/rockchip/rga/rga-hw.c b/drivers/media/platform/rockchip/rga/rga-hw.c
> > > index dac3cb6aa17d3..6c1956b04f6ba 100644
> > > --- a/drivers/media/platform/rockchip/rga/rga-hw.c
> > > +++ b/drivers/media/platform/rockchip/rga/rga-hw.c
> > > @@ -156,7 +156,38 @@ static void rga_cmd_set_dst_addr(struct rga_ctx *ctx, dma_addr_t dma_addr)
> > > dest[reg >> 2] |= 0x7 << 8;
> > > }
> > >
> > > -static void rga_cmd_set_trans_info(struct rga_ctx *ctx)
> > > +static void rga_cmd_set_flip_rotate_info(struct rga_ctx *ctx)
> > > +{
> > > + u32 *dest = ctx->cmdbuf_virt;
> > > + union rga_src_info src_info;
> > > +
> > > + src_info.val = dest[(RGA_SRC_INFO - RGA_MODE_BASE_REG) >> 2];
> > > +
> > > + if (ctx->vflip)
> > > + src_info.data.mir_mode |= RGA_SRC_MIRR_MODE_X;
> > > +
> > > + if (ctx->hflip)
> > > + src_info.data.mir_mode |= RGA_SRC_MIRR_MODE_Y;
> > > +
> > > + switch (ctx->rotate) {
> > > + case 90:
> > > + src_info.data.rot_mode = RGA_SRC_ROT_MODE_90_DEGREE;
> > > + break;
> > > + case 180:
> > > + src_info.data.rot_mode = RGA_SRC_ROT_MODE_180_DEGREE;
> > > + break;
> > > + case 270:
> > > + src_info.data.rot_mode = RGA_SRC_ROT_MODE_270_DEGREE;
> > > + break;
> > > + default:
> > > + src_info.data.rot_mode = RGA_SRC_ROT_MODE_0_DEGREE;
> > > + break;
> > > + }
> > > +
> > > + dest[(RGA_SRC_INFO - RGA_MODE_BASE_REG) >> 2] = src_info.val;
> > > +}
> > > +
> > > +static void rga_cmd_set_format_scale_info(struct rga_ctx *ctx)
> > > {
> > > struct rockchip_rga *rga = ctx->rga;
> > > u32 *dest = ctx->cmdbuf_virt;
> > > @@ -219,27 +250,6 @@ static void rga_cmd_set_trans_info(struct rga_ctx *ctx)
> > > }
> > > }
> > >
> > > - if (ctx->vflip)
> > > - src_info.data.mir_mode |= RGA_SRC_MIRR_MODE_X;
> > > -
> > > - if (ctx->hflip)
> > > - src_info.data.mir_mode |= RGA_SRC_MIRR_MODE_Y;
> > > -
> > > - switch (ctx->rotate) {
> > > - case 90:
> > > - src_info.data.rot_mode = RGA_SRC_ROT_MODE_90_DEGREE;
> > > - break;
> > > - case 180:
> > > - src_info.data.rot_mode = RGA_SRC_ROT_MODE_180_DEGREE;
> > > - break;
> > > - case 270:
> > > - src_info.data.rot_mode = RGA_SRC_ROT_MODE_270_DEGREE;
> > > - break;
> > > - default:
> > > - src_info.data.rot_mode = RGA_SRC_ROT_MODE_0_DEGREE;
> > > - break;
> > > - }
> > > -
> > > /*
> > > * Calculate the up/down scaling mode/factor.
> > > *
> > > @@ -431,7 +441,8 @@ static void rga_cmd_set(struct rga_ctx *ctx,
> > >
> > > rga_cmd_set_src_info(ctx, &src->offset);
> > > rga_cmd_set_dst_info(ctx, &dst->offset);
> > > - rga_cmd_set_trans_info(ctx);
> > > + rga_cmd_set_format_scale_info(ctx);
> > > + rga_cmd_set_flip_rotate_info(ctx);
> > >
> > > rga_write(rga, RGA_CMD_BASE, ctx->cmdbuf_phy);
> > >
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v5 06/29] media: rockchip: rga: fix too small buffer size
From: Sven Püschel @ 2026-05-12 14:14 UTC (permalink / raw)
To: Nicolas Dufresne, Jacob Chen, Ezequiel Garcia,
Mauro Carvalho Chehab, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans Verkuil
Cc: linux-media, linux-rockchip, linux-arm-kernel, linux-kernel,
devicetree, kernel, sebastian.reichel
In-Reply-To: <7cf0950e51e4917a0b4d565f71b1e8f2a41e4bbe.camel@ndufresne.ca>
Hi Nicolas,
On 5/8/26 11:11 PM, Nicolas Dufresne wrote:
> Le mardi 28 avril 2026 à 11:00 +0200, Sven Püschel a écrit :
>> Fix the command buffer size being only a quarter of the actual size.
>> The RGA_CMDBUF_SIZE macro was potentially intended to specify the length
>> of the cmdbuf u32 array pointer. But as it's used to specify the size of
>> the allocation, which is counted in bytes. Therefore adjust the macro
>> size to bytes as it better matches the variable name and adjust it's
>> users accordingly.
>>
>> As the command buffer is relatively small, it probably didn't caused
>> an issue due to being smaller than a single page.
>>
>> Fixes: f7e7b48e6d79 ("[media] rockchip/rga: v4l2 m2m support")
>> Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
>
>> ---
>> drivers/media/platform/rockchip/rga/rga-hw.c | 2 +-
>> drivers/media/platform/rockchip/rga/rga-hw.h | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/platform/rockchip/rga/rga-hw.c b/drivers/media/platform/rockchip/rga/rga-hw.c
>> index 43ed742a16492..d1618bb247501 100644
>> --- a/drivers/media/platform/rockchip/rga/rga-hw.c
>> +++ b/drivers/media/platform/rockchip/rga/rga-hw.c
>> @@ -414,7 +414,7 @@ static void rga_cmd_set(struct rga_ctx *ctx,
>> {
>> struct rockchip_rga *rga = ctx->rga;
>>
>> - memset(rga->cmdbuf_virt, 0, RGA_CMDBUF_SIZE * 4);
>> + memset(rga->cmdbuf_virt, 0, RGA_CMDBUF_SIZE);
> So we had a buffer overrun ?
From my point of view, yes [1]:
/* Create CMD buffer */
rga->cmdbuf_virt = dma_alloc_attrs(rga->dev, RGA_CMDBUF_SIZE,
&rga->cmdbuf_phy, GFP_KERNEL,
DMA_ATTR_WRITE_COMBINE);
Given that 0x20 * 4 is smaller than a page, it probably didn't caused an
issue as we didn't write out of the one page allocated.
Btw.: I've noticed it while reading a bit over the comments from
sashiko.dev [2]. I'll also add this link for clarity to the comment in
my next series (seems to be the common way of referring to sashiko.dev).
Sincerely
Sven
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/rockchip/rga/rga.c?id=50897c955902c93ae71c38698abb910525ebdc89#n880
[2]
https://sashiko.dev/#/patchset/20260325-spu-rga3-v4-0-e90ec1c61354%40pengutronix.de?part=10
>
> Nicolas
>
>>
>> rga_cmd_set_src_addr(ctx, src->dma_desc_pa);
>> /*
>> diff --git a/drivers/media/platform/rockchip/rga/rga-hw.h b/drivers/media/platform/rockchip/rga/rga-hw.h
>> index cc6bd7f5b0300..2b8537a5fd0d7 100644
>> --- a/drivers/media/platform/rockchip/rga/rga-hw.h
>> +++ b/drivers/media/platform/rockchip/rga/rga-hw.h
>> @@ -6,7 +6,7 @@
>> #ifndef __RGA_HW_H__
>> #define __RGA_HW_H__
>>
>> -#define RGA_CMDBUF_SIZE 0x20
>> +#define RGA_CMDBUF_SIZE 0x80
>>
>> /* Hardware limits */
>> #define MAX_WIDTH 8192
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: iio: adc: Convert xilinx-xadc bindings to YAML schema
From: David Lechner @ 2026-05-12 14:13 UTC (permalink / raw)
To: Rob Herring
Cc: Jonathan Cameron, Pramod Maurya, Nuno Sá, Andy Shevchenko,
Krzysztof Kozlowski, Conor Dooley, Michal Simek,
Lars-Peter Clausen, linux-iio, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <a4ecfb27-5ef4-4682-b87c-24917f81b4f0@baylibre.com>
On 5/12/26 8:58 AM, David Lechner wrote:
> On 5/12/26 7:14 AM, Rob Herring wrote:
>> On Mon, May 11, 2026 at 11:24 AM David Lechner <dlechner@baylibre.com> wrote:
>>>
>>> On 5/11/26 11:15 AM, Jonathan Cameron wrote:
>>>> On Sun, 10 May 2026 08:01:36 -0400
>>>> Pramod Maurya <pramod.nexgen@gmail.com> wrote:
>>>>
>>>>> Convert the Xilinx XADC and UltraScale System Monitor device tree binding
>>>>> from the legacy plain-text format to a YAML schema, enabling automated
>>>>> validation with dt-schema.
>>>>>
>>>>> The new binding covers the same hardware and compatible strings:
>>>>> - xlnx,zynq-xadc-1.00.a (ZYNQ hardmacro)
>>>>> - xlnx,axi-xadc-1.00.a (AXI softmacro)
>>>>> - xlnx,system-management-wiz-1.3 (UltraScale System Management Wizard)
>>>>>
>>>>> Signed-off-by: Pramod Maurya <pramod.nexgen@gmail.com>
>>>> Hi Pramod,
>>>>
>>>> Something went wrong with your sending of v3. I have two versions sent
>>>> half a day apart and no idea how they are related.
>>>>
>>>> Anyhow one of them got feedback from Rob's bot so I'll assume we are
>>>> getting a v4 and wait for that.
>>>>
>>>> Jonathan
>>>
>>> I think Rob will have to fix the bot to make an exception for the
>>> legacy bindings. This should have been called out in the commit message
>>> as requested in a previous revision.
>>
>> The bot is not the problem. It just runs validation. The schemas will
>> have to either drop this check (comma's in nodenames) or exclude just
>> this property.
>>
>>
>> Rob
>
> Even though this is an existing text-based schema that has been around
> for 12 years with this name already? Changing it could be a breaking
> change to existing users. Although there aren't any in any .dts in the
> kernel source.
Pramod,
Unless Rob changes his mind, the thing to do would be to use the standard
channels property from adc.yaml when converting the binding instead of
xlnx,channels.
We will also need to add handling in the driver for "channels" while
preserving "xlnx,channels" handling for backwards compatibility.
xlnx,channels will just be undocumented.
And all of this reasoning must be explained in the commit messages.
^ permalink raw reply
* Re: [PATCH 4/8] drm/panthor: Add support for protected memory allocation in panthor
From: Boris Brezillon @ 2026-05-12 14:11 UTC (permalink / raw)
To: Liviu Dudau
Cc: Marcin Ślusarz, Ketil Johnsen, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Jonathan Corbet, Shuah Khan, Sumit Semwal, Benjamin Gaignard,
Brian Starkey, John Stultz, T.J. Mercier, Christian König,
Steven Price, Daniel Almeida, Alice Ryhl, Matthias Brugger,
AngeloGioacchino Del Regno, dri-devel, linux-doc, linux-kernel,
linux-media, linaro-mm-sig, linux-arm-kernel, linux-mediatek,
Florent Tomasin, nd
In-Reply-To: <agMvb_jeRsO7tSS-@e142607>
On Tue, 12 May 2026 14:47:27 +0100
Liviu Dudau <liviu.dudau@arm.com> wrote:
> On Thu, May 07, 2026 at 01:53:56PM +0200, Boris Brezillon wrote:
> > On Thu, 7 May 2026 11:02:26 +0200
> > Marcin Ślusarz <marcin.slusarz@arm.com> wrote:
> >
> > > On Tue, May 05, 2026 at 06:15:23PM +0200, Boris Brezillon wrote:
> > > > > @@ -277,9 +286,21 @@ int panthor_device_init(struct panthor_device *ptdev)
> > > > > return ret;
> > > > > }
> > > > >
> > > > > + /* If a protected heap name is specified but not found, defer the probe until created */
> > > > > + if (protected_heap_name && strlen(protected_heap_name)) {
> > > >
> > > > Do we really need this strlen() > 0? Won't dma_heap_find() fail is the
> > > > name is "" already?
> > >
> > > If dma_heap_find() will fail, then the whole probe with fail too.
> > > This check prevents that.
> >
> > Yeah, that's also a questionable design choice. I mean, we can
> > currently probe and boot the FW even though we never setup the
> > protected FW sections, so why should we defer the probe here? Can't we
> > just retry the next time a group with the protected bit is created and
> > fail if we can find a protected heap?
>
> The problem we have with the current firmware is that it does a number of setup steps at "boot"
> time only. One of the steps is preparing its internal structures for when it enters protected
> mode and it stores them in the buffer passed in at firmware loading. We cannot later run the
> process when we have a group with protected mode set.
No, but we can force a full/slow reset and have that thing
re-initialized, can't we? I mean, that's basically what we do when a
fast reset fails: we re-initialize all the sections and reset again, at
which point the FW should start from a fresh state, and be able to
properly initialize the protected-related stuff if protected sections
are populated. Am I missing something?
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: iio: adc: Convert xilinx-xadc bindings to YAML schema
From: Michal Simek @ 2026-05-12 14:10 UTC (permalink / raw)
To: David Lechner, Rob Herring
Cc: Jonathan Cameron, Pramod Maurya, Nuno Sá, Andy Shevchenko,
Krzysztof Kozlowski, Conor Dooley, Lars-Peter Clausen, linux-iio,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <a4ecfb27-5ef4-4682-b87c-24917f81b4f0@baylibre.com>
On 5/12/26 15:58, David Lechner wrote:
> On 5/12/26 7:14 AM, Rob Herring wrote:
>> On Mon, May 11, 2026 at 11:24 AM David Lechner <dlechner@baylibre.com> wrote:
>>>
>>> On 5/11/26 11:15 AM, Jonathan Cameron wrote:
>>>> On Sun, 10 May 2026 08:01:36 -0400
>>>> Pramod Maurya <pramod.nexgen@gmail.com> wrote:
>>>>
>>>>> Convert the Xilinx XADC and UltraScale System Monitor device tree binding
>>>>> from the legacy plain-text format to a YAML schema, enabling automated
>>>>> validation with dt-schema.
>>>>>
>>>>> The new binding covers the same hardware and compatible strings:
>>>>> - xlnx,zynq-xadc-1.00.a (ZYNQ hardmacro)
>>>>> - xlnx,axi-xadc-1.00.a (AXI softmacro)
>>>>> - xlnx,system-management-wiz-1.3 (UltraScale System Management Wizard)
>>>>>
>>>>> Signed-off-by: Pramod Maurya <pramod.nexgen@gmail.com>
>>>> Hi Pramod,
>>>>
>>>> Something went wrong with your sending of v3. I have two versions sent
>>>> half a day apart and no idea how they are related.
>>>>
>>>> Anyhow one of them got feedback from Rob's bot so I'll assume we are
>>>> getting a v4 and wait for that.
>>>>
>>>> Jonathan
>>>
>>> I think Rob will have to fix the bot to make an exception for the
>>> legacy bindings. This should have been called out in the commit message
>>> as requested in a previous revision.
>>
>> The bot is not the problem. It just runs validation. The schemas will
>> have to either drop this check (comma's in nodenames) or exclude just
>> this property.
>>
>>
>> Rob
>
> Even though this is an existing text-based schema that has been around
> for 12 years with this name already? Changing it could be a breaking
> change to existing users. Although there aren't any in any .dts in the
> kernel source.
Zynq has it described.
arch/arm/boot/dts/xilinx/zynq-7000.dtsi:111: compatible =
"xlnx,zynq-xadc-1.00.a";
And make no sense to describe programmable logic which are that other two.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v8 0/2] arm64/sve: Performance improvements with SVE state saving
From: Will Deacon @ 2026-05-12 14:10 UTC (permalink / raw)
To: Mark Brown
Cc: Catalin Marinas, Mark Rutland, Ryan Roberts, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260320-arm64-sve-trap-mitigation-v8-0-8bf116c8e360@kernel.org>
Hi Mark,
On Fri, Mar 20, 2026 at 03:44:13PM +0000, Mark Brown wrote:
> This series aims to improve our handling of SVE access traps and state
> clearing. As SVE deployment progresses both hardware and software
> actively using SVE is becoming more common. When a task is using SVE it
> faces additional costs, the floating point state we must track is larger
> and our syscall ABI requires that the extra state is cleared on every
> syscall. Users have measured these overheads and raised concerns about
> them.
>
> We can avoid these costs by reenabling SVE access traps and falling back
> to FPSIMD only mode but if we do this too often for tasks that are
> actively using SVE the cost of the access traps becomes prohibitive.
> Currently we attempt to balance the tradeoffs here by starting tasks
> with SVE disabled, enabling it on first use and then turning it off if
> we need to load state from memory while the task is in a syscall. This
> means that CPU bound tasks that do not regularly do blocking syscalls
> will rarely drop SVE while tasks that use a lot of SVE but do block in
> syscalls (eg, due to network or user interaction) will be much more
> likely to do and hence incur SVE access traps.
>
> I did some instrumentation which counted the number of SVE access traps
> and the number of times we loaded FPSIMD only register state for each task.
> Testing with Debian Bookworm this showed that during boot the overwhelming
> majority of tasks triggered another SVE access trap more than 50% of the
> time after loading FPSIMD only state with a substantial number near 100%,
> though some programs had a very small number of SVE accesses most likely
> from the dynamic linker. There were few tasks in the range 5-45%, most
> tasks either used SVE frequently or used it only a tiny proportion of
> times. As expected older distributions which do not have the SVE
> performance work available showed no SVE usage in general applications.
>
> For tasks with minimal SVE usage benchmarking with fp-pidbench on a
> system with 128 bit SVE shows an approximately 6% overhead on syscalls
> from having used SVE in the task, the overhead should be greater on a
> system with 256 bit SVE since the Z registers must be flushed as well as
> the P and FFR registers.
>
> The two patches here move to using a time based heuristic to decide when
> to reenable the SVE access trap, doing so after a second. This means
> that tasks actively using SVE which block in syscalls should see reduced
> or similar numbers of access traps, while CPU bound tasks that rarely
> use SVE will see the SVE syscall overhead removed after running for
> approximately a second, confirmed via fp-pidbench.
Have you looked at all at applying this heuristic to SME? I wonder if it
would help with the recent DVMSync erratum workaround, where tasks that
use SME once/infrequently end up causing IPIs for TLB invalidation every
time they run on an effected core.
Will
^ permalink raw reply
* Re: [PATCH] firmware: smccc: Fix Arm SMCCC SOC_ID name call
From: Andre Przywara @ 2026-05-12 14:09 UTC (permalink / raw)
To: Paul Benoit, Sudeep Holla
Cc: Mark Rutland, Lorenzo Pieralisi, linux-arm-kernel, linux-kernel
In-Reply-To: <c72b6d61-d532-48f0-add0-4f44051b4ae9@os.amperecomputing.com>
Hi Paul,
many thanks for the answer, and apologies for the delay (was on holidays).
On 5/1/26 22:14, Paul Benoit wrote:
> On 4/30/2026 10:59 AM, Andre Przywara wrote:
>> [You don't often get email from andre.przywara@arm.com. Learn why this
>> is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Hi Paul,
>>
>> is there any update on this?
>> One more thought below ...
>>
>
> Hi Andre,
>
> Using the incorrect SMC32 vs. the correct SMC64 interface, for SOC_ID
> Name, was addressed by Ampere firmware some months back.
>
> In addition to recent firmware now responding to a SMC64 CC SOC_ID Name
> request, it will continue to respond to an incorrect/broken SMC32
> request and return the SOC_ID Name string packed in 64-bit registers.
> This will allow Linux kernels 6.15+, incorrectly using SMC32 to get the
> SOC_ID Name, to continue to work with new Ampere firmware versions.
OK, many thanks for the information, that seems to be a good solution.
> In other words, unless any other vendors also implemented SOC_ID Name as
> SMC32 in their firmware, I think we can let the Ampere firmware handle
> the SMC32 vs. SMC64 mix-up and keep the handling of it out of the Linux
> kernel.
But I think availability of the machines predates the "some month back"
period you mention above?
So it would only work if users would update the firmware?
> It should now be safe to make the SMC32->SMC64 SOC_ID Name change in
> Linux.
So I wonder if would still need a quirk for AmpereOne. I guess we can't
query the TF-A build version easily, and a DMI quirk probably doesn't
work either, judging by the dmidecode output of one machine I looked at.
So I was wondering if we should employ the following algorithm:
- do call with 64-bit FID
- if (ret == -1) && (soc_id == jep106:0a16:0004)
- try 32-bit FID
Would that work? That checks for the SoC, not the firmware version, but
seems way easier to implement and would cover all cases.
Thoughts?
Cheers,
Andre
>
>
>> On 9/4/25 16:29, Sudeep Holla wrote:
>>> On Wed, Sep 03, 2025 at 05:38:44PM -0400, Paul Benoit wrote:
>>>> On 9/3/2025 10:49 AM, Sudeep Holla wrote:
>>>>> On Wed, Sep 03, 2025 at 03:23:58PM +0100, Sudeep Holla wrote:
>>>>>> On Tue, Sep 02, 2025 at 06:20:53PM +0100, Andre Przywara wrote:
>>>>>>> Commit 5f9c23abc477 ("firmware: smccc: Support optional Arm SMCCC
>>>>>>> SOC_ID
>>>>>>> name") introduced the SOC_ID name string call, which reports a human
>>>>>>> readable string describing the SoC, as returned by firmware.
>>>>>>> The SMCCC spec v1.6 describes this feature as AArch64 only, since
>>>>>>> we rely
>>>>>>> on 8 characters to be transmitted per register. Consequently the
>>>>>>> SMCCC
>>>>>>> call must use the AArch64 calling convention, which requires bit
>>>>>>> 30 of
>>>>>>> the FID to be set. The spec is a bit confusing here, since it
>>>>>>> mentions
>>>>>>> that in the parameter description ("2: SoC name (optionally
>>>>>>> implemented for
>>>>>>> SMC64 calls, ..."), but still prints the FID explicitly as
>>>>>>> 0x80000002.
>>>>>>> But as this FID is using the SMC32 calling convention (correct
>>>>>>> for the
>>>>>>> other two calls), it will not match what mainline TF-A is
>>>>>>> expecting, so
>>>>>>> any call would return NOT_SUPPORTED.
>>>>>>>
>>>>>>
>>>>>> Good catch and I must admit I completely missed it inspite of
>>>>>> discussing
>>>>>> 32b vs 64b FID around the same time this was introduced.
>>>>>>
>>>>>>> Add a 64-bit version of the ARCH_SOC_ID FID macro, and use that
>>>>>>> for the
>>>>>>> SoC name version of the call.
>>>>>>>
>>>>>>> Fixes: 5f9c23abc477 ("firmware: smccc: Support optional Arm SMCCC
>>>>>>> SOC_ID name")
>>>>>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>>>>>> ---
>>>>>>> Hi,
>>>>>>>
>>>>>>> as somewhat expected, this now fails on an Ampere machine, which
>>>>>>> reported a string in /sys/devices/soc0/machine before, but is now
>>>>>>> missing
>>>>>>> this file.
>>>>>>> Any idea what's the best way to handle this? Let the code try the
>>>>>>> 32-bit
>>>>>>> FID, when the 64-bit one fails? Or handle this as some kind of
>>>>>>> erratum?
>>>>>>>
>>>>>>
>>>>>> Not sure about it yet. Erratum seems good option so that we can avoid
>>>>>> others getting it wrong too as they might just run the kernel and
>>>>>> be happy
>>>>>> if the machine sysfs shows up as we decided to do fallback to 32b
>>>>>> FID.
>>>>>>
>>>>>> I will start a discussion to get the spec updated and pushed out
>>>>>> and see
>>>>>> how that goes.
>>>>>>
>>>>>> The change itself looks good and happy to get it merged once we know
>>>>>> what is the best approach(erratum vs fallback).
>>>>>>
>>>>>
>>>>> Looking at the SMCCC spec(DEN0028 v1.6 G Edition) ->
>>>>> Section 7.4.6 Implementation responsibilities
>>>>>
>>>>> If implemented, the firmware:
>>>>> ...
>>>>> • must not implement SoC_ID_type == 2 for SMC32.
>>>>> • can optionally implement SoC_ID_type == 2 for SMC64 (Function ID
>>>>> 0xC000_0002),
>>>>> ...
>>>>>
>>>>> So Ampere is not spec conformant here and hence I prefer to handle
>>>>> it as
>>>>> erratum. Hopefully we can use SOC_ID version and revision to keep
>>>>> the scope
>>>>> of erratum confined to smallest set of platforms.
>>>>>
>>>>> Paul,
>>>>>
>>>>> Thoughts ?
>>>>>
>>>>
>>>> Am I correctly understanding that, if the SMC64 SOC_ID Name call fails,
>>>> rather than an unconditional fallback to the SMC32 call, the SMC32
>>>> fallback would only be occurring under the proposed erratum?
>>>>
>>>
>>> Correct, if we have unconditional fallback to the SMC32 call, then there
>>> is a chance that this issue gets carried into newer Ampere systems as
>>> f/w
>>> gets copied as well as other vendors will also not notice the issue if
>>> they make similar mistake as the kernel silent makes a SMC32 call.
>>>
>>> We do need details of the SoC revision and version for which we need to
>>> apply this workaround/erratum.
>>
>> So this looks more like a firmware erratum than a SoC specific one,
>> right? So I wonder if any SoC specific IDs are really appropriate here.
>> Is there some firmware version we can read via DMI or so to identify
>> affected systems?
>> Or shall we use a probably much easier SoC or even MIDR check anyway,
>> since it's just a fallback? As in: try smc64, if that fails and if it's
>> a core that ever shipped with that affected firmware, try smc32? I think
>> there is not much harm in trying those FIDs, so we just limit the scope
>> to Ampere cores - even though that's technically not the right method by
>> the book?
>>
>> Cheers,
>> Andre
>>
>>
>>
>>>
>>>> I brought this issue up at a weekly team meeting today, and I'll
>>>> also be
>>>> communicating with the Ampere Computing firmware team regarding this
>>>> issue.
>>>
>>> Thanks!
>>>
>>
>
^ permalink raw reply
* Re: [PATCH v5 16/29] media: rockchip: rga: split flip and rotate into separate function
From: Sven Püschel @ 2026-05-12 14:08 UTC (permalink / raw)
To: Nicolas Dufresne, Jacob Chen, Ezequiel Garcia,
Mauro Carvalho Chehab, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans Verkuil
Cc: linux-media, linux-rockchip, linux-arm-kernel, linux-kernel,
devicetree, kernel, sebastian.reichel
In-Reply-To: <ebe5cd6689923eb1e2124e177f694895383fba54.camel@ndufresne.ca>
Hi Nicolas,
On 5/9/26 12:11 AM, Nicolas Dufresne wrote:
> Le mardi 28 avril 2026 à 11:00 +0200, Sven Püschel a écrit :
>> Split the flip and rotate command configuration into a separate
>> function in preparation of filling the command stream at streamon.
>> As the userspace can change the flipping and rotation controls while
>> streaming, we have to update them with each new frame to prevent the
>> user being unable to change them while streaming.
>>
>> Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
> For code point of view, everything seems fine, but the commit message leave me a
> bit wondering. Any rotation that isn't 180 degree will cause the width and
> height to be reversed, and a new stride is needed to present the buffer
> correctly. Meaning the capture format can be affected by this change.
Sorry for missing to properly communicate my intention with this patch.
I've stumbled over the RGA pulling a spin lock on the controls, when
starting the next job [1]. This made me realize that the driver allows
changing the controls while streaming, which my change to move the
command buffer setup to streamon breaks (as a potential rotation isn't
updated until the next streamon).
This commit is the result of trying to not break the old behavior by
moving the relevant code parts to be run on every frame instead of being
only run at streamon. I didn't think about the 90 degree rotation
problems, which are also present in the current RGA state.
sashiko.dev also pointed out that my simple code move didn't work for
the mirroring case [2], as the relevant command buffer is ore'd with the
mirroring flags. Also I've noticed that the rotation mode affects the
scaling factor. To avoid these footguns, I've got the idea to set a flag
to raise when the controls change. Then I can fully re-initialize the
command buffer on the next frame and fully avoid these kind of problems.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/rockchip/rga/rga.c?id=50897c955902c93ae71c38698abb910525ebdc89#n41
[2]
https://sashiko.dev/#/patchset/20260428-spu-rga3-v5-0-eb7f5d019d86%40pengutronix.de?part=16
>
> To stick with the spec, the capture format needs to be updated, and it needs to
> happen in a way user can be able to read it back for the correct frame if
> userspace make use of the queues. I see 3 options, let me know what you think,
> or what is later implemented if you already thought about that.
>
> 1. Synchronously update the capture format width/height, document in the
> respective control this behaviour, leaving to userspace to remember which frames
> the change will apply to.
>
> This works nicely for this type of HW, but would be a bit complicated for a
> deinterlacer, since the buffering might be HW specific. It also make usage of
> queues harder, less independent.
>
> 2. Force a drain/stop/start for any 90 degree rotation
>
> This might impose a longer idle time for the converter core, and is kind of
> opposite of your commit message. But requires no spec work.
>
> 3. Emit SRC_CH, implement the drain procedure typical to decoder resolution
> change.
>
> Typically it means userspace can keep buffering on the OUTPUT queue, and once
> the LAST buffer is met, it can simply read the new format (and new stride, since
> due to alignment, this might be hardware specific) and toggle streamoff/on only
> on capture queue to reactivate the processing.
>
> The 3. is more complex for the driver, but its a proven race-free method for
> decoders already. 2 would be statusquo to get this series in, and we could post-
> poned more advance work for seamless 90degree rorations. 1., I don't really like
> that solution, it not quite generic enough.
I'll go with option 2 for now to keep it simple and improve the status
quo a bit.
Sincerely
Sven
> feedback welcome,
> Nicolas
>
>> ---
>> drivers/media/platform/rockchip/rga/rga-hw.c | 57 +++++++++++++++++-----------
>> 1 file changed, 34 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/media/platform/rockchip/rga/rga-hw.c b/drivers/media/platform/rockchip/rga/rga-hw.c
>> index dac3cb6aa17d3..6c1956b04f6ba 100644
>> --- a/drivers/media/platform/rockchip/rga/rga-hw.c
>> +++ b/drivers/media/platform/rockchip/rga/rga-hw.c
>> @@ -156,7 +156,38 @@ static void rga_cmd_set_dst_addr(struct rga_ctx *ctx, dma_addr_t dma_addr)
>> dest[reg >> 2] |= 0x7 << 8;
>> }
>>
>> -static void rga_cmd_set_trans_info(struct rga_ctx *ctx)
>> +static void rga_cmd_set_flip_rotate_info(struct rga_ctx *ctx)
>> +{
>> + u32 *dest = ctx->cmdbuf_virt;
>> + union rga_src_info src_info;
>> +
>> + src_info.val = dest[(RGA_SRC_INFO - RGA_MODE_BASE_REG) >> 2];
>> +
>> + if (ctx->vflip)
>> + src_info.data.mir_mode |= RGA_SRC_MIRR_MODE_X;
>> +
>> + if (ctx->hflip)
>> + src_info.data.mir_mode |= RGA_SRC_MIRR_MODE_Y;
>> +
>> + switch (ctx->rotate) {
>> + case 90:
>> + src_info.data.rot_mode = RGA_SRC_ROT_MODE_90_DEGREE;
>> + break;
>> + case 180:
>> + src_info.data.rot_mode = RGA_SRC_ROT_MODE_180_DEGREE;
>> + break;
>> + case 270:
>> + src_info.data.rot_mode = RGA_SRC_ROT_MODE_270_DEGREE;
>> + break;
>> + default:
>> + src_info.data.rot_mode = RGA_SRC_ROT_MODE_0_DEGREE;
>> + break;
>> + }
>> +
>> + dest[(RGA_SRC_INFO - RGA_MODE_BASE_REG) >> 2] = src_info.val;
>> +}
>> +
>> +static void rga_cmd_set_format_scale_info(struct rga_ctx *ctx)
>> {
>> struct rockchip_rga *rga = ctx->rga;
>> u32 *dest = ctx->cmdbuf_virt;
>> @@ -219,27 +250,6 @@ static void rga_cmd_set_trans_info(struct rga_ctx *ctx)
>> }
>> }
>>
>> - if (ctx->vflip)
>> - src_info.data.mir_mode |= RGA_SRC_MIRR_MODE_X;
>> -
>> - if (ctx->hflip)
>> - src_info.data.mir_mode |= RGA_SRC_MIRR_MODE_Y;
>> -
>> - switch (ctx->rotate) {
>> - case 90:
>> - src_info.data.rot_mode = RGA_SRC_ROT_MODE_90_DEGREE;
>> - break;
>> - case 180:
>> - src_info.data.rot_mode = RGA_SRC_ROT_MODE_180_DEGREE;
>> - break;
>> - case 270:
>> - src_info.data.rot_mode = RGA_SRC_ROT_MODE_270_DEGREE;
>> - break;
>> - default:
>> - src_info.data.rot_mode = RGA_SRC_ROT_MODE_0_DEGREE;
>> - break;
>> - }
>> -
>> /*
>> * Calculate the up/down scaling mode/factor.
>> *
>> @@ -431,7 +441,8 @@ static void rga_cmd_set(struct rga_ctx *ctx,
>>
>> rga_cmd_set_src_info(ctx, &src->offset);
>> rga_cmd_set_dst_info(ctx, &dst->offset);
>> - rga_cmd_set_trans_info(ctx);
>> + rga_cmd_set_format_scale_info(ctx);
>> + rga_cmd_set_flip_rotate_info(ctx);
>>
>> rga_write(rga, RGA_CMD_BASE, ctx->cmdbuf_phy);
>>
^ permalink raw reply
* [PATCH 0/2] KVM: arm64: nv: Reduce FP/SVE overhead on exception/exception return
From: Marc Zyngier @ 2026-05-12 14:07 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Mark Rutland, Will Deacon, Fuad Tabba
Staring at NV traces has shown that there is a substantial amount of
overhead being triggered when a guest switches between EL1 and EL2 (or
the reverse). This is caused by the naive put/load mechanism we use to
multiplex EL1 and EL2 onto EL1 only, and the FP handling appears as a
prime candidate for optimisation. More precisely, there are two
distinct sources of overhead here:
- the FP/SVE registers are saved, and potentially the host userspace
state restored when doing put()
- the FP traps are reinstated as part of load(), as the state is now
the host's
These two things mean that we end-up with a lot of work during this
switch, and that we are 100% guaranteed to get a FP/SVE trap very
quickly, as the guest keeps using the FP registers. These traps
themselves result in some horrible trap amplification in even moderate
levels of nesting, which we could trivially avoid. A bit of thinking
indicates that it should be entirely valid to elide this stuff in the
context of a nested exception/exception return.
The first patch in this small series just add a new vcpu state flag
indicating that put() and load() are done in the context of a nested
exception from L2 to L1. This is the exact pendent of IN_NESTED_ERET,
which tracks an ERET from L1 to L2.
The second patch uses these two flags to abruptly elide FP/SVE
save/restore when any of them is set, sidestepping the overhead
entirely.
Performance-wise, this is rather impressive. I get a 10%-20%
improvement on running the Debian installed as an L3 on my QC
platform. Combined with the use of the EL2 virtual timer, it almost
makes L3 usable.
But of course, nothing is simple with this stuff, which is why I'm
cc'ing Mark here, as he's done a lot of work tracking funny bugs in
our FP handling. Hopefully I haven't subtly broken anything, but let's
see!
Marc Zyngier (2):
KVM: arm64: nv: Track L2 to L1 exception emulation
KVM: arm64: nv: Don't save/restore FP register during a nested ERET or
exception
arch/arm64/include/asm/kvm_host.h | 3 ++-
arch/arm64/kvm/emulate-nested.c | 4 ++++
arch/arm64/kvm/fpsimd.c | 8 ++++++++
3 files changed, 14 insertions(+), 1 deletion(-)
--
2.47.3
^ permalink raw reply
* [PATCH 1/2] KVM: arm64: nv: Track L2 to L1 exception emulation
From: Marc Zyngier @ 2026-05-12 14:07 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Mark Rutland, Will Deacon, Fuad Tabba
In-Reply-To: <20260512140755.3676306-1-maz@kernel.org>
While we currently track that we are emulating a nested ERET from
L1 to L2, we currently don't track the reverse direction (an exception
going from L2 to L1).
Add a new vcpu state flag for this purpose, which will see some
use shortly.
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/include/asm/kvm_host.h | 3 ++-
arch/arm64/kvm/emulate-nested.c | 4 ++++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 65eead8362e0b..c79747d5f4dd1 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -1112,7 +1112,8 @@ struct kvm_vcpu_arch {
#define IN_NESTED_ERET __vcpu_single_flag(sflags, BIT(7))
/* SError pending for nested guest */
#define NESTED_SERROR_PENDING __vcpu_single_flag(sflags, BIT(8))
-
+/* KVM is currently emulating an L2 to L1 exception */
+#define IN_NESTED_EXCEPTION __vcpu_single_flag(sflags, BIT(9))
/* Pointer to the vcpu's SVE FFR for sve_{save,load}_state() */
#define vcpu_sve_pffr(vcpu) (kern_hyp_va((vcpu)->arch.sve_state) + \
diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
index dba7ced74ca5e..15c691a6266d5 100644
--- a/arch/arm64/kvm/emulate-nested.c
+++ b/arch/arm64/kvm/emulate-nested.c
@@ -2862,6 +2862,8 @@ static int kvm_inject_nested(struct kvm_vcpu *vcpu, u64 esr_el2,
preempt_disable();
+ vcpu_set_flag(vcpu, IN_NESTED_EXCEPTION);
+
/*
* We may have an exception or PC update in the EL0/EL1 context.
* Commit it before entering EL2.
@@ -2884,6 +2886,8 @@ static int kvm_inject_nested(struct kvm_vcpu *vcpu, u64 esr_el2,
__kvm_adjust_pc(vcpu);
kvm_arch_vcpu_load(vcpu, smp_processor_id());
+ vcpu_clear_flag(vcpu, IN_NESTED_EXCEPTION);
+
preempt_enable();
if (kvm_vcpu_has_pmu(vcpu))
--
2.47.3
^ permalink raw reply related
* [PATCH 2/2] KVM: arm64: nv: Don't save/restore FP register during a nested ERET or exception
From: Marc Zyngier @ 2026-05-12 14:07 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Mark Rutland, Will Deacon, Fuad Tabba
In-Reply-To: <20260512140755.3676306-1-maz@kernel.org>
When switching between L1 and L2, we diligently use a non-preemptible
put/load sequence in order to make sure that the old state is saved,
while the new state is brought in. Crucially, this includes the FP
registers.
However, this is a bit silly. The FP registers are completely shared
between the various ELs (just like the GPRs, really), and eagerly
save/restoring those in a non-preemptible section is just overhead.
Not to mention that the next access will end-up trapping, something
that becomes exponentially expensive as we nest deeper.
The temptation is therefore to completely drop this save/restore thing.
Why is it valid to do so? By analogy, the hypervisor doesn't try to
poloce things between EL1 and EL0, or between EL2 and EL0. Why should
it do so between EL2 and EL1 (or EL2 and L2 EL0)?
Once you admit that the FP (and by extension SVE) registers are EL-agnostic,
the things that matter are:
- 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.
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 | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index 15e17aca1dec0..73eda0f46b127 100644
--- a/arch/arm64/kvm/fpsimd.c
+++ b/arch/arm64/kvm/fpsimd.c
@@ -28,6 +28,10 @@ void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu)
if (!system_supports_fpsimd())
return;
+ if (vcpu_get_flag(vcpu, IN_NESTED_ERET) ||
+ vcpu_get_flag(vcpu, IN_NESTED_EXCEPTION))
+ 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 +106,10 @@ void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
{
unsigned long flags;
+ if (vcpu_get_flag(vcpu, IN_NESTED_ERET) ||
+ vcpu_get_flag(vcpu, IN_NESTED_EXCEPTION))
+ return;
+
local_irq_save(flags);
if (guest_owns_fp_regs()) {
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v4 7/9] nvmet: pci-epf: Use dmaengine_prep_config_single_safe() API
From: Manivannan Sadhasivam @ 2026-05-12 14:06 UTC (permalink / raw)
To: Frank Li
Cc: Vinod Koul, Krzysztof Wilczyński, Kishon Vijay Abraham I,
Bjorn Helgaas, Christoph Hellwig, Sagi Grimberg,
Chaitanya Kulkarni, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Koichiro Den, Niklas Cassel,
dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx
In-Reply-To: <20260506-dma_prep_config-v4-7-85b3d22babff@nxp.com>
On Wed, May 06, 2026 at 04:44:19PM -0400, Frank Li wrote:
> Use the new dmaengine_prep_config_single_safe() API to combine the
> configuration and descriptor preparation into a single call.
>
> Since dmaengine_prep_config_single_safe() performs the configuration and
> preparation atomically and the mutex can be removed.
>
> Tested-by: Niklas Cassel <cassel@kernel.org>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> ---
> drivers/nvme/target/pci-epf.c | 18 ++++--------------
> 1 file changed, 4 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/nvme/target/pci-epf.c b/drivers/nvme/target/pci-epf.c
> index 2afe8f4d0e46104a1b3c98db3905cf33e8c9e011..04d8f48d6950349ca97d2dbeae4e38e4714ad0d4 100644
> --- a/drivers/nvme/target/pci-epf.c
> +++ b/drivers/nvme/target/pci-epf.c
> @@ -388,22 +388,15 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
> return -EINVAL;
> }
>
> - mutex_lock(lock);
> -
> dma_dev = dmaengine_get_dma_device(chan);
> dma_addr = dma_map_single(dma_dev, seg->buf, seg->length, dir);
> ret = dma_mapping_error(dma_dev, dma_addr);
> if (ret)
> - goto unlock;
> -
> - ret = dmaengine_slave_config(chan, &sconf);
> - if (ret) {
> - dev_err(dev, "Failed to configure DMA channel\n");
> - goto unmap;
> - }
> + return ret;
>
> - desc = dmaengine_prep_slave_single(chan, dma_addr, seg->length,
> - sconf.direction, DMA_CTRL_ACK);
> + desc = dmaengine_prep_config_single_safe(chan, dma_addr, seg->length,
> + sconf.direction,
> + DMA_CTRL_ACK, &sconf);
> if (!desc) {
> dev_err(dev, "Failed to prepare DMA\n");
> ret = -EIO;
> @@ -426,9 +419,6 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
> unmap:
> dma_unmap_single(dma_dev, dma_addr, seg->length, dir);
>
> -unlock:
> - mutex_unlock(lock);
> -
> return ret;
> }
>
>
> --
> 2.43.0
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v4 6/9] nvmet: pci-epf: Remove unnecessary dmaengine_terminate_sync() on each DMA transfer
From: Manivannan Sadhasivam @ 2026-05-12 14:05 UTC (permalink / raw)
To: Frank Li
Cc: Vinod Koul, Krzysztof Wilczyński, Kishon Vijay Abraham I,
Bjorn Helgaas, Christoph Hellwig, Sagi Grimberg,
Chaitanya Kulkarni, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Koichiro Den, Niklas Cassel,
dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx,
Damien Le Moal
In-Reply-To: <20260506-dma_prep_config-v4-6-85b3d22babff@nxp.com>
On Wed, May 06, 2026 at 04:44:18PM -0400, Frank Li wrote:
> dmaengine_terminate_sync() cancels all pending requests. Calling it for
> every DMA transfer is unnecessary and counterproductive. This function is
> generally intended for cleanup paths such as module removal, device close,
> or unbind operations.
>
> Remove the redundant calls for success path and keep it only at error path.
>
> Tested-by: Niklas Cassel <cassel@kernel.org>
> Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> ---
> This one also fix stress test failure after remove mutex and use new API
> dmaengine_prep_slave_sg_config().
> ---
> drivers/nvme/target/pci-epf.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/nvme/target/pci-epf.c b/drivers/nvme/target/pci-epf.c
> index 4e9db96ebfecd796244e5dc67c23e1abb1a14974..2afe8f4d0e46104a1b3c98db3905cf33e8c9e011 100644
> --- a/drivers/nvme/target/pci-epf.c
> +++ b/drivers/nvme/target/pci-epf.c
> @@ -420,10 +420,9 @@ static int nvmet_pci_epf_dma_transfer(struct nvmet_pci_epf *nvme_epf,
> if (dma_sync_wait(chan, cookie) != DMA_COMPLETE) {
> dev_err(dev, "DMA transfer failed\n");
> ret = -EIO;
> + dmaengine_terminate_sync(chan);
> }
>
> - dmaengine_terminate_sync(chan);
> -
> unmap:
> dma_unmap_single(dma_dev, dma_addr, seg->length, dir);
>
>
> --
> 2.43.0
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v4 5/9] dmaengine: dw-edma: Pass dma_slave_config to dw_edma_device_transfer()
From: Manivannan Sadhasivam @ 2026-05-12 14:04 UTC (permalink / raw)
To: Frank Li
Cc: Vinod Koul, Krzysztof Wilczyński, Kishon Vijay Abraham I,
Bjorn Helgaas, Christoph Hellwig, Sagi Grimberg,
Chaitanya Kulkarni, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Koichiro Den, Niklas Cassel,
dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx
In-Reply-To: <20260506-dma_prep_config-v4-5-85b3d22babff@nxp.com>
On Wed, May 06, 2026 at 04:44:17PM -0400, Frank Li wrote:
> Pass dma_slave_config to dw_edma_device_transfer() to support atomic
> configuration and descriptor preparation when a non-NULL config is
> provided to device_prep_config_sg().
>
> Tested-by: Niklas Cassel <cassel@kernel.org>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> ---
> change in v3
> - rewrite dw_edma_device_slave_config() according to Damien's suggestion.
> ---
> drivers/dma/dw-edma/dw-edma-core.c | 27 +++++++++++++++++++++------
> 1 file changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
> index f7f58b0010e26b529ffb7382d5b166a703587c71..ec6f6b1e482568a27ebe90852d5679672b24a1e9 100644
> --- a/drivers/dma/dw-edma/dw-edma-core.c
> +++ b/drivers/dma/dw-edma/dw-edma-core.c
> @@ -267,6 +267,20 @@ static int dw_edma_device_config(struct dma_chan *dchan,
> return 0;
> }
>
> +static struct dma_slave_config *
> +dw_edma_device_get_config(struct dma_chan *dchan,
> + struct dma_slave_config *config)
> +{
> + struct dw_edma_chan *chan;
> +
> + if (config)
> + return config;
> +
> + chan = dchan2dw_edma_chan(dchan);
> +
> + return &chan->config;
> +}
> +
> static int dw_edma_device_pause(struct dma_chan *dchan)
> {
> struct dw_edma_chan *chan = dchan2dw_edma_chan(dchan);
> @@ -385,7 +399,8 @@ dw_edma_device_tx_status(struct dma_chan *dchan, dma_cookie_t cookie,
> }
>
> static struct dma_async_tx_descriptor *
> -dw_edma_device_transfer(struct dw_edma_transfer *xfer)
> +dw_edma_device_transfer(struct dw_edma_transfer *xfer,
> + struct dma_slave_config *config)
> {
> struct dw_edma_chan *chan = dchan2dw_edma_chan(xfer->dchan);
> enum dma_transfer_direction dir = xfer->direction;
> @@ -472,8 +487,8 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer)
> src_addr = xfer->xfer.il->src_start;
> dst_addr = xfer->xfer.il->dst_start;
> } else {
> - src_addr = chan->config.src_addr;
> - dst_addr = chan->config.dst_addr;
> + src_addr = config->src_addr;
> + dst_addr = config->dst_addr;
> }
>
> if (dir == DMA_DEV_TO_MEM)
> @@ -595,7 +610,7 @@ dw_edma_device_prep_config_sg(struct dma_chan *dchan, struct scatterlist *sgl,
> if (config)
> dw_edma_device_config(dchan, config);
>
> - return dw_edma_device_transfer(&xfer);
> + return dw_edma_device_transfer(&xfer, dw_edma_device_get_config(dchan, config));
> }
>
> static struct dma_async_tx_descriptor *
> @@ -614,7 +629,7 @@ dw_edma_device_prep_dma_cyclic(struct dma_chan *dchan, dma_addr_t paddr,
> xfer.flags = flags;
> xfer.type = EDMA_XFER_CYCLIC;
>
> - return dw_edma_device_transfer(&xfer);
> + return dw_edma_device_transfer(&xfer, dw_edma_device_get_config(dchan, NULL));
> }
>
> static struct dma_async_tx_descriptor *
> @@ -630,7 +645,7 @@ dw_edma_device_prep_interleaved_dma(struct dma_chan *dchan,
> xfer.flags = flags;
> xfer.type = EDMA_XFER_INTERLEAVED;
>
> - return dw_edma_device_transfer(&xfer);
> + return dw_edma_device_transfer(&xfer, dw_edma_device_get_config(dchan, NULL));
> }
>
> static void dw_hdma_set_callback_result(struct virt_dma_desc *vd,
>
> --
> 2.43.0
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v4 4/9] dmaengine: dw-edma: Use new .device_prep_config_sg() callback
From: Manivannan Sadhasivam @ 2026-05-12 14:03 UTC (permalink / raw)
To: Frank Li
Cc: Vinod Koul, Krzysztof Wilczyński, Kishon Vijay Abraham I,
Bjorn Helgaas, Christoph Hellwig, Sagi Grimberg,
Chaitanya Kulkarni, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Koichiro Den, Niklas Cassel,
dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx,
Damien Le Moal
In-Reply-To: <20260506-dma_prep_config-v4-4-85b3d22babff@nxp.com>
On Wed, May 06, 2026 at 04:44:16PM -0400, Frank Li wrote:
> Use the new .device_prep_config_sg() callback to combine configuration and
> descriptor preparation.
>
> No functional changes.
>
> Tested-by: Niklas Cassel <cassel@kernel.org>
> Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> ---
> change in v4
> - drop context in callback.
> change in v3
> - add Damien Le Moal review tag
> ---
> drivers/dma/dw-edma/dw-edma-core.c | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
> index c2feb3adc79fa94b016913443305b9fae9deef12..f7f58b0010e26b529ffb7382d5b166a703587c71 100644
> --- a/drivers/dma/dw-edma/dw-edma-core.c
> +++ b/drivers/dma/dw-edma/dw-edma-core.c
> @@ -577,10 +577,11 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer)
> }
>
> static struct dma_async_tx_descriptor *
> -dw_edma_device_prep_slave_sg(struct dma_chan *dchan, struct scatterlist *sgl,
> - unsigned int len,
> - enum dma_transfer_direction direction,
> - unsigned long flags, void *context)
> +dw_edma_device_prep_config_sg(struct dma_chan *dchan, struct scatterlist *sgl,
> + unsigned int len,
> + enum dma_transfer_direction direction,
> + unsigned long flags,
> + struct dma_slave_config *config)
> {
> struct dw_edma_transfer xfer;
>
> @@ -591,6 +592,9 @@ dw_edma_device_prep_slave_sg(struct dma_chan *dchan, struct scatterlist *sgl,
> xfer.flags = flags;
> xfer.type = EDMA_XFER_SCATTER_GATHER;
>
> + if (config)
> + dw_edma_device_config(dchan, config);
> +
> return dw_edma_device_transfer(&xfer);
> }
>
> @@ -970,7 +974,7 @@ static int dw_edma_channel_setup(struct dw_edma *dw, u32 wr_alloc, u32 rd_alloc)
> dma->device_terminate_all = dw_edma_device_terminate_all;
> dma->device_issue_pending = dw_edma_device_issue_pending;
> dma->device_tx_status = dw_edma_device_tx_status;
> - dma->device_prep_slave_sg = dw_edma_device_prep_slave_sg;
> + dma->device_prep_config_sg = dw_edma_device_prep_config_sg;
> dma->device_prep_dma_cyclic = dw_edma_device_prep_dma_cyclic;
> dma->device_prep_interleaved_dma = dw_edma_device_prep_interleaved_dma;
>
>
> --
> 2.43.0
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v4 2/9] dmaengine: Add safe API to combine configuration and preparation
From: Manivannan Sadhasivam @ 2026-05-12 14:03 UTC (permalink / raw)
To: Frank Li
Cc: Vinod Koul, Krzysztof Wilczyński, Kishon Vijay Abraham I,
Bjorn Helgaas, Christoph Hellwig, Sagi Grimberg,
Chaitanya Kulkarni, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Koichiro Den, Niklas Cassel,
dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx
In-Reply-To: <20260506-dma_prep_config-v4-2-85b3d22babff@nxp.com>
On Wed, May 06, 2026 at 04:44:14PM -0400, Frank Li wrote:
> Introduce dmaengine_prep_config_single_safe() and
> dmaengine_prep_config_sg_safe() to provide a reentrant-safe way to
> combine slave configuration and transfer preparation.
>
> Drivers may implement the new device_prep_config_sg() callback to perform
> both steps atomically. If the callback is not provided, the helpers fall
> back to calling dmaengine_slave_config() followed by
> dmaengine_prep_slave_sg() under per-channel mutex protection.
>
> Tested-by: Niklas Cassel <cassel@kernel.org>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> chagne in v4
> - use spinlock() to protect config() and prep()
>
> change in v3
> - new patch
> ---
> drivers/dma/dmaengine.c | 2 ++
> include/linux/dmaengine.h | 58 +++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 60 insertions(+)
>
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index 405bd2fbb4a3b94fd0bf44526f656f6a19feaad0..ba29e60160c1a0148793bb299849bccfebb6d32b 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -1099,6 +1099,8 @@ static int __dma_async_device_channel_register(struct dma_device *device,
> chan->dev->device.parent = device->dev;
> chan->dev->chan = chan;
> chan->dev->dev_id = device->dev_id;
> + spin_lock_init(&chan->lock);
> +
> if (!name)
> dev_set_name(&chan->dev->device, "dma%dchan%d", device->dev_id, chan->chan_id);
> else
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index defa377d2ef54d94e6337cdfa7826a091295535e..23728f3d60804e49cd4cbbd3a513c4936eed5836 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -322,6 +322,8 @@ struct dma_router {
> * @slave: ptr to the device using this channel
> * @cookie: last cookie value returned to client
> * @completed_cookie: last completed cookie for this channel
> + * @lock: protect between config and prepare transfer when driver have not
> + * implemented callback device_prep_config_sg().
> * @chan_id: channel ID for sysfs
> * @dev: class device for sysfs
> * @name: backlink name for sysfs
> @@ -341,6 +343,12 @@ struct dma_chan {
> dma_cookie_t cookie;
> dma_cookie_t completed_cookie;
>
> + /*
> + * protect between config and prepare transfer because *_prep() may be
> + * called from complete callback, which is in GFP_NOSLEEP context.
> + */
> + spinlock_t lock; /* protect between config and prepare transfer since */
Why two comments?
> +
> /* sysfs */
> int chan_id;
> struct dma_chan_dev *dev;
> @@ -1068,6 +1076,56 @@ dmaengine_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
> return dmaengine_prep_config_sg(chan, sgl, sg_len, dir, flags, NULL);
> }
>
> +/*
> + * dmaengine_prep_config_single(sg)_safe() is re-entrant version.
> + *
> + * The unsafe variant (without the _safe suffix) falls back to calling
> + * dmaengine_slave_config() and dmaengine_prep_slave_sg() separately.
> + * In this case, additional locking may be required, depending on the
> + * DMA consumer's usage.
> + *
> + * If dmaengine driver have not implemented call back device_prep_config_sg()
> + * safe version use per-channel spinlock to protect call dmaengine_slave_config()
> + * and dmaengine_prep_slave_sg().
> + */
Use proper kernel-doc comments please...
> +static inline struct dma_async_tx_descriptor *
> +dmaengine_prep_config_sg_safe(struct dma_chan *chan, struct scatterlist *sgl,
> + unsigned int sg_len,
> + enum dma_transfer_direction dir,
> + unsigned long flags,
> + struct dma_slave_config *config)
> +{
> + struct dma_async_tx_descriptor *tx;
> +
> + if (!chan || !chan->device)
> + return NULL;
> +
> + if (!chan->device->device_prep_config_sg)
> + spin_lock(&chan->lock);
> +
> + tx = dmaengine_prep_config_sg(chan, sgl, sg_len, dir, flags, config);
> +
> + if (!chan->device->device_prep_config_sg)
> + spin_unlock(&chan->lock);
> +
> + return tx;
> +}
> +
Missing kernel-doc.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v4 1/9] dmaengine: Add API to combine configuration and preparation (sg and single)
From: Manivannan Sadhasivam @ 2026-05-12 14:00 UTC (permalink / raw)
To: Frank Li
Cc: Vinod Koul, Krzysztof Wilczyński, Kishon Vijay Abraham I,
Bjorn Helgaas, Christoph Hellwig, Sagi Grimberg,
Chaitanya Kulkarni, Herbert Xu, David S. Miller, Nicolas Ferre,
Alexandre Belloni, Claudiu Beznea, Koichiro Den, Niklas Cassel,
dmaengine, linux-kernel, linux-pci, linux-nvme, mhi,
linux-arm-msm, linux-crypto, linux-arm-kernel, imx
In-Reply-To: <20260506-dma_prep_config-v4-1-85b3d22babff@nxp.com>
On Wed, May 06, 2026 at 04:44:13PM -0400, Frank Li wrote:
> Previously, configuration and preparation required two separate calls. This
> works well when configuration is done only once during initialization.
>
> However, in cases where the burst length or source/destination address must
> be adjusted for each transfer, calling two functions is verbose and
> requires additional locking to ensure both steps complete atomically.
>
> Add a new API dmaengine_prep_config_single() and dmaengine_prep_config_sg()
> and callback device_prep_config_sg() that combines configuration and
> preparation into a single operation. If the configuration argument is
> passed as NULL, fall back to the existing implementation.
>
> Tested-by: Niklas Cassel <cassel@kernel.org>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
My only concern is that since these APIs are defined as 'inline' functions,
adding more code will end up increasing the kernel Image size.
- Mani
> ---
> change in v4
> - drop context in device_prep_config_sg()
>
> change in v3
> - remove Deprecated for callback device_prep_slave_sg().
> - Move condition check before sg init.
> - split function at return type.
> - move safe version to next patch
>
> change in v2
> - add () for function
> - use short name device_prep_sg(), remove "slave" and "config". the 'slave'
> is reduntant. after remove slave, the function name is difference existed
> one, so remove _config suffix.
> ---
> Documentation/driver-api/dmaengine/client.rst | 9 ++++
> include/linux/dmaengine.h | 63 +++++++++++++++++++++++----
> 2 files changed, 64 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/driver-api/dmaengine/client.rst b/Documentation/driver-api/dmaengine/client.rst
> index d491e385d61a98b8a804cd823caf254a2dc62cf4..5ee5d4a3596dd986b02f1bce3078ca6c4c1fb45a 100644
> --- a/Documentation/driver-api/dmaengine/client.rst
> +++ b/Documentation/driver-api/dmaengine/client.rst
> @@ -80,6 +80,10 @@ The details of these operations are:
>
> - slave_sg: DMA a list of scatter gather buffers from/to a peripheral
>
> + - config_sg: Similar with slave_sg, just pass down dma_slave_config
> + struct to avoid calling dmaengine_slave_config() every time adjusting the
> + burst length or the FIFO address is needed.
> +
> - peripheral_dma_vec: DMA an array of scatter gather buffers from/to a
> peripheral. Similar to slave_sg, but uses an array of dma_vec
> structures instead of a scatterlist.
> @@ -106,6 +110,11 @@ The details of these operations are:
> unsigned int sg_len, enum dma_data_direction direction,
> unsigned long flags);
>
> + struct dma_async_tx_descriptor *dmaengine_prep_config_sg(
> + struct dma_chan *chan, struct scatterlist *sgl,
> + unsigned int sg_len, enum dma_transfer_direction dir,
> + unsigned long flags, struct dma_slave_config *config);
> +
> struct dma_async_tx_descriptor *dmaengine_prep_peripheral_dma_vec(
> struct dma_chan *chan, const struct dma_vec *vecs,
> size_t nents, enum dma_data_direction direction,
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index b3d251c9734e95e1b75cf6763d4d2c3a1c6a9910..defa377d2ef54d94e6337cdfa7826a091295535e 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -835,6 +835,7 @@ struct dma_filter {
> * where the address and size of each segment is located in one entry of
> * the dma_vec array.
> * @device_prep_slave_sg: prepares a slave dma operation
> + * @device_prep_config_sg: prepares a slave DMA operation with dma_slave_config
> * @device_prep_dma_cyclic: prepare a cyclic dma operation suitable for audio.
> * The function takes a buffer of size buf_len. The callback function will
> * be called after period_len bytes have been transferred.
> @@ -934,6 +935,10 @@ struct dma_device {
> struct dma_chan *chan, struct scatterlist *sgl,
> unsigned int sg_len, enum dma_transfer_direction direction,
> unsigned long flags, void *context);
> + struct dma_async_tx_descriptor *(*device_prep_config_sg)(
> + struct dma_chan *chan, struct scatterlist *sgl,
> + unsigned int sg_len, enum dma_transfer_direction direction,
> + unsigned long flags, struct dma_slave_config *config);
> struct dma_async_tx_descriptor *(*device_prep_dma_cyclic)(
> struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
> size_t period_len, enum dma_transfer_direction direction,
> @@ -974,22 +979,44 @@ static inline bool is_slave_direction(enum dma_transfer_direction direction)
> (direction == DMA_DEV_TO_DEV);
> }
>
> -static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_single(
> - struct dma_chan *chan, dma_addr_t buf, size_t len,
> - enum dma_transfer_direction dir, unsigned long flags)
> +static inline struct dma_async_tx_descriptor *
> +dmaengine_prep_config_single(struct dma_chan *chan, dma_addr_t buf, size_t len,
> + enum dma_transfer_direction dir,
> + unsigned long flags,
> + struct dma_slave_config *config)
> {
> struct scatterlist sg;
> +
> + if (!chan || !chan->device)
> + return NULL;
> +
> sg_init_table(&sg, 1);
> sg_dma_address(&sg) = buf;
> sg_dma_len(&sg) = len;
>
> - if (!chan || !chan->device || !chan->device->device_prep_slave_sg)
> + if (chan->device->device_prep_config_sg)
> + return chan->device->device_prep_config_sg(chan, &sg, 1, dir,
> + flags, config);
> +
> + if (config)
> + if (dmaengine_slave_config(chan, config))
> + return NULL;
> +
> + if (!chan->device->device_prep_slave_sg)
> return NULL;
>
> return chan->device->device_prep_slave_sg(chan, &sg, 1,
> dir, flags, NULL);
> }
>
> +static inline struct dma_async_tx_descriptor *
> +dmaengine_prep_slave_single(struct dma_chan *chan, dma_addr_t buf, size_t len,
> + enum dma_transfer_direction dir,
> + unsigned long flags)
> +{
> + return dmaengine_prep_config_single(chan, buf, len, dir, flags, NULL);
> +}
> +
> /**
> * dmaengine_prep_peripheral_dma_vec() - Prepare a DMA scatter-gather descriptor
> * @chan: The channel to be used for this descriptor
> @@ -1010,17 +1037,37 @@ static inline struct dma_async_tx_descriptor *dmaengine_prep_peripheral_dma_vec(
> dir, flags);
> }
>
> -static inline struct dma_async_tx_descriptor *dmaengine_prep_slave_sg(
> - struct dma_chan *chan, struct scatterlist *sgl, unsigned int sg_len,
> - enum dma_transfer_direction dir, unsigned long flags)
> +static inline struct dma_async_tx_descriptor *
> +dmaengine_prep_config_sg(struct dma_chan *chan, struct scatterlist *sgl,
> + unsigned int sg_len, enum dma_transfer_direction dir,
> + unsigned long flags, struct dma_slave_config *config)
> {
> - if (!chan || !chan->device || !chan->device->device_prep_slave_sg)
> + if (!chan || !chan->device)
> + return NULL;
> +
> + if (chan->device->device_prep_config_sg)
> + return chan->device->device_prep_config_sg(chan, sgl, sg_len,
> + dir, flags, config);
> +
> + if (config)
> + if (dmaengine_slave_config(chan, config))
> + return NULL;
> +
> + if (!chan->device->device_prep_slave_sg)
> return NULL;
>
> return chan->device->device_prep_slave_sg(chan, sgl, sg_len,
> dir, flags, NULL);
> }
>
> +static inline struct dma_async_tx_descriptor *
> +dmaengine_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
> + unsigned int sg_len, enum dma_transfer_direction dir,
> + unsigned long flags)
> +{
> + return dmaengine_prep_config_sg(chan, sgl, sg_len, dir, flags, NULL);
> +}
> +
> #ifdef CONFIG_RAPIDIO_DMA_ENGINE
> struct rio_dma_ext;
> static inline struct dma_async_tx_descriptor *dmaengine_prep_rio_sg(
>
> --
> 2.43.0
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: iio: adc: Convert xilinx-xadc bindings to YAML schema
From: David Lechner @ 2026-05-12 13:58 UTC (permalink / raw)
To: Rob Herring
Cc: Jonathan Cameron, Pramod Maurya, Nuno Sá, Andy Shevchenko,
Krzysztof Kozlowski, Conor Dooley, Michal Simek,
Lars-Peter Clausen, linux-iio, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <CAL_JsqLxtWLR+jxRXt7Uz6dcF-90NYmfyGWYQk9um9TYHSWbTw@mail.gmail.com>
On 5/12/26 7:14 AM, Rob Herring wrote:
> On Mon, May 11, 2026 at 11:24 AM David Lechner <dlechner@baylibre.com> wrote:
>>
>> On 5/11/26 11:15 AM, Jonathan Cameron wrote:
>>> On Sun, 10 May 2026 08:01:36 -0400
>>> Pramod Maurya <pramod.nexgen@gmail.com> wrote:
>>>
>>>> Convert the Xilinx XADC and UltraScale System Monitor device tree binding
>>>> from the legacy plain-text format to a YAML schema, enabling automated
>>>> validation with dt-schema.
>>>>
>>>> The new binding covers the same hardware and compatible strings:
>>>> - xlnx,zynq-xadc-1.00.a (ZYNQ hardmacro)
>>>> - xlnx,axi-xadc-1.00.a (AXI softmacro)
>>>> - xlnx,system-management-wiz-1.3 (UltraScale System Management Wizard)
>>>>
>>>> Signed-off-by: Pramod Maurya <pramod.nexgen@gmail.com>
>>> Hi Pramod,
>>>
>>> Something went wrong with your sending of v3. I have two versions sent
>>> half a day apart and no idea how they are related.
>>>
>>> Anyhow one of them got feedback from Rob's bot so I'll assume we are
>>> getting a v4 and wait for that.
>>>
>>> Jonathan
>>
>> I think Rob will have to fix the bot to make an exception for the
>> legacy bindings. This should have been called out in the commit message
>> as requested in a previous revision.
>
> The bot is not the problem. It just runs validation. The schemas will
> have to either drop this check (comma's in nodenames) or exclude just
> this property.
>
>
> Rob
Even though this is an existing text-based schema that has been around
for 12 years with this name already? Changing it could be a breaking
change to existing users. Although there aren't any in any .dts in the
kernel source.
^ permalink raw reply
* Re: [PATCH] ARM: OMAP2+: Make OMAP4 finish_suspend callback CFI-safe
From: Nathan Chancellor @ 2026-05-12 13:57 UTC (permalink / raw)
To: Andreas Kemnade
Cc: Mithil Bavishi, Aaro Koskinen, Kevin Hilman, Roger Quadros,
Tony Lindgren, Russell King, Sami Tolvanen, Kees Cook,
linux-arm-kernel, linux-omap, llvm, linux-kernel
In-Reply-To: <20260512100207.3d24837e@kemnade.info>
On Tue, May 12, 2026 at 10:02:07AM +0200, Andreas Kemnade wrote:
> On Tue, 12 May 2026 16:34:42 +0900
> Nathan Chancellor <nathan@kernel.org> wrote:
>
> > On Tue, May 12, 2026 at 12:23:41AM -0400, Mithil Bavishi wrote:
> > > With CONFIG_CFI enabled, OMAP4 can trap in omap4_enter_lowpower()
> > > because omap_pm_ops.finish_suspend points directly to the assembly
> > > routine omap4_finish_suspend, which lacks the expected KCFI type
> > > metadata.
> >
> > It sounds like omap4_finish_suspend() should be defined with
> > SYM_TYPED_FUNC_START then? Is that the case for all of the other
> > functions that are added to omap_pm_ops?
> >
> omap_cpu_resume: the address is written to some cpu register and
> on that way casted to u32. So therefore does not trigger CFI.
> Same for secondary_startup which is also assembler code.
> scu_prepare is C.
>
> DO you have a pointer to any documentation:
> :~/linux$ grep -R SYM_TYPED_FUNC_START Documentation/
I don't think we have any formal documentation for SYM_TYPED_FUNC_START
(it should probably be documented via kernel-doc?) but you can read the
commit message of the change that added it for more information:
e84e008e7b02 ("cfi: Add type helper macros")
--
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH v2 01/16] dt-bindings: iio: adc: mt6359: generalize description for mt63xx series
From: Roman Vivchar @ 2026-05-12 13:55 UTC (permalink / raw)
To: Jonathan Cameron
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Sen Chu, Sean Wang, Macpaul Lin,
Lee Jones, Srinivas Kandagatla, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, linux-iio, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-pm, Ben Grisdale
In-Reply-To: <20260512141313.425535d9@jic23-huawei>
On Tuesday, May 12th, 2026 at 4:13 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> On Tue, 12 May 2026 08:18:15 +0300
> Roman Vivchar via B4 Relay <devnull+rva333.protonmail.com@kernel.org> wrote:
>
> > From: Roman Vivchar <rva333@protonmail.com>
> >
> > Update binding title to the MT63xx, since the list of compatibles already
> > includes mt6363 and mt6373 which don't belong to the mt6350 family.
> Hi Roman,
>
> Wild cards have a nasty habit of going wrong. I'd prefer to see
> language like: MT6359 and similar PMIC AUXADC
Hi Jonathan,
I agree that it would be better to specify the exact PMIC models, however
'similar' wording might be a bit misleading here. As far as I know,
the mt6363 and mt6373 use SPMI, while mt635x (and older models, like
most of the mt63xx series) use PWRAP (a custom SPI-based protocol).
The mt6323 has an older AUXADC revision which is not compatible
with the mt635x driver.
Would you prefer more explicit list like 'MT6323, MT6350 series, MT6363
and MT6373 PMIC AUXADC'? It's a bit mess because some mt63xx
(like mt6333) are sub-PMICs and use I2C instead of PWRAP.
> It is less important here than in many other places because the
> file has an explicit list soon after this, but none the less
> we've been bitten by this too often to think manufacturers won't
> throw a completely non compatible part in the middle of a wild
> card covered range.
>
Best regards,
Roman
^ 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