* [PATCH v13 2/5] drm/gem/shmem: Introduce __drm_gem_shmem_free_sgt_locked()
From: Lyude Paul @ 2026-04-28 19:03 UTC (permalink / raw)
To: nouveau, Gary Guo, Daniel Almeida, rust-for-linux,
Danilo Krummrich, dri-devel
Cc: Matthew Maurer, FUJITA Tomonori, Lorenzo Stoakes,
christian.koenig, Asahi Lina, Miguel Ojeda, Andreas Hindborg,
Simona Vetter, Alice Ryhl, Boqun Feng, Sumit Semwal,
Krishna Ketan Rai, linux-media, Shankari Anand, David Airlie,
Benno Lossin, Viresh Kumar, linaro-mm-sig, Asahi Lina,
Greg Kroah-Hartman, kernel
In-Reply-To: <20260428190605.3355690-1-lyude@redhat.com>
One of the complications of trying to use the shmem helpers to create a
scatterlist for shmem objects is that we need to be able to provide a
guarantee that the driver cannot be unbound for the lifetime of the
scatterlist.
The easiest way of handling this seems to be just hooking up an unmap
operation to devres the first time we create a scatterlist, which allows us
to still take advantage of gem shmem facilities without breaking that
guarantee. To allow for this, we extract __drm_gem_shmem_free_sgt_locked()
- which allows a caller (e.g. the rust bindings) to manually unmap the sgt
for a gem object as needed.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
---
V10:
* Fix incorrect function name in documentation for
__drm_gem_shmem_release_sgt_locked()
drivers/gpu/drm/drm_gem_shmem_helper.c | 32 +++++++++++++++++++++-----
include/drm/drm_gem_shmem_helper.h | 1 +
2 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 545933c7f7121..c989459eb2159 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -158,6 +158,30 @@ struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev, size_t
}
EXPORT_SYMBOL_GPL(drm_gem_shmem_create);
+/**
+ * __drm_gem_shmem_release_sgt_locked - Unpin and DMA unmap pages, and release the
+ * cached scatter/gather table for an shmem GEM object.
+ * @shmem: shmem GEM object
+ *
+ * If the passed shmem object has an active scatter/gather table for driver
+ * usage, this function will unmap it and release the memory associated with it.
+ * It is the responsibility of the caller to ensure it holds the dma_resv_lock
+ * for this object.
+ *
+ * Drivers should not need to call this function themselves, it is mainly
+ * intended for usage in the Rust shmem bindings.
+ */
+void __drm_gem_shmem_free_sgt_locked(struct drm_gem_shmem_object *shmem)
+{
+ dma_resv_assert_held(shmem->base.resv);
+
+ dma_unmap_sgtable(shmem->base.dev->dev, shmem->sgt, DMA_BIDIRECTIONAL, 0);
+ sg_free_table(shmem->sgt);
+ kfree(shmem->sgt);
+ shmem->sgt = NULL;
+}
+EXPORT_SYMBOL_GPL(__drm_gem_shmem_free_sgt_locked);
+
/**
* drm_gem_shmem_release - Release resources associated with a shmem GEM object.
* @shmem: shmem GEM object
@@ -176,12 +200,8 @@ void drm_gem_shmem_release(struct drm_gem_shmem_object *shmem)
drm_WARN_ON(obj->dev, refcount_read(&shmem->vmap_use_count));
- if (shmem->sgt) {
- dma_unmap_sgtable(obj->dev->dev, shmem->sgt,
- DMA_BIDIRECTIONAL, 0);
- sg_free_table(shmem->sgt);
- kfree(shmem->sgt);
- }
+ if (shmem->sgt)
+ __drm_gem_shmem_free_sgt_locked(shmem);
if (shmem->pages)
drm_gem_shmem_put_pages_locked(shmem);
diff --git a/include/drm/drm_gem_shmem_helper.h b/include/drm/drm_gem_shmem_helper.h
index 5ccdae21b94a9..b2c23af628e1a 100644
--- a/include/drm/drm_gem_shmem_helper.h
+++ b/include/drm/drm_gem_shmem_helper.h
@@ -111,6 +111,7 @@ int drm_gem_shmem_init(struct drm_device *dev, struct drm_gem_shmem_object *shme
struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev, size_t size);
void drm_gem_shmem_release(struct drm_gem_shmem_object *shmem);
void drm_gem_shmem_free(struct drm_gem_shmem_object *shmem);
+void __drm_gem_shmem_free_sgt_locked(struct drm_gem_shmem_object *shmem);
void drm_gem_shmem_put_pages_locked(struct drm_gem_shmem_object *shmem);
int drm_gem_shmem_pin(struct drm_gem_shmem_object *shmem);
--
2.54.0
^ permalink raw reply related
* [PATCH v13 1/5] rust: drm: gem: s/device::Device/Device/ for shmem.rs
From: Lyude Paul @ 2026-04-28 19:03 UTC (permalink / raw)
To: nouveau, Gary Guo, Daniel Almeida, rust-for-linux,
Danilo Krummrich, dri-devel
Cc: Matthew Maurer, FUJITA Tomonori, Lorenzo Stoakes,
christian.koenig, Asahi Lina, Miguel Ojeda, Andreas Hindborg,
Simona Vetter, Alice Ryhl, Boqun Feng, Sumit Semwal,
Krishna Ketan Rai, linux-media, Shankari Anand, David Airlie,
Benno Lossin, Viresh Kumar, linaro-mm-sig, Asahi Lina,
Greg Kroah-Hartman, kernel
In-Reply-To: <20260428190605.3355690-1-lyude@redhat.com>
We're about to start explicitly mentioning kernel devices as well in this
file, so this makes it easier to differentiate the two by allowing us to
import `device` as `kernel::device`.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
---
V11:
* Fix location of //
rust/kernel/drm/gem/shmem.rs | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/rust/kernel/drm/gem/shmem.rs b/rust/kernel/drm/gem/shmem.rs
index e1b648920d2f6..35d7523e164ff 100644
--- a/rust/kernel/drm/gem/shmem.rs
+++ b/rust/kernel/drm/gem/shmem.rs
@@ -12,10 +12,10 @@
use crate::{
container_of,
drm::{
- device,
driver,
gem,
- private::Sealed, //
+ private::Sealed,
+ Device, //
},
error::to_result,
prelude::*,
@@ -106,7 +106,7 @@ fn as_raw_shmem(&self) -> *mut bindings::drm_gem_shmem_object {
///
/// Additional config options can be specified using `config`.
pub fn new(
- dev: &device::Device<T::Driver>,
+ dev: &Device<T::Driver>,
size: usize,
config: ObjectConfig<'_, T>,
args: T::Args,
@@ -148,9 +148,9 @@ pub fn new(
}
/// Returns the `Device` that owns this GEM object.
- pub fn dev(&self) -> &device::Device<T::Driver> {
+ pub fn dev(&self) -> &Device<T::Driver> {
// SAFETY: `dev` will have been initialized in `Self::new()` by `drm_gem_shmem_init()`.
- unsafe { device::Device::from_raw((*self.as_raw()).dev) }
+ unsafe { Device::from_raw((*self.as_raw()).dev) }
}
extern "C" fn free_callback(obj: *mut bindings::drm_gem_object) {
--
2.54.0
^ permalink raw reply related
* [PATCH v13 0/5] Rust bindings for gem shmem
From: Lyude Paul @ 2026-04-28 19:03 UTC (permalink / raw)
To: nouveau, Gary Guo, Daniel Almeida, rust-for-linux,
Danilo Krummrich, dri-devel
Cc: Matthew Maurer, FUJITA Tomonori, Lorenzo Stoakes,
christian.koenig, Asahi Lina, Miguel Ojeda, Andreas Hindborg,
Simona Vetter, Alice Ryhl, Boqun Feng, Sumit Semwal,
Krishna Ketan Rai, linux-media, Shankari Anand, David Airlie,
Benno Lossin, Viresh Kumar, linaro-mm-sig, Asahi Lina,
Greg Kroah-Hartman, kernel
Most of this patch series has already been pushed upstream, this is just
the second half of the patch series that has not been pushed yet + some
additional changes which were required to implement changes requested by
the mailing list. This patch series is originally from Asahi, previously
posted by Daniel Almeida.
The previous version of the patch series can be found here:
https://patchwork.freedesktop.org/series/164580/
Branch with patches applied available here
sure this builds:
https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem
This patch series applies on top of drm-rust-next
Lyude Paul (5):
rust: drm: gem: s/device::Device/Device/ for shmem.rs
drm/gem/shmem: Introduce __drm_gem_shmem_free_sgt_locked()
rust: drm: gem/shmem: Add DmaResvGuard helper
rust: drm: gem: Introduce shmem::SGTable
rust: drm: gem: Add vmap functions to shmem bindings
drivers/gpu/drm/drm_gem_shmem_helper.c | 32 +-
include/drm/drm_gem_shmem_helper.h | 1 +
rust/kernel/drm/gem/shmem.rs | 602 ++++++++++++++++++++++++-
3 files changed, 614 insertions(+), 21 deletions(-)
base-commit: d9a6809478f9815b6455a327aa001737ac7b2c09
--
2.54.0
^ permalink raw reply
* Re: [PATCH v2] staging: tegra-video: Align wrapped function arguments
From: Dan Carpenter @ 2026-04-28 18:59 UTC (permalink / raw)
To: Marc Hanna
Cc: linux-media, linux-staging, linux-tegra, linux-kernel,
thierry.reding, jonathanh, skomatineni, luca.ceresoli, mchehab,
gregkh
In-Reply-To: <20260428185024.853-1-marchanna111@gmail.com>
The subject still says the patch is aligning function arguments when
the patch is about long lines.
On Tue, Apr 28, 2026 at 01:50:24PM -0500, Marc Hanna wrote:
> Align wrapped arguments in tegra20.c
> to follow kernel coding style.
>
> v2:
> - Fix From header
> - Update commit message per review feedback
>
This goes under the --- cut off line.
> Signed-off-by: Marc Hanna <marchanna111@gmail.com>
> ---
^^^
here.
https://staticthinking.wordpress.com/2022/07/27/how-to-send-a-v2-patch/
regards,
dan carpenter
^ permalink raw reply
* [PATCH v2] staging: tegra-video: Align wrapped function arguments
From: Marc Hanna @ 2026-04-28 18:50 UTC (permalink / raw)
To: linux-media
Cc: linux-staging, linux-tegra, linux-kernel, thierry.reding,
jonathanh, skomatineni, luca.ceresoli, mchehab, gregkh,
Marc Hanna
Align wrapped arguments in tegra20.c
to follow kernel coding style.
v2:
- Fix From header
- Update commit message per review feedback
Signed-off-by: Marc Hanna <marchanna111@gmail.com>
---
drivers/staging/media/tegra-video/tegra20.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/tegra-video/tegra20.c b/drivers/staging/media/tegra-video/tegra20.c
index e513e6ccb776..eb1fc5b7e2cd 100644
--- a/drivers/staging/media/tegra-video/tegra20.c
+++ b/drivers/staging/media/tegra-video/tegra20.c
@@ -552,7 +552,8 @@ static void tegra20_channel_vi_buffer_setup(struct tegra_vi_channel *chan,
case V4L2_PIX_FMT_YUYV:
case V4L2_PIX_FMT_YVYU:
tegra20_vi_write(chan, TEGRA_VI_VB0_BASE_ADDRESS(TEGRA_VI_OUT_1), base);
- tegra20_vi_write(chan, TEGRA_VI_VB0_START_ADDRESS(TEGRA_VI_OUT_1), base + chan->start_offset);
+ tegra20_vi_write(chan, TEGRA_VI_VB0_START_ADDRESS(TEGRA_VI_OUT_1),
+ base + chan->start_offset);
break;
/* RAW8 */
case V4L2_PIX_FMT_SRGGB8:
@@ -565,7 +566,8 @@ static void tegra20_channel_vi_buffer_setup(struct tegra_vi_channel *chan,
case V4L2_PIX_FMT_SGBRG10:
case V4L2_PIX_FMT_SBGGR10:
tegra20_vi_write(chan, TEGRA_VI_VB0_BASE_ADDRESS(TEGRA_VI_OUT_2), base);
- tegra20_vi_write(chan, TEGRA_VI_VB0_START_ADDRESS(TEGRA_VI_OUT_2), base + chan->start_offset);
+ tegra20_vi_write(chan, TEGRA_VI_VB0_START_ADDRESS(TEGRA_VI_OUT_2),
+ base + chan->start_offset);
break;
}
}
--
2.43.0
^ permalink raw reply related
* Re: [ANNv4] Media Summit on May 26th in Nice, France
From: Nicolas Dufresne @ 2026-04-28 17:54 UTC (permalink / raw)
To: Hans Verkuil, Jacopo Mondi, Laurent Pinchart
Cc: Loic Poulain, Michael Riesch, Ricardo Ribalda,
Linux Media Mailing List, Mauro Carvalho Chehab, Sean Young,
Sakari Ailus, Niklas Söderlund, Tomi Valkeinen, Alain Volmat,
Bryan O'Donoghue, Dave Stevenson, Daniel Almeida,
Michael Tretter, Tomasz Figa, Steve Cho, Kieran Bingham,
Kevin Hilman, Paul Kocialkowski, Benjamin Mugnier, Hans de Goede,
Maxime Ripard, Brandon Brnich, Marco Felsch, Sven Püschel,
Devarsh Thakkar, Yemike Abhilash Chandra, Jackson Lee, Jai Luthra,
Mehdi Djait, Padhi, Beleswar, Donadkar, Rishikesh,
Rouven Czerwinski, Nayden Kanchev, Konstantin Babin,
Anthony McGivern
In-Reply-To: <77ea77b9-5503-40b2-882b-e96e30028c43@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 21388 bytes --]
Le mardi 28 avril 2026 à 15:00 +0200, Hans Verkuil a écrit :
> On 4/28/26 14:30, Jacopo Mondi wrote:
> > Hello
> >
> > On Tue, Apr 14, 2026 at 11:42:59AM +0300, Laurent Pinchart wrote:
> > > On Tue, Apr 14, 2026 at 10:34:13AM +0200, Loic Poulain wrote:
> > > > On Tue, Apr 14, 2026 at 9:42 AM Laurent Pinchart wrote:
> > > > > On Tue, Apr 14, 2026 at 09:20:56AM +0200, Michael Riesch wrote:
> > > > > > On 4/14/26 08:55, Ricardo Ribalda wrote:
> > > > > > > On Tue, 14 Apr 2026 at 08:47, Hans Verkuil <hverkuil+cisco@kernel.org> wrote:
> > > > > > > > On 13/04/2026 23:16, Laurent Pinchart wrote:
> > > > > > > > > On Mon, Apr 13, 2026 at 04:25:54PM -0400, Nicolas Dufresne wrote:
> > > > > > > > > > Le lundi 13 avril 2026 à 23:19 +0300, Laurent Pinchart a écrit :
> > > > > > > > > > > On Mon, Apr 13, 2026 at 10:03:52PM +0200, Loic Poulain wrote:
> > > > > > > > > > > > Hi Hans,
> > > > > > > > > > > >
> > > > > > > > > > > > I would be happy to discuss this if a slot is available:
> > > > > > > > > > > >
> > > > > > > > > > > > Title: Generic V4L2 ISP M2M framework
> > > > > > > > > > > > Presenter: Loic Poulain
> > > > > > > > > > > > Time estimate: ~20min
> > > > > > > > > > > > Description: During early development of a Qualcomm Offline Image
> > > > > > > > > > > > Processing Engine (OPE), we relied on the V4L2 memory‑to‑memory
> > > > > > > > > > > > (v4l2‑m2m) framework, which is widely used and provides solid support
> > > > > > > > > > > > for buffer management and scheduling. However, applying it to an ISP
> > > > > > > > > > > > use case exposes limitations: ISP engines often require a richer media
> > > > > > > > > > > > graph, with multiple pads and metadata flows, similar to inline ISP
> > > > > > > > > > > > pipelines (params, stats, outputs). This talk proposes discussing the
> > > > > > > > > > > > need for and design of a common V4L2 ISP M2M framework to factor out
> > > > > > > > > > > > shared functionality across drivers, particularly around buffer/queue
> > > > > > > > > > > > management and job scheduling.
> > > > > >
> > > > > > It seems that we share some pain points.. :-) :-/
> > > > > >
> > > > > > Over the last year, some ideas have been brewing in my mind. Not
> > > > > > necessarily *my* ideas, mind you, rather ideas that have been around in
> > > > > > linux-media for quite a while, actually. What I would like to prepare
> > > > > > for the Media Summit goes along the same lines.
> > > > > >
> > > > > > > > > > > That's well aligned with the v4l2-isp framework that Jacopo started, and
> > > > > > > > > > > to the multi-context and media-jobs APIs that we have proposed. I
> > > > > > > > > > > wonder, however, if a short session at the media summit will be enough,
> > > > > > > > > > > or if we should try to organize a half day brainstorming workshop at
> > > > > > > > > > > some point. Depending on when the people interested in this topic plan
> > > > > > > > > > > to arrive, Monday could be an option.
> > > > > > > > > >
> > > > > > > > > > I'm also/still interested in the multi-context for m2m decoders that have inline
> > > > > > > > > > post-processing capabilities (current model forces us to waste a lot of RAM). We
> > > > > > > > > > just restarted some design discussion with the team, with an increased
> > > > > > > > > > confidence that multi-context is the way. The scheduler could come handy in the
> > > > > > > > > > future if we get to deal with more multi-stage codecs in the future. I'll be in
> > > > > > > > > > Nice all day Monday.
> > > > > > > > >
> > > > > > > > > I will unfortunately be available only until 15:00 on Monday, but Jacopo
> > > > > > > > > should be available through the day. Let's see who would be interested
> > > > > > > > > and available, and try to organize something.
> > > > > > > >
> > > > > > > > I'm available on Monday as well. I think this is a topic that is well suited
> > > > > > > > to a brainstorm session.
> > > > > > >
> > > > > > > I am also available on Monday and would like to attend the session.
> > > > > >
> > > > > > I'd be interested too. Right now the plan is to arrive on Monday
> > > > > > afternoon. Depending on what time you agree on it may work out anyway.
> > > > > > It would be great to know the exact time this session will start (as I
> > > > > > might need to adjust my travel arrangements).
> > > >
> > > > I can arrive on Monday, with a preference for the afternoon.
> > > >
> > > > > We need a volunteer to organize this, as in finding and booking a
> > > > > meeting space. Note that Monday is a public holiday in France (Monday
> > > > > the 25th of May in particular, not all Mondays).
> > > > >
> > > > > If the number of attendees was small I was thinking of hosting the event
> > > > > in the place where the Ideas on Board team will be staying, but it looks
> > > > > like we're already reaching a fair number of people.
> > > > >
> >
> > Are we still considering this BoF session ?
> >
> > We would someone to volunteer organizing this, at @IoB we're quite
> > full for the week and we might have an hard time organizing this one
> > on top of the libcamera workshop.
> >
> > As Laurent said, that Monday is a public holiday in France, and
> > getting a room somewhere might be complicated.
> >
> > We can host some people in the location where we're having the yearly IoB
> > get-together, but you should arrange your travel there (35 minutes
> > from Nice by car).
> >
> > If we get a volunteer we can should maybe a dedicated mail thread as this one
> > was about the Media Summit ?
>
> If the number of people can be kept low (say <= 6), then it shouldn't be a
> problem to just find a hotel restaurant or similar, close to the place of
> the media summit, and just sit together.
>
> Who would be the key people for this? And who are 'nice to have'? :-)
> I think I probably fit more in the latter category than the first.
I was hoping a small number of people and a simple café/lobby too. The mass of
people interested in the reply arrive much later, but I'm there all day, and
would be more then happy to be able to brainstorm the subject a bit, which is
easier in small group.
Nicolas
p.s. once we know how many, if its too big, I can always abuse Mark again and
ask him to figure-out something for us.
>
> Regards,
>
> Hans
>
> >
> >
> > > > > > > Regards!
> > > > > > >
> > > > > > > > The agenda for the media summit is getting quite full, and I agree with Laurent
> > > > > > > > that 20 minutes is likely not enough. If we can so a session on Monday instead,
> > > > > > > > then that would be a good solution.
> > > > > >
> > > > > > Apart from the time and date the scope of this session would be interesting.
> > > > > >
> > > > > > Will this be a birds of a feather session in which the next generation
> > > > > > kernel ISP framework will be discussed? Or even the next generation
> > > > > > kernel video processing framework, where video processing is image
> > > > > > signal processing, encoding/decoding, 2D graphics processing (fisheye
> > > > > > correction units, 2D GPU such as the Rockchip RGA3, ...)?
> > > > >
> > > > > I would focus on Loic's original scope. If the solution can be used for
> > > > > other devices that's great too. I believe that the current multi-context
> > > > > patch series is a good fit for codecs. If we broaden the scope too much
> > > > > right away we'll achieve nothing.
> > > > >
> > > > > > > > I have never been very enthusiastic about the m2m framework: it's fine for e.g.
> > > > > > > > simple scalers, but it's awkward to use for codecs let alone ISPs.
> > > > > > > >
> > > > > > > > I always felt that we really need variants of the m2m framework that are customized
> > > > > > > > to specific use-cases: i.e. a codec m2m framework, and (perhaps) an ISP m2m framework.
> > > > > > > >
> > > > > > > > The big problem with that is of course who will do the work. Making new frameworks
> > > > > > > > is difficult and takes a long time.
> > > >
> > > > A couple of weeks ago, I submitted an initial driver for a Qualcomm
> > > > Offline ISP based on the standard v4l2-m2m framework. Following
> > > > discussions around which parts could be generalized, I started
> > > > migrating this work to a new v4l2-isp-m2m framework:
> > > > (https://github.com/loicpoulain/linux/commit/5d575d7eff8f2371e91d8237148ffdb44b0af5b0).
> > >
> > > I definitely want to discuss this, but I will be available on Monday
> > > until 15:00 only.
> > >
> > > > The API and overall logic closely mirror v4l2-m2m.c, but are extended
> > > > to address ISP‑specific requirements such as multi‑device support and
> > > > multiple queue handling.
> > >
> > > That part I don't like. The V4L2 M2M framework is a big mid-layer that
> > > prevents drivers from having control of how operations are handled. It
> > > does too much, and doesn't give enough flexibility to drivers. It may
> > > have been fine when the framework was designed, for the devices we had
> > > back then, but today it's just painful. I want to turn this around and
> > > give control to the drivers, with helpers they can use to implement
> > > parts that are not driver-specific. This needs to be opt-in, not a layer
> > > that takes completely control between the uAPI and driver operations.
> > >
> > > Let's not reproduce the design mistakes made in the V4L2 M2M framework.
> > >
> > > I also think you need to decouple the context handling and scheduling in
> > > two separate components. They need to work together, but shouldn't be
> > > bundled into a monolithic system. Very importantly, a driver should be
> > > able to implement contexts with the multi-context helpers, and implement
> > > custom scheduling itself.
> > >
> > > > I am planning to submit this work as an RFC
> > > > before the Media Summit. At this stage, the framework is still fairly
> > > > basic and primarily tailored to the Qualcomm use case. There is
> > > > definitely room for improvement, for example, integrating Jacopo’s
> > > > multi‑context support, since for now, the Qualcomm driver simply
> > > > instantiates a single ISP‑M2M context.
> > > >
> > > > As I am still getting familiar with the media subsystem, this work may
> > > > overlap with or conflict with ongoing efforts. Synchronizing seems
> > > > indeed important. Based on my current understanding, there are several
> > > > related areas of work that appear either complementary or orthogonal:
> > > > - Multi‑context support, to instantiate multiple processing sessions
> > > > on shared hardware/driver.
> > > > - Media jobs, to synchronize work across multiple drivers within the
> > > > same media pipeline.
> > > > - ISP M2M, aiming to provide a v4l2-m2m‑like framework specifically
> > > > for memory‑to‑memory ISP devices.
> > > >
> > > > > > This may be naive and overly optimistic, but I feel there is quite a
> > > > > > number of people sharing the same pain points (which are similar to
> > > > > > those Loic pointed out). Maybe (hopefully) this birds of a feather
> > > > > > session leads to the formation of some work group?
> > > > > >
> > > > > > > > > > > > On Sun, Apr 12, 2026 at 12:25 PM Hans Verkuil wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > (Please pass this on to anyone you think might be interested in this!)
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi all,
> > > > > > > > > > > > >
> > > > > > > > > > > > > This is the fourth version of this announcement, updating the list of attendees
> > > > > > > > > > > > > and the tentative agenda at the end: please let me know if you see mistakes.
> > > > > > > > > > > > > Note that there is still time for one or two other topics. Also please check
> > > > > > > > > > > > > the agenda if you need more (or perhaps less) time for your topic.
> > > > > > > > > > > > >
> > > > > > > > > > > > > This year's Media Summit will be held on Tuesday May 26th the day before the
> > > > > > > > > > > > > Embedded Recipes Conference in Nice, France:
> > > > > > > > > > > > >
> > > > > > > > > > > > > https://embedded-recipes.org/2026/
> > > > > > > > > > > > >
> > > > > > > > > > > > > The Media Summit will be held at Hotel Campanile and in the same meeting room
> > > > > > > > > > > > > as last year (Nikaia):
> > > > > > > > > > > > >
> > > > > > > > > > > > > https://nice-aeroport.campanile.com/en-us/
> > > > > > > > > > > > >
> > > > > > > > > > > > > It is close to the Airport and to the Embedded Recipes venue.
> > > > > > > > > > > > >
> > > > > > > > > > > > > The meeting room can hold up to 30 people and I will provide video conferencing support,
> > > > > > > > > > > > > just like last year. The location and the meeting room was quite nice last year, so
> > > > > > > > > > > > > I saw no need to change it.
> > > > > > > > > > > > >
> > > > > > > > > > > > > That said, in-person participation is very much preferred. This yearly summit is meant
> > > > > > > > > > > > > for active media developers to meet face-to-face and to discuss media subsystem issues.
> > > > > > > > > > > > >
> > > > > > > > > > > > > And it is also a good opportunity to talk to each other during the Embedded Recipes
> > > > > > > > > > > > > conference to discuss topics in a smaller group. But if you are an active media developer
> > > > > > > > > > > > > and are really not able to attend in person, then remote participation is an option.
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you want to attend the meeting (either in person or remote), then send an email to me
> > > > > > > > > > > > > directly. The deadline for in-person attendance is May 14 as the hotel needs to know the
> > > > > > > > > > > > > final number of attendees by then.
> > > > > > > > > > > > >
> > > > > > > > > > > > > There is no registration fee, the meeting room is sponsored by Cisco and Collabora, and
> > > > > > > > > > > > > the lunch is sponsored by Ideas on Board! Many thanks to our sponsors, it's very much
> > > > > > > > > > > > > appreciated.
> > > > > > > > > > > > >
> > > > > > > > > > > > > If you have a topic that you want to discuss, just 'Reply All' to this announcement
> > > > > > > > > > > > > and give the topic title, a short description and a guesstimate of the time you need
> > > > > > > > > > > > > for your topic.
> > > > > > > > > > > > >
> > > > > > > > > > > > > See last year's Media Summit Report as an example of what to expect:
> > > > > > > > > > > > >
> > > > > > > > > > > > > https://lore.kernel.org/linux-media/21769183-ca57-4f8f-818a-6a1ad089298d@jjverkuil.nl/
> > > > > > > > > > > > >
> > > > > > > > > > > > > Regards,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hans
> > > > > > > > > > > > >
> > > > > > > > > > > > > PS: Be aware that May 24 and 25 are public holidays in France. So many
> > > > > > > > > > > > > shops may be
> > > > > > > > > > > > > closed those days.
> > > > > > > > > > > > >
> > > > > > > > > > > > > In-person attendees:
> > > > > > > > > > > > > Sakari Ailus <sakari.ailus@linux.intel.com>
> > > > > > > > > > > > > Kieran Bingham <kieran.bingham@ideasonboard.com>
> > > > > > > > > > > > > Brandon Brnich <b-brnich@ti.com>
> > > > > > > > > > > > > Rouven Czerwinski <rouven.czerwinski@linaro.org>
> > > > > > > > > > > > > Mehdi Djait <mehdi.djait@linux.intel.com>
> > > > > > > > > > > > > Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> > > > > > > > > > > > > Nicolas Dufresne <nicolas.dufresne@collabora.com>
> > > > > > > > > > > > > Marco Felsch <m.felsch@pengutronix.de>
> > > > > > > > > > > > > Paul Kocialkowski <paulk@sys-base.io>
> > > > > > > > > > > > > Jai Luthra <jai.luthra@ideasonboard.com>
> > > > > > > > > > > > > Jacopo Mondi <jacopo.mondi@ideasonboard.com>
> > > > > > > > > > > > > Benjamin Mugnier <benjamin.mugnier@foss.st.com>
> > > > > > > > > > > > > Beleswar Padhi <b-padhi@ti.com>
> > > > > > > > > > > > > Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > > > > > > > > > > > Loic Poulain <loic.poulain@oss.qualcomm.com>
> > > > > > > > > > > > > Sven Püschel <s.pueschel@pengutronix.de>
> > > > > > > > > > > > > Ricardo Ribalda <ribalda@chromium.org>
> > > > > > > > > > > > > Michael Riesch <michael.riesch@collabora.com>
> > > > > > > > > > > > > Devarsh Thakkar <devarsht@ti.com>
> > > > > > > > > > > > > Michael Tretter <m.tretter@pengutronix.de>
> > > > > > > > > > > > > Hans Verkuil <hverkuil@kernel.org>
> > > > > > > > > > > > >
> > > > > > > > > > > > > Remote attendees:
> > > > > > > > > > > > > Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
> > > > > > > > > > > > > Rishikesh Donadkar <r-donadkar@ti.com>
> > > > > > > > > > > > > Jackson Lee <jackson.lee@chipsnmedia.com>
> > > > > > > > > > > > > Dave Stevenson <dave.stevenson@raspberrypi.com> (tentative)
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Agenda (tentative):
> > > > > > > > > > > > >
> > > > > > > > > > > > > 8:45-9:20: Arrive, settle in
> > > > > > > > > > > > >
> > > > > > > > > > > > > 9:20-9:30: Short intro (Hans Verkuil)
> > > > > > > > > > > > >
> > > > > > > > > > > > > 9:30-9:45: Status of ISP support in V4L2
> > > > > > > > > > > > > Presenter: Laurent Pinchart
> > > > > > > > > > > > > Description: Summary of ISP-related development in V4L2 since the last
> > > > > > > > > > > > > Linux Media Summit. This includes a brief overview of technical
> > > > > > > > > > > > > developments, and a summary of the efforts to engage with vendors.
> > > > > > > > > > > > >
> > > > > > > > > > > > > 9:45-10:45: V4L2 Stateless Video Encoding uAPI Progress Update
> > > > > > > > > > > > > Presenter: Paul Kocialkowski
> > > > > > > > > > > > > Description: An update on the ongonig work to support stateless codecs in V4L2.
> > > > > > > > > > > > > Some of the remaining open topics will be presented and discussed.
> > > > > > > > > > > > >
> > > > > > > > > > > > > 10:45-11:00: break
> > > > > > > > > > > > >
> > > > > > > > > > > > > 11:00-11:30: Vulkan Video Codecs
> > > > > > > > > > > > > Presenter: Nicolas Dufresne
> > > > > > > > > > > > > Description: Vulkan video codecs: what are the viable options for Linux Media
> > > > > > > > > > > > > and what is in preparation outside of our subsystem. The second aspect is
> > > > > > > > > > > > > informative as these discussions don't seem to lean toward our subsystem as the
> > > > > > > > > > > > > foundation. But I think it's rather useful for everyone to understand why and
> > > > > > > > > > > > > what is included.
> > > > > > > > > > > > >
> > > > > > > > > > > > > 11:30-12:00: Protected Video playback on i.MX8MQ
> > > > > > > > > > > > > Presenter: Rouven Czerwinski
> > > > > > > > > > > > > Description: Introduction to protected video playback
> > > > > > > > > > > > > on i.MX8MQ and missing bits for linux-media & protected heap interoperability.
> > > > > > > > > > > > >
> > > > > > > > > > > > > 12:00-13:30: Lunch
> > > > > > > > > > > > >
> > > > > > > > > > > > > 13:30-14:00: HDCP support for HDMI receivers
> > > > > > > > > > > > > Presenter: Hans Verkuil
> > > > > > > > > > > > > Description: I have been working on adding HDCP support for HDMI receivers.
> > > > > > > > > > > > > Specifically the HDCP negotiation between sources and sinks.
> > > > > > > > > > > > >
> > > > > > > > > > > > > 14:00-14:30: AI patches
> > > > > > > > > > > > > Presenter: Sakari Ailus
> > > > > > > > > > > > > Description: What is our policy w.r.t. AI generated patches?
> > > > > > > > > > > > >
> > > > > > > > > > > > > 14:30-15:00 Overview of Media CI: where do pipelines run?
> > > > > > > > > > > > > Presenter: Ricardo Ribalda
> > > > > > > > > > > > > Description: How are jobs in pipelines assigned? How does the infrastructure
> > > > > > > > > > > > > for Media CI work? Are there things that can be tweaked to make it more
> > > > > > > > > > > > > reliable?
> > > > > > > > > > > > >
> > > > > > > > > > > > > 15:00-15:15: Break
> > > > > > > > > > > > >
> > > > > > > > > > > > > 15:15-16:15: Discussion of the media subsystem development process
> > > > > > > > > > > > > Presenter: Hans Verkuil
> > > > > > > > > > > > > Description: Review of the multi-committer model: current status and next steps.
> > > > > > > > > > > > > Are there any bottlenecks, any ideas for improvements, w.r.t. the development process?
> > > > > > > > > > > > >
> > > > > > > > > > > > > As you can see, there is still some available time for other topics.
> > >
> > > --
> > > Regards,
> > >
> > > Laurent Pinchart
> >
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH] media: i2c: isl7998x: inline i2c_check_functionality check
From: Thorsten Blum @ 2026-04-28 16:57 UTC (permalink / raw)
To: Michael Tretter, Pengutronix Kernel Team, Mauro Carvalho Chehab
Cc: Thorsten Blum, linux-media, linux-kernel
Inline the i2c_check_functionality() check, since the function returns a
boolean status rather than an error code.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
drivers/media/i2c/isl7998x.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/i2c/isl7998x.c b/drivers/media/i2c/isl7998x.c
index 5ffd53e005ee..96702c5eaa35 100644
--- a/drivers/media/i2c/isl7998x.c
+++ b/drivers/media/i2c/isl7998x.c
@@ -1460,8 +1460,7 @@ static int isl7998x_probe(struct i2c_client *client)
int nr_inputs;
int ret;
- ret = i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WORD_DATA);
- if (!ret) {
+ if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WORD_DATA)) {
dev_warn(&adapter->dev,
"I2C-Adapter doesn't support I2C_FUNC_SMBUS_WORD\n");
return -EIO;
^ permalink raw reply related
* Re: [PATCH v4 12/15] net: ipa: Switch to generic PAS TZ APIs
From: Alex Elder @ 2026-04-28 16:54 UTC (permalink / raw)
To: Sumit Garg, andersson, konradybcio
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, robh, krzk+dt,
conor+dt, robin.clark, sean, akhilpo, lumag, abhinav.kumar,
jesszhan0024, marijn.suijten, airlied, simona, vikash.garodia,
dikshita.agarwal, bod, mchehab, elder, andrew+netdev, davem,
edumazet, kuba, pabeni, jjohnson, mathieu.poirier,
trilokkumar.soni, mukesh.ojha, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <20260427095603.1157963-13-sumit.garg@kernel.org>
On 4/27/26 4:56 AM, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Switch ipa client driver over to generic PAS TZ APIs. Generic PAS TZ
> service allows to support multiple TZ implementation backends like QTEE
> based SCM PAS service, OP-TEE based PAS service and any further future TZ
> backend service.
>
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Looks good to me.
Reviewed-by: Alex Elder <elder@riscstar.com>
> ---
> drivers/net/ipa/Kconfig | 2 +-
> drivers/net/ipa/ipa_main.c | 13 ++++++++-----
> 2 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ipa/Kconfig b/drivers/net/ipa/Kconfig
> index 01d219d3760c..a9aff1b7977d 100644
> --- a/drivers/net/ipa/Kconfig
> +++ b/drivers/net/ipa/Kconfig
> @@ -6,7 +6,7 @@ config QCOM_IPA
> depends on QCOM_RPROC_COMMON || (QCOM_RPROC_COMMON=n && COMPILE_TEST)
> depends on QCOM_AOSS_QMP || QCOM_AOSS_QMP=n
> select QCOM_MDT_LOADER
> - select QCOM_SCM
> + select QCOM_PAS
> select QCOM_QMI_HELPERS
> help
> Choose Y or M here to include support for the Qualcomm
> diff --git a/drivers/net/ipa/ipa_main.c b/drivers/net/ipa/ipa_main.c
> index 788dd99af2a4..3cd9e44680e9 100644
> --- a/drivers/net/ipa/ipa_main.c
> +++ b/drivers/net/ipa/ipa_main.c
> @@ -14,7 +14,7 @@
> #include <linux/pm_runtime.h>
> #include <linux/types.h>
>
> -#include <linux/firmware/qcom/qcom_scm.h>
> +#include <linux/firmware/qcom/qcom_pas.h>
> #include <linux/soc/qcom/mdt_loader.h>
>
> #include "ipa.h"
> @@ -624,10 +624,13 @@ static int ipa_firmware_load(struct device *dev)
> }
>
> ret = qcom_mdt_load(dev, fw, path, IPA_PAS_ID, virt, phys, size, NULL);
> - if (ret)
> + if (ret) {
> dev_err(dev, "error %d loading \"%s\"\n", ret, path);
> - else if ((ret = qcom_scm_pas_auth_and_reset(IPA_PAS_ID)))
> - dev_err(dev, "error %d authenticating \"%s\"\n", ret, path);
> + } else {
> + ret = qcom_pas_auth_and_reset(IPA_PAS_ID);
> + if (ret)
> + dev_err(dev, "error %d authenticating \"%s\"\n", ret, path);
> + }
>
> memunmap(virt);
> out_release_firmware:
> @@ -758,7 +761,7 @@ static enum ipa_firmware_loader ipa_firmware_loader(struct device *dev)
> return IPA_LOADER_INVALID;
> out_self:
> /* We need Trust Zone to load firmware; make sure it's available */
> - if (qcom_scm_is_available())
> + if (qcom_pas_is_available())
> return IPA_LOADER_SELF;
>
> return IPA_LOADER_DEFER;
^ permalink raw reply
* Re: [PATCH] staging: tegra-video: Fix function argument alignment
From: Dan Carpenter @ 2026-04-28 16:50 UTC (permalink / raw)
To: Mhanna112-code
Cc: linux-staging, linux-media, linux-tegra, linux-kernel,
thierry.reding, jonathanh, skomatineni, luca.ceresoli, mchehab,
gregkh
In-Reply-To: <20260428154022.6997-1-marchanna111@gmail.com>
On Tue, Apr 28, 2026 at 10:40:22AM -0500, Mhanna112-code wrote:
^^^^^^^^^^^^^^
Your from header needs to be fixed.
> Separate long function calls into multiple lines to comply with kernel formatting style.
>
> This fixes the following checkpatch warnings:
>
> CHECK: Alignment should match open parenthesis
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This isn't what the patch does.
>
> Signed-off-by: Marc Hanna <marchanna111@gmail.com>
regards,
dan carpenter
^ permalink raw reply
* [PATCH] staging: tegra-video: replace bit shifts with BIT() macro
From: Mhanna112-code @ 2026-04-28 16:33 UTC (permalink / raw)
To: linux-staging
Cc: thierry.reding, jonathanh, skomatineni, luca.ceresoli, mchehab,
gregkh, linux-media, linux-tegra, linux-kernel, Mhanna112-code
Replace manual bit shifts with the BIT() macro to follow kernel
coding style and improve readability.
Fixes the following checkpatch warning:
CHECK: Prefer using the BIT macro
Signed-off-by: Marc Hanna <marchanna111@gmail.com>
---
drivers/staging/media/tegra-video/tegra20.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/tegra-video/tegra20.c b/drivers/staging/media/tegra-video/tegra20.c
index eb1fc5b7e2cd..f3edca909684 100644
--- a/drivers/staging/media/tegra-video/tegra20.c
+++ b/drivers/staging/media/tegra-video/tegra20.c
@@ -177,15 +177,15 @@ enum tegra_vi_out {
#define CSI_SKIP_PACKET_THRESHOLD(n) (((n) & 0xff) << 16)
#define TEGRA_CSI_PIXEL_STREAM_CONTROL0(n) (0x0018 + (n) * 0x2c)
#define CSI_PP_PAD_FRAME_PAD0S (0 << 28)
-#define CSI_PP_PAD_FRAME_PAD1S (1 << 28)
+#define CSI_PP_PAD_FRAME_PAD1S BIT(28)
#define CSI_PP_PAD_FRAME_NOPAD (2 << 28)
#define CSI_PP_HEADER_EC_ENABLE BIT(27)
#define CSI_PP_PAD_SHORT_LINE_PAD0S (0 << 24)
-#define CSI_PP_PAD_SHORT_LINE_PAD1S (1 << 24)
+#define CSI_PP_PAD_SHORT_LINE_PAD1S BIT(24)
#define CSI_PP_PAD_SHORT_LINE_NOPAD (2 << 24)
#define CSI_PP_EMBEDDED_DATA_EMBEDDED BIT(20)
#define CSI_PP_OUTPUT_FORMAT_ARBITRARY (0 << 16)
-#define CSI_PP_OUTPUT_FORMAT_PIXEL (1 << 16)
+#define CSI_PP_OUTPUT_FORMAT_PIXEL BIT(16)
#define CSI_PP_OUTPUT_FORMAT_PIXEL_REP (2 << 16)
#define CSI_PP_OUTPUT_FORMAT_STORE (3 << 16)
#define CSI_PP_VIRTUAL_CHANNEL_ID(n) (((n) - 1) << 14)
--
2.43.0
^ permalink raw reply related
* [PATCH] dept: update documentation function names to match implementation
From: Yunseong Kim @ 2026-04-28 16:26 UTC (permalink / raw)
To: bagasdotme
Cc: 2407018371, Dai.Ngo, Liam.Howlett, a.hindborg, ada.coupriediaz,
adilger.kernel, akpm, alex.gaynor, alexander.shishkin, aliceryhl,
amir73il, andi.shyti, andrii, anna, arnd, ast, baolin.wang,
bigeasy, bjorn3_gh, boqun.feng, bp, brauner, broonie, bsegall,
byungchul, catalin.marinas, chenhuacai, chris.p.wilson,
christian.koenig, chuck.lever, cl, clrkwllms, corbet, da.gomez,
dakr, damien.lemoal, dan.j.williams, daniel.vetter, dave.hansen,
david, dennis, dietmar.eggemann, djwong, dri-devel, duyuyang,
dwmw, francesco, frederic, gary, geert+renesas, geert, gregkh,
guoweikang.kernel, gustavo, gwan-gyeong.mun, hamohammed.sa,
hannes, harry.yoo, hch, her0gyugyu, hpa, jack, jglisse,
jiangshanlai, jlayton, joel.granados, joel, joelagnelf,
johannes.berg, josef, josh, jpoimboe, juri.lelli, kees,
kernel-team, kernel_team, kevin.brodsky, kristina.martsenko,
lillian, linaro-mm-sig, link, linux-arch, linux-arm-kernel,
linux-block, linux-doc, linux-ext4, linux-fsdevel, linux-i2c,
linux-ide, linux-kernel, linux-media, linux-mm, linux-modules,
linux-nfs, linux-rt-devel, linux, longman, lorenzo.stoakes,
lossin, luto, mark.rutland, masahiroy, mathieu.desnoyers,
matthew.brost, max.byungchul.park, mcgrof, melissa.srw, mgorman,
mhocko, miguel.ojeda.sandonis, minchan, mingo, mjguzik,
neeraj.upadhyay, neil, neilb, netdev, ngupta, ojeda, okorniev,
oleg, paulmck, penberg, peterz, petr.pavlu, qiang.zhang, rcu,
richard.weiyang, rientjes, rodrigosiqueiramelo, rostedt, rppt,
rust-for-linux, samitolvanen, sashal, shakeel.butt, sj,
sumit.semwal, surenb, tglx, thomas.weissschuh, tim.c.chen, tj,
tmgross, tom, torvalds, trondmy, tytso, urezki, usamaarif642,
vbabka, vdavydov.dev, vincent.guittot, vschneid, wangfushuai,
wangkefeng.wang, will, willy, wsa+renesas, x86, yeoreum.yun, ysk,
yunseong.kim, yuzhao, ziy, Yunseong Kim
In-Reply-To: <aTN38kJjBftxnjm9@archie.me>
Synchronize function names in the documentation with the actual
implementation to fix naming inconsistencies.
Signed-off-by: Yunseong Kim <yunseong.kim@est.tech>
---
Documentation/dev-tools/dept.rst | 2 +-
Documentation/dev-tools/dept_api.rst | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/dev-tools/dept.rst b/Documentation/dev-tools/dept.rst
index 333166464543..31b2fe629fab 100644
--- a/Documentation/dev-tools/dept.rst
+++ b/Documentation/dev-tools/dept.rst
@@ -97,7 +97,7 @@ No. What about the following?
mutex_lock A
mutex_lock A <- DEADLOCK
- wait_for_complete B <- DEADLOCK
+ wait_for_completion B <- DEADLOCK
complete B
mutex_unlock A
mutex_unlock A
diff --git a/Documentation/dev-tools/dept_api.rst b/Documentation/dev-tools/dept_api.rst
index 409116a62849..74e7b1424ad5 100644
--- a/Documentation/dev-tools/dept_api.rst
+++ b/Documentation/dev-tools/dept_api.rst
@@ -113,7 +113,7 @@ Do not use these APIs directly. The raw APIs of dept are:
dept_stage_wait(map, key, ip, wait_func, time);
dept_request_event_wait_commit();
dept_clean_stage();
- dept_stage_event(task, ip);
+ dept_ttwu_stage_wait(task, ip);
dept_ecxt_enter(map, evt_flags, ip, ecxt_func, evt_func, sub_local);
dept_ecxt_holding(map, evt_flags);
dept_request_event(map, ext_wgen);
--
2.53.0
^ permalink raw reply related
* [PATCH] staging: tegra-video: Fix function argument alignment
From: Mhanna112-code @ 2026-04-28 15:40 UTC (permalink / raw)
To: linux-staging
Cc: linux-media, linux-tegra, linux-kernel, thierry.reding, jonathanh,
skomatineni, luca.ceresoli, mchehab, gregkh, Mhanna112-code
Separate long function calls into multiple lines to comply with kernel formatting style.
This fixes the following checkpatch warnings:
CHECK: Alignment should match open parenthesis
Signed-off-by: Marc Hanna <marchanna111@gmail.com>
---
drivers/staging/media/tegra-video/tegra20.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/tegra-video/tegra20.c b/drivers/staging/media/tegra-video/tegra20.c
index e513e6ccb776..eb1fc5b7e2cd 100644
--- a/drivers/staging/media/tegra-video/tegra20.c
+++ b/drivers/staging/media/tegra-video/tegra20.c
@@ -552,7 +552,8 @@ static void tegra20_channel_vi_buffer_setup(struct tegra_vi_channel *chan,
case V4L2_PIX_FMT_YUYV:
case V4L2_PIX_FMT_YVYU:
tegra20_vi_write(chan, TEGRA_VI_VB0_BASE_ADDRESS(TEGRA_VI_OUT_1), base);
- tegra20_vi_write(chan, TEGRA_VI_VB0_START_ADDRESS(TEGRA_VI_OUT_1), base + chan->start_offset);
+ tegra20_vi_write(chan, TEGRA_VI_VB0_START_ADDRESS(TEGRA_VI_OUT_1),
+ base + chan->start_offset);
break;
/* RAW8 */
case V4L2_PIX_FMT_SRGGB8:
@@ -565,7 +566,8 @@ static void tegra20_channel_vi_buffer_setup(struct tegra_vi_channel *chan,
case V4L2_PIX_FMT_SGBRG10:
case V4L2_PIX_FMT_SBGGR10:
tegra20_vi_write(chan, TEGRA_VI_VB0_BASE_ADDRESS(TEGRA_VI_OUT_2), base);
- tegra20_vi_write(chan, TEGRA_VI_VB0_START_ADDRESS(TEGRA_VI_OUT_2), base + chan->start_offset);
+ tegra20_vi_write(chan, TEGRA_VI_VB0_START_ADDRESS(TEGRA_VI_OUT_2),
+ base + chan->start_offset);
break;
}
}
--
2.43.0
^ permalink raw reply related
* [PATCH RESEND] media: pci: dm1105: Free allocated workqueue
From: Krzysztof Kozlowski @ 2026-04-28 14:50 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Igor M. Liplianin, linux-media,
linux-kernel
Cc: Krzysztof Kozlowski, stable
Destroy allocated workqueue in remove() callback to free its resources,
thus fixing memory leak.
Fixes: 519a4bdcf822 ("V4L/DVB (11984): Add support for yet another SDMC DM1105 based DVB-S card.")
Cc: <stable@vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
drivers/media/pci/dm1105/dm1105.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/pci/dm1105/dm1105.c b/drivers/media/pci/dm1105/dm1105.c
index bbd24769ae56..e915d9a3f785 100644
--- a/drivers/media/pci/dm1105/dm1105.c
+++ b/drivers/media/pci/dm1105/dm1105.c
@@ -1194,6 +1194,7 @@ static void dm1105_remove(struct pci_dev *pdev)
dm1105_hw_exit(dev);
free_irq(pdev->irq, dev);
+ destroy_workqueue(dev->wq);
pci_iounmap(pdev, dev->io_mem);
pci_release_regions(pdev);
pci_disable_device(pdev);
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] media: verisilicon: Fix format enumeration when post-processor is mandatory
From: Nicolas Dufresne @ 2026-04-28 14:30 UTC (permalink / raw)
To: Benjamin Gaignard, p.zabel, mchehab, hverkuil
Cc: linux-media, linux-rockchip, linux-kernel, kernel
In-Reply-To: <20260428083723.54314-1-benjamin.gaignard@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]
Le mardi 28 avril 2026 à 10:37 +0200, Benjamin Gaignard a écrit :
> When a post-processor pixel format is mandatory (i.e. when an AV1
> bitstream use film grain feature) the driver must only enumerate
> post-processed format.
> Use the context format to know what is suppose to be enumerated.
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
> Fixes: 80c7373a456e ("media: verisilicon: Conditionally ignore native formats")
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> ---
> drivers/media/platform/verisilicon/hantro_v4l2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/verisilicon/hantro_v4l2.c b/drivers/media/platform/verisilicon/hantro_v4l2.c
> index fcf3bd9bcda2..f538d4562744 100644
> --- a/drivers/media/platform/verisilicon/hantro_v4l2.c
> +++ b/drivers/media/platform/verisilicon/hantro_v4l2.c
> @@ -242,7 +242,7 @@ static int vidioc_enum_fmt(struct file *file, void *priv,
> */
> skip_mode_none = capture == ctx->is_encoder;
>
> - formats = hantro_get_formats(ctx, &num_fmts, HANTRO_AUTO_POSTPROC);
> + formats = hantro_get_formats(ctx, &num_fmts, ctx->need_postproc);
> for (i = 0; i < num_fmts; i++) {
> bool mode_none = formats[i].codec_mode == HANTRO_MODE_NONE;
> fmt = &formats[i];
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 0/6] media: Fix new smatch warnings
From: Ricardo Ribalda @ 2026-04-28 13:58 UTC (permalink / raw)
To: Dan Carpenter
Cc: Mauro Carvalho Chehab, Laurent Pinchart, Sakari Ailus,
Hans Verkuil, Nas Chung, Jackson Lee, Bingbu Cao, Tianshu Qiu,
Greg Kroah-Hartman, Keke Li, linux-media, linux-kernel,
linux-staging
In-Reply-To: <afC7qXCCkTTOS7jr@stanley.mountain>
Hi Dan
On Tue, 28 Apr 2026 at 15:52, Dan Carpenter <error27@gmail.com> wrote:
>
> On Tue, Apr 28, 2026 at 12:41:06PM +0000, Ricardo Ribalda wrote:
> > Current version of smatch triggers some warnings for the media tree.
> > Most of them are inoffensive, but we would like to have zero smatch
> > warnings.
> >
> > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max
> > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max
> > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max
> > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max
> > drivers/media/v4l2-core/v4l2-dev.c:1036 __video_register_device() error: buffer overflow 'video_devices' 256 <= 288
> > drivers/media/v4l2-core/v4l2-dev.c:1043 __video_register_device() error: buffer overflow 'video_devices' 256 <= 288
> > drivers/media/v4l2-core/v4l2-dev.c:1101 __video_register_device() error: buffer overflow 'video_devices' 256 <= 288
> > drivers/media/platform/chips-media/wave5/wave5-vpuapi.c:588 wave5_vpu_dec_get_output_info() error: buffer overflow 'inst->frame_buf' 64 <= 127
> > drivers/staging/media/ipu3/ipu3-css-params.c:1792 imgu_css_cfg_acc_stripe() warn: 'acc->stripe.bds_out_stripes[0]->width - 2 * f' 4294967168 can't fit into 65535 'acc->stripe.bds_out_stripes[1]->offset'
> > drivers/media/i2c/adv7604.c:3672 adv76xx_probe() error: buffer overflow 'state->pads' 7 <= 4294967294
> > drivers/media/i2c/adv7604.c:3673 adv76xx_probe() error: buffer overflow 'state->pads' 7 <= u32max
> > drivers/media/i2c/mt9p031.c:799 mt9p031_s_ctrl() warn: assigning (-1952) to unsigned variable 'data'
> >
> > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
>
> I'm re-writing a bunch of core stuff right now... Feel free to
> complain about false positives. I'm going to re-write the buffer
> overflow warning in the next couple weeks.
The only one that deserves a complain is this one:
https://lore.kernel.org/linux-media/CANiDSCtm4Nh4Ub4rbEBvpjV8GXT9VQ5eFXZTHn=Wy=0RpR=3JA@mail.gmail.com/T/#m650723c33ec0318d8f32f1a6cc74c74a952ae11a
There are other false positives like this one:
https://lore.kernel.org/linux-media/CANiDSCtm4Nh4Ub4rbEBvpjV8GXT9VQ5eFXZTHn=Wy=0RpR=3JA@mail.gmail.com/T/#md58851baa54c511f57b05a4dcf3aecf0ffb1b1fa
But I think the extra check makes the code more robust.
Thanks for your tool :)
>
> regards,
> dan carpenter
--
Ricardo Ribalda
^ permalink raw reply
* Re: [PATCH 0/6] media: Fix new smatch warnings
From: Dan Carpenter @ 2026-04-28 13:52 UTC (permalink / raw)
To: Ricardo Ribalda
Cc: Mauro Carvalho Chehab, Laurent Pinchart, Sakari Ailus,
Hans Verkuil, Nas Chung, Jackson Lee, Bingbu Cao, Tianshu Qiu,
Greg Kroah-Hartman, Keke Li, linux-media, linux-kernel,
linux-staging
In-Reply-To: <20260428-smatch-7-1-v1-0-46890dffb611@chromium.org>
On Tue, Apr 28, 2026 at 12:41:06PM +0000, Ricardo Ribalda wrote:
> Current version of smatch triggers some warnings for the media tree.
> Most of them are inoffensive, but we would like to have zero smatch
> warnings.
>
> drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max
> drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max
> drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max
> drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max
> drivers/media/v4l2-core/v4l2-dev.c:1036 __video_register_device() error: buffer overflow 'video_devices' 256 <= 288
> drivers/media/v4l2-core/v4l2-dev.c:1043 __video_register_device() error: buffer overflow 'video_devices' 256 <= 288
> drivers/media/v4l2-core/v4l2-dev.c:1101 __video_register_device() error: buffer overflow 'video_devices' 256 <= 288
> drivers/media/platform/chips-media/wave5/wave5-vpuapi.c:588 wave5_vpu_dec_get_output_info() error: buffer overflow 'inst->frame_buf' 64 <= 127
> drivers/staging/media/ipu3/ipu3-css-params.c:1792 imgu_css_cfg_acc_stripe() warn: 'acc->stripe.bds_out_stripes[0]->width - 2 * f' 4294967168 can't fit into 65535 'acc->stripe.bds_out_stripes[1]->offset'
> drivers/media/i2c/adv7604.c:3672 adv76xx_probe() error: buffer overflow 'state->pads' 7 <= 4294967294
> drivers/media/i2c/adv7604.c:3673 adv76xx_probe() error: buffer overflow 'state->pads' 7 <= u32max
> drivers/media/i2c/mt9p031.c:799 mt9p031_s_ctrl() warn: assigning (-1952) to unsigned variable 'data'
>
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
I'm re-writing a bunch of core stuff right now... Feel free to
complain about false positives. I'm going to re-write the buffer
overflow warning in the next couple weeks.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 6/6] media: amlogic-c3: Add validations for ae and awb config
From: Ricardo Ribalda @ 2026-04-28 13:49 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mauro Carvalho Chehab, Sakari Ailus, Hans Verkuil, Nas Chung,
Jackson Lee, Bingbu Cao, Tianshu Qiu, Greg Kroah-Hartman, Keke Li,
linux-media, linux-kernel, linux-staging, Jacopo Mondi
In-Reply-To: <20260428132649.GD120836@killaraus.ideasonboard.com>
On Tue, 28 Apr 2026 at 15:26, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> On Tue, Apr 28, 2026 at 03:14:21PM +0200, Ricardo Ribalda wrote:
> > On Tue, 28 Apr 2026 at 15:10, Laurent Pinchart wrote:
> > > On Tue, Apr 28, 2026 at 12:41:12PM +0000, Ricardo Ribalda wrote:
> > > > Avoid invalid memory access if the zones_num is bigger than
> > > > zone_weight.
> > > >
> > > > This patch fixes the following smatch errors:
> > > > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max
> > > > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max
> > > > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max
> > > > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max
> > > >
> > > > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> > > > ---
> > > > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c | 4 ++++
> > > > 1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/drivers/media/platform/amlogic/c3/isp/c3-isp-params.c b/drivers/media/platform/amlogic/c3/isp/c3-isp-params.c
> > > > index 6f9ca7a7dd88..42d780f684d1 100644
> > > > --- a/drivers/media/platform/amlogic/c3/isp/c3-isp-params.c
> > > > +++ b/drivers/media/platform/amlogic/c3/isp/c3-isp-params.c
> > > > @@ -104,6 +104,8 @@ static void c3_isp_params_awb_wt(struct c3_isp_device *isp,
> > > > c3_isp_write(isp, ISP_AWB_BLK_WT_ADDR, 0);
> > > >
> > > > zones_num = cfg->horiz_zones_num * cfg->vert_zones_num;
> > > > + if (WARN_ON(zones_num > C3_ISP_AWB_MAX_ZONES))
> > >
> > > This is triggerable by userspace, it shouldn't result in a WARN_ON().
> > > Ideally the horiz_zones_num and vert_zones_num should be validated at
> > > buf prepare time, and an error should be returned to userspace. That
> > > will likely not fix your smatch issue though, I don't think it will be
> > > able to understand that the values have been validated.
> >
> > Based on the warnings from the other drivers I also suspect that if
> > you have validated the data somewhere else smatch will understand it.
> >
> > Even if you add a validate function I would suggest to keep the
> > WARN_ON(), ideally it should never trigger, and if it triggers it will
> > get a lot more attention to get it fixed.
>
> We could keep the WARN_ON() if we first validate the data, but the
> driver doesn't currently :-/ I expect there could be more similar
> issues.
Yep, I got that. I will let you or Jacopo figure out the best way to
implement the validation in buf_prepare. If you do not have time to
implement it now I will just remove the WARN_ON in the interim... but
from my experience we only fix stuff if we get an oops.
Regards!
>
> > > Jacopo, do we need to add a validate function pointer to
> > > v4l2_isp_params_block_type_info ?
> > >
> > > > + zones_num = C3_ISP_AWB_MAX_ZONES;
> > > >
> > > > /* Need to write 8 weights at once */
> > > > for (i = 0; i < zones_num / 8; i++) {
> > > > @@ -220,6 +222,8 @@ static void c3_isp_params_ae_wt(struct c3_isp_device *isp,
> > > > c3_isp_write(isp, ISP_AE_BLK_WT_ADDR, 0);
> > > >
> > > > zones_num = cfg->horiz_zones_num * cfg->vert_zones_num;
> > > > + if (WARN_ON(zones_num > C3_ISP_AE_MAX_ZONES))
> > > > + zones_num = C3_ISP_AE_MAX_ZONES;
> > > >
> > > > /* Need to write 8 weights at once */
> > > > for (i = 0; i < zones_num / 8; i++) {
>
> --
> Regards,
>
> Laurent Pinchart
--
Ricardo Ribalda
^ permalink raw reply
* Re: [PATCH 2/6] media: i2c: mt9p031: Rewrite a bitwise mask
From: Ricardo Ribalda @ 2026-04-28 13:37 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mauro Carvalho Chehab, Sakari Ailus, Hans Verkuil, Nas Chung,
Jackson Lee, Bingbu Cao, Tianshu Qiu, Greg Kroah-Hartman, Keke Li,
linux-media, linux-kernel, linux-staging
In-Reply-To: <20260428132524.GC120836@killaraus.ideasonboard.com>
Hi Laurent
On Tue, 28 Apr 2026 at 15:25, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> On Tue, Apr 28, 2026 at 12:41:08PM +0000, Ricardo Ribalda wrote:
> > The current code makes smatch a bit uncomfortable:
> > drivers/media/i2c/mt9p031.c:799 mt9p031_s_ctrl() warn: assigning (-1952) to unsigned variable 'data'
> >
> > Probably because smatch is not clever enough (yet). Do a simple rewrite
> > to make sure that smatch understands what we are doing here.
> >
> > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> > ---
> > drivers/media/i2c/mt9p031.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
> > index ea5d43d925ff..5c9dff030b4d 100644
> > --- a/drivers/media/i2c/mt9p031.c
> > +++ b/drivers/media/i2c/mt9p031.c
> > @@ -795,7 +795,7 @@ static int mt9p031_s_ctrl(struct v4l2_ctrl *ctrl)
> > ctrl->val &= ~1;
> > data = (1 << 6) | (ctrl->val >> 1);
> > } else {
> > - ctrl->val &= ~7;
> > + ctrl->val -= ctrl->val % 8;
>
> This is less readable than it was :-/ Is there a way to avoid the
> warning while keeping the ~7 ? Maybe by assigning
I guess it is a matter of taste. I find my version more readable.
Also yours do not seem to convince smatch :P
drivers/media/i2c/mt9p031.c:800 mt9p031_s_ctrl() warn: '(data << 8) |
(1 << 6) | 32' 16775264 can't fit into 65535 'data'
ribalda@ribalda:~/work/linux$ git diff
diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
index 5c9dff030b4d..f9f51d5060f6 100644
--- a/drivers/media/i2c/mt9p031.c
+++ b/drivers/media/i2c/mt9p031.c
@@ -795,8 +795,9 @@ static int mt9p031_s_ctrl(struct v4l2_ctrl *ctrl)
ctrl->val &= ~1;
data = (1 << 6) | (ctrl->val >> 1);
} else {
- ctrl->val -= ctrl->val % 8;
- data = ((ctrl->val - 64) << 5) | (1 << 6) | 32;
+ ctrl->val &= ~7;
+ data = (ctrl->val - 64) >> 3;
+ data = (data << 8) | (1 << 6) | 32;
>
> data = (ctrl->val - 64) >> 3;
> data = (data << 8) | (1 << 6) | 32;
>
> > data = ((ctrl->val - 64) << 5) | (1 << 6) | 32;
> > }
> >
>
> --
> Regards,
>
> Laurent Pinchart
--
Ricardo Ribalda
^ permalink raw reply related
* Re: [PATCH RFC v3 04/11] arm64: dts: qcom: msm8939: Add venus node
From: Bryan O'Donoghue @ 2026-04-28 13:36 UTC (permalink / raw)
To: Erikas Bitovtas, Vikash Garodia, Dikshita Agarwal,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, André Apitzsch, Bjorn Andersson, Konrad Dybcio,
Michael Turquette, Stephen Boyd
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, linux-clk,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <34627be5-75cc-469b-af23-f1f08ce29820@gmail.com>
On 28/04/2026 10:47, Erikas Bitovtas wrote:
>
>
> On 4/28/26 10:10 AM, Bryan O'Donoghue wrote:
>> On 27/04/2026 18:58, Erikas Bitovtas wrote:
>>> + video-decoder {
>>> + compatible = "venus-decoder";
>>> + clocks = <&gcc GCC_VENUS0_CORE0_VCODEC0_CLK>,
>>> + <&gcc GCC_VENUS0_CORE1_VCODEC0_CLK>;
>>> + clock-names = "core0", "core1";
>>> + power-domains = <&gcc VENUS_CORE0_GDSC>,
>>> + <&gcc VENUS_CORE1_GDSC>;
>>> + power-domain-names = "core0", "core1";
>>> + };
>>> +
>>> + video-encoder {
>>> + compatible = "venus-encoder";
>>> + clocks = <&gcc GCC_VENUS0_CORE0_VCODEC0_CLK>,
>>> + <&gcc GCC_VENUS0_CORE1_VCODEC0_CLK>;
>>> + clock-names = "core0", "core1";
>>> + power-domains = <&gcc VENUS_CORE0_GDSC>,
>>> + <&gcc VENUS_CORE1_GDSC>;
>>> + power-domain-names = "core0", "core1";
>>> + };
>>
>> So to be fair in this case you do have a reason to have an encoder and
>> decoder compatible here _but_ it should be the case that one one of the
>> sub-devices contains CORE0 related stuff and the other CORE1 related stuff.
>>
>> Because in that case the sub-devices actually represent individual
>> hardware settings.
>>
>> So listing power-domains and clocks for both cores in each node like
>> this militates against that.
>>
>> The other thing is to double check of the encoder and decoder are inter-
>> changable here i.e. can either core be encoder or decoder or is it fixed ?
>>
>> I believe on older generations - perhaps not on 8939 it is not
>> interchangable.
>>
> I found this in LA.BR.1.2.9.1_rb1.5:
> https://github.com/msm8916-mainline/linux-downstream/blob/b20608408caff817ec874f325127b07609fbaeb8/arch/arm/boot/dts/qcom/msm8939-common.dtsi#L1589
> Only decoder bits are being set in bus configs. This suggests that the
> cores are not interchangeable.
> Then again, I never managed to get encoding working on MSM8939. Testing
> it with
> gst-launch-1.0 videotestsrc ! videoconvert ! v4l2vp8enc ! queue !
> v4l2vp8dec ! xvimagesink
> Fails with the following log: https://pastebin.com/nmZcLgPV
> And in dmesg it reports a firmware error:
> [ 784.461031] qcom-venus 1d00000.video-codec: no valid instance(pkt
> session_id:dead, pkt:21001)
> [ 784.461126] qcom-venus-decoder 1d00000.video-codec:video-decoder:
> dec: event session error 0
> [ 784.461200] qcom-venus-encoder 1d00000.video-codec:video-encoder:
> enc: event session error 0
> [ 784.468799] qcom-venus 1d00000.video-codec: SFR message from FW:
> QC_IMAGE_VERSION_STRING=VIDEO.VE.1.8-00099, Err_Fatal -
> Z:\b\venus\utils\src\vbuffer.c:1319:
> [ 785.791641] qcom-venus 1d00000.video-codec: System error has
> occurred, recovery failed to init HFI
> [ 787.018339] qcom-venus 1d00000.video-codec: System error has
> occurred, recovery failed to init HFI
> [ 787.097253] qcom-venus 1d00000.video-codec: system error has occurred
> (recovered)
> This happens regardless of whether I enable the cores for encoding too
> or not. The same errors were happening on MSM8916 as well. So I can't
> tell if these cores are interchangeable just by testing.
Right so if you swap around the definition of which core is encoder and
which decoder do you get the same or different result ?
i.e. is it because you are trying to get encoder running generally or
because of the core you are doing it on ?
How about declaring both cores a decoder ?
---
bod
^ permalink raw reply
* Re: [PATCH 6/6] media: amlogic-c3: Add validations for ae and awb config
From: Laurent Pinchart @ 2026-04-28 13:26 UTC (permalink / raw)
To: Ricardo Ribalda
Cc: Mauro Carvalho Chehab, Sakari Ailus, Hans Verkuil, Nas Chung,
Jackson Lee, Bingbu Cao, Tianshu Qiu, Greg Kroah-Hartman, Keke Li,
linux-media, linux-kernel, linux-staging, Jacopo Mondi
In-Reply-To: <CANiDSCvaS-Jz9m5H2OHo2akD-o-sffsZyEw6_CrfUhD1BN+m2g@mail.gmail.com>
On Tue, Apr 28, 2026 at 03:14:21PM +0200, Ricardo Ribalda wrote:
> On Tue, 28 Apr 2026 at 15:10, Laurent Pinchart wrote:
> > On Tue, Apr 28, 2026 at 12:41:12PM +0000, Ricardo Ribalda wrote:
> > > Avoid invalid memory access if the zones_num is bigger than
> > > zone_weight.
> > >
> > > This patch fixes the following smatch errors:
> > > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max
> > > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max
> > > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max
> > > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max
> > >
> > > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> > > ---
> > > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/media/platform/amlogic/c3/isp/c3-isp-params.c b/drivers/media/platform/amlogic/c3/isp/c3-isp-params.c
> > > index 6f9ca7a7dd88..42d780f684d1 100644
> > > --- a/drivers/media/platform/amlogic/c3/isp/c3-isp-params.c
> > > +++ b/drivers/media/platform/amlogic/c3/isp/c3-isp-params.c
> > > @@ -104,6 +104,8 @@ static void c3_isp_params_awb_wt(struct c3_isp_device *isp,
> > > c3_isp_write(isp, ISP_AWB_BLK_WT_ADDR, 0);
> > >
> > > zones_num = cfg->horiz_zones_num * cfg->vert_zones_num;
> > > + if (WARN_ON(zones_num > C3_ISP_AWB_MAX_ZONES))
> >
> > This is triggerable by userspace, it shouldn't result in a WARN_ON().
> > Ideally the horiz_zones_num and vert_zones_num should be validated at
> > buf prepare time, and an error should be returned to userspace. That
> > will likely not fix your smatch issue though, I don't think it will be
> > able to understand that the values have been validated.
>
> Based on the warnings from the other drivers I also suspect that if
> you have validated the data somewhere else smatch will understand it.
>
> Even if you add a validate function I would suggest to keep the
> WARN_ON(), ideally it should never trigger, and if it triggers it will
> get a lot more attention to get it fixed.
We could keep the WARN_ON() if we first validate the data, but the
driver doesn't currently :-/ I expect there could be more similar
issues.
> > Jacopo, do we need to add a validate function pointer to
> > v4l2_isp_params_block_type_info ?
> >
> > > + zones_num = C3_ISP_AWB_MAX_ZONES;
> > >
> > > /* Need to write 8 weights at once */
> > > for (i = 0; i < zones_num / 8; i++) {
> > > @@ -220,6 +222,8 @@ static void c3_isp_params_ae_wt(struct c3_isp_device *isp,
> > > c3_isp_write(isp, ISP_AE_BLK_WT_ADDR, 0);
> > >
> > > zones_num = cfg->horiz_zones_num * cfg->vert_zones_num;
> > > + if (WARN_ON(zones_num > C3_ISP_AE_MAX_ZONES))
> > > + zones_num = C3_ISP_AE_MAX_ZONES;
> > >
> > > /* Need to write 8 weights at once */
> > > for (i = 0; i < zones_num / 8; i++) {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 2/6] media: i2c: mt9p031: Rewrite a bitwise mask
From: Laurent Pinchart @ 2026-04-28 13:25 UTC (permalink / raw)
To: Ricardo Ribalda
Cc: Mauro Carvalho Chehab, Sakari Ailus, Hans Verkuil, Nas Chung,
Jackson Lee, Bingbu Cao, Tianshu Qiu, Greg Kroah-Hartman, Keke Li,
linux-media, linux-kernel, linux-staging
In-Reply-To: <20260428-smatch-7-1-v1-2-46890dffb611@chromium.org>
On Tue, Apr 28, 2026 at 12:41:08PM +0000, Ricardo Ribalda wrote:
> The current code makes smatch a bit uncomfortable:
> drivers/media/i2c/mt9p031.c:799 mt9p031_s_ctrl() warn: assigning (-1952) to unsigned variable 'data'
>
> Probably because smatch is not clever enough (yet). Do a simple rewrite
> to make sure that smatch understands what we are doing here.
>
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> ---
> drivers/media/i2c/mt9p031.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
> index ea5d43d925ff..5c9dff030b4d 100644
> --- a/drivers/media/i2c/mt9p031.c
> +++ b/drivers/media/i2c/mt9p031.c
> @@ -795,7 +795,7 @@ static int mt9p031_s_ctrl(struct v4l2_ctrl *ctrl)
> ctrl->val &= ~1;
> data = (1 << 6) | (ctrl->val >> 1);
> } else {
> - ctrl->val &= ~7;
> + ctrl->val -= ctrl->val % 8;
This is less readable than it was :-/ Is there a way to avoid the
warning while keeping the ~7 ? Maybe by assigning
data = (ctrl->val - 64) >> 3;
data = (data << 8) | (1 << 6) | 32;
> data = ((ctrl->val - 64) << 5) | (1 << 6) | 32;
> }
>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 5/6] media: staging: ipu3-imgu: Add range check for imgu_css_cfg_acc_stripe
From: Ricardo Ribalda @ 2026-04-28 13:17 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mauro Carvalho Chehab, Sakari Ailus, Hans Verkuil, Nas Chung,
Jackson Lee, Bingbu Cao, Tianshu Qiu, Greg Kroah-Hartman, Keke Li,
linux-media, linux-kernel, linux-staging
In-Reply-To: <20260428131347.GB120836@killaraus.ideasonboard.com>
HI Laurent
On Tue, 28 Apr 2026 at 15:13, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> On Tue, Apr 28, 2026 at 12:41:11PM +0000, Ricardo Ribalda wrote:
> > If the driver's stripe information is invalid it can result in an integer
> > overflow. Add a range check with a WARN_ON to expose this kind of
> > error.
> >
> > This patch fixes the following smatch error:
> > drivers/staging/media/ipu3/ipu3-css-params.c:1792 imgu_css_cfg_acc_stripe() warn: 'acc->stripe.bds_out_stripes[0]->width - 2 * f' 4294967168 can't fit into 65535 'acc->stripe.bds_out_stripes[1]->offset'
> >
> > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> > ---
> > drivers/staging/media/ipu3/ipu3-css-params.c | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/staging/media/ipu3/ipu3-css-params.c b/drivers/staging/media/ipu3/ipu3-css-params.c
> > index 2c48d57a3180..6ed23c7a0c3f 100644
> > --- a/drivers/staging/media/ipu3/ipu3-css-params.c
> > +++ b/drivers/staging/media/ipu3/ipu3-css-params.c
> > @@ -1770,6 +1770,8 @@ static int imgu_css_cfg_acc_stripe(struct imgu_css *css, unsigned int pipe,
> > acc->stripe.bds_out_stripes[0].width =
> > ALIGN(css_pipe->rect[IPU3_CSS_RECT_BDS].width, f);
> > } else {
> > + u32 offset;
> > +
> > /* Image processing is divided into two stripes */
> > acc->stripe.bds_out_stripes[0].width =
> > acc->stripe.bds_out_stripes[1].width =
> > @@ -1788,8 +1790,10 @@ static int imgu_css_cfg_acc_stripe(struct imgu_css *css, unsigned int pipe,
> > acc->stripe.bds_out_stripes[1].width += f;
> > }
> > /* Overlap between stripes is IPU3_UAPI_ISP_VEC_ELEMS * 4 */
> > - acc->stripe.bds_out_stripes[1].offset =
> > - acc->stripe.bds_out_stripes[0].width - 2 * f;
> > + offset = acc->stripe.bds_out_stripes[0].width - 2 * f;
> > + if (WARN_ON(offset > 65535))
>
> If this can be triggered by userspace it shouldn't WARN_ON().
v2 will not have the WARN_ON.
Thanks!
>
> > + return -EINVAL;
> > + acc->stripe.bds_out_stripes[1].offset = offset;
> > }
> >
> > acc->stripe.effective_stripes[0].height =
>
> --
> Regards,
>
> Laurent Pinchart
--
Ricardo Ribalda
^ permalink raw reply
* Re: [PATCH 6/6] media: amlogic-c3: Add validations for ae and awb config
From: Ricardo Ribalda @ 2026-04-28 13:15 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mauro Carvalho Chehab, Sakari Ailus, Hans Verkuil, Nas Chung,
Jackson Lee, Bingbu Cao, Tianshu Qiu, Greg Kroah-Hartman, Keke Li,
linux-media, linux-kernel, linux-staging, Jacopo Mondi
In-Reply-To: <CANiDSCvaS-Jz9m5H2OHo2akD-o-sffsZyEw6_CrfUhD1BN+m2g@mail.gmail.com>
On Tue, 28 Apr 2026 at 15:14, Ricardo Ribalda <ribalda@chromium.org> wrote:
>
> Hi Laurent
>
> On Tue, 28 Apr 2026 at 15:10, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> >
> > Hi Ricardo,
> >
> > Thank you for the patch.
> >
> > CC'ing Jacopo.
> >
> > On Tue, Apr 28, 2026 at 12:41:12PM +0000, Ricardo Ribalda wrote:
> > > Avoid invalid memory access if the zones_num is bigger than
> > > zone_weight.
> > >
> > > This patch fixes the following smatch errors:
> > > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max
> > > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max
> > > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max
> > > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max
> > >
> > > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> > > ---
> > > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/media/platform/amlogic/c3/isp/c3-isp-params.c b/drivers/media/platform/amlogic/c3/isp/c3-isp-params.c
> > > index 6f9ca7a7dd88..42d780f684d1 100644
> > > --- a/drivers/media/platform/amlogic/c3/isp/c3-isp-params.c
> > > +++ b/drivers/media/platform/amlogic/c3/isp/c3-isp-params.c
> > > @@ -104,6 +104,8 @@ static void c3_isp_params_awb_wt(struct c3_isp_device *isp,
> > > c3_isp_write(isp, ISP_AWB_BLK_WT_ADDR, 0);
> > >
> > > zones_num = cfg->horiz_zones_num * cfg->vert_zones_num;
> > > + if (WARN_ON(zones_num > C3_ISP_AWB_MAX_ZONES))
> >
> > This is triggerable by userspace, it shouldn't result in a WARN_ON().
> > Ideally the horiz_zones_num and vert_zones_num should be validated at
> > buf prepare time, and an error should be returned to userspace. That
> > will likely not fix your smatch issue though, I don't think it will be
> > able to understand that the values have been validated.
>
> Based on the warnings from the other drivers I also suspect that if
> you have validated the data somewhere else smatch will understand it.
I mean that
will *NOT* understand it.
Sorry
>
> Even if you add a validate function I would suggest to keep the
> WARN_ON(), ideally it should never trigger, and if it triggers it will
> get a lot more attention to get it fixed.
>
> >
> > Jacopo, do we need to add a validate function pointer to
> > v4l2_isp_params_block_type_info ?
> >
> > > + zones_num = C3_ISP_AWB_MAX_ZONES;
> > >
> > > /* Need to write 8 weights at once */
> > > for (i = 0; i < zones_num / 8; i++) {
> > > @@ -220,6 +222,8 @@ static void c3_isp_params_ae_wt(struct c3_isp_device *isp,
> > > c3_isp_write(isp, ISP_AE_BLK_WT_ADDR, 0);
> > >
> > > zones_num = cfg->horiz_zones_num * cfg->vert_zones_num;
> > > + if (WARN_ON(zones_num > C3_ISP_AE_MAX_ZONES))
> > > + zones_num = C3_ISP_AE_MAX_ZONES;
> > >
> > > /* Need to write 8 weights at once */
> > > for (i = 0; i < zones_num / 8; i++) {
> > >
> >
> > --
> > Regards,
> >
> > Laurent Pinchart
>
>
>
> --
> Ricardo Ribalda
--
Ricardo Ribalda
^ permalink raw reply
* Re: [PATCH 6/6] media: amlogic-c3: Add validations for ae and awb config
From: Ricardo Ribalda @ 2026-04-28 13:14 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mauro Carvalho Chehab, Sakari Ailus, Hans Verkuil, Nas Chung,
Jackson Lee, Bingbu Cao, Tianshu Qiu, Greg Kroah-Hartman, Keke Li,
linux-media, linux-kernel, linux-staging, Jacopo Mondi
In-Reply-To: <20260428131038.GA120836@killaraus.ideasonboard.com>
Hi Laurent
On Tue, 28 Apr 2026 at 15:10, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Hi Ricardo,
>
> Thank you for the patch.
>
> CC'ing Jacopo.
>
> On Tue, Apr 28, 2026 at 12:41:12PM +0000, Ricardo Ribalda wrote:
> > Avoid invalid memory access if the zones_num is bigger than
> > zone_weight.
> >
> > This patch fixes the following smatch errors:
> > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max
> > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:111 c3_isp_params_awb_wt() error: buffer overflow 'cfg->zone_weight' 768 <= u32max
> > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max
> > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c:227 c3_isp_params_ae_wt() error: buffer overflow 'cfg->zone_weight' 255 <= u32max
> >
> > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> > ---
> > drivers/media/platform/amlogic/c3/isp/c3-isp-params.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/media/platform/amlogic/c3/isp/c3-isp-params.c b/drivers/media/platform/amlogic/c3/isp/c3-isp-params.c
> > index 6f9ca7a7dd88..42d780f684d1 100644
> > --- a/drivers/media/platform/amlogic/c3/isp/c3-isp-params.c
> > +++ b/drivers/media/platform/amlogic/c3/isp/c3-isp-params.c
> > @@ -104,6 +104,8 @@ static void c3_isp_params_awb_wt(struct c3_isp_device *isp,
> > c3_isp_write(isp, ISP_AWB_BLK_WT_ADDR, 0);
> >
> > zones_num = cfg->horiz_zones_num * cfg->vert_zones_num;
> > + if (WARN_ON(zones_num > C3_ISP_AWB_MAX_ZONES))
>
> This is triggerable by userspace, it shouldn't result in a WARN_ON().
> Ideally the horiz_zones_num and vert_zones_num should be validated at
> buf prepare time, and an error should be returned to userspace. That
> will likely not fix your smatch issue though, I don't think it will be
> able to understand that the values have been validated.
Based on the warnings from the other drivers I also suspect that if
you have validated the data somewhere else smatch will understand it.
Even if you add a validate function I would suggest to keep the
WARN_ON(), ideally it should never trigger, and if it triggers it will
get a lot more attention to get it fixed.
>
> Jacopo, do we need to add a validate function pointer to
> v4l2_isp_params_block_type_info ?
>
> > + zones_num = C3_ISP_AWB_MAX_ZONES;
> >
> > /* Need to write 8 weights at once */
> > for (i = 0; i < zones_num / 8; i++) {
> > @@ -220,6 +222,8 @@ static void c3_isp_params_ae_wt(struct c3_isp_device *isp,
> > c3_isp_write(isp, ISP_AE_BLK_WT_ADDR, 0);
> >
> > zones_num = cfg->horiz_zones_num * cfg->vert_zones_num;
> > + if (WARN_ON(zones_num > C3_ISP_AE_MAX_ZONES))
> > + zones_num = C3_ISP_AE_MAX_ZONES;
> >
> > /* Need to write 8 weights at once */
> > for (i = 0; i < zones_num / 8; i++) {
> >
>
> --
> Regards,
>
> Laurent Pinchart
--
Ricardo Ribalda
^ permalink raw reply
* Re: [PATCH 5/6] media: staging: ipu3-imgu: Add range check for imgu_css_cfg_acc_stripe
From: Laurent Pinchart @ 2026-04-28 13:13 UTC (permalink / raw)
To: Ricardo Ribalda
Cc: Mauro Carvalho Chehab, Sakari Ailus, Hans Verkuil, Nas Chung,
Jackson Lee, Bingbu Cao, Tianshu Qiu, Greg Kroah-Hartman, Keke Li,
linux-media, linux-kernel, linux-staging
In-Reply-To: <20260428-smatch-7-1-v1-5-46890dffb611@chromium.org>
On Tue, Apr 28, 2026 at 12:41:11PM +0000, Ricardo Ribalda wrote:
> If the driver's stripe information is invalid it can result in an integer
> overflow. Add a range check with a WARN_ON to expose this kind of
> error.
>
> This patch fixes the following smatch error:
> drivers/staging/media/ipu3/ipu3-css-params.c:1792 imgu_css_cfg_acc_stripe() warn: 'acc->stripe.bds_out_stripes[0]->width - 2 * f' 4294967168 can't fit into 65535 'acc->stripe.bds_out_stripes[1]->offset'
>
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> ---
> drivers/staging/media/ipu3/ipu3-css-params.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/media/ipu3/ipu3-css-params.c b/drivers/staging/media/ipu3/ipu3-css-params.c
> index 2c48d57a3180..6ed23c7a0c3f 100644
> --- a/drivers/staging/media/ipu3/ipu3-css-params.c
> +++ b/drivers/staging/media/ipu3/ipu3-css-params.c
> @@ -1770,6 +1770,8 @@ static int imgu_css_cfg_acc_stripe(struct imgu_css *css, unsigned int pipe,
> acc->stripe.bds_out_stripes[0].width =
> ALIGN(css_pipe->rect[IPU3_CSS_RECT_BDS].width, f);
> } else {
> + u32 offset;
> +
> /* Image processing is divided into two stripes */
> acc->stripe.bds_out_stripes[0].width =
> acc->stripe.bds_out_stripes[1].width =
> @@ -1788,8 +1790,10 @@ static int imgu_css_cfg_acc_stripe(struct imgu_css *css, unsigned int pipe,
> acc->stripe.bds_out_stripes[1].width += f;
> }
> /* Overlap between stripes is IPU3_UAPI_ISP_VEC_ELEMS * 4 */
> - acc->stripe.bds_out_stripes[1].offset =
> - acc->stripe.bds_out_stripes[0].width - 2 * f;
> + offset = acc->stripe.bds_out_stripes[0].width - 2 * f;
> + if (WARN_ON(offset > 65535))
If this can be triggered by userspace it shouldn't WARN_ON().
> + return -EINVAL;
> + acc->stripe.bds_out_stripes[1].offset = offset;
> }
>
> acc->stripe.effective_stripes[0].height =
--
Regards,
Laurent Pinchart
^ 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