From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Nicolas Dufresne <nicolas@ndufresne.ca>
Cc: Stefan Klug <stefan.klug@ideasonboard.com>,
Xavier Roumegue <xavier.roumegue@oss.nxp.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Clark Williams <clrkwllms@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rt-devel@lists.linux.dev
Subject: Re: [PATCH 2/4] media: dw100: Implement dynamic vertex map update
Date: Tue, 6 Jan 2026 16:35:39 +0200 [thread overview]
Message-ID: <20260106143539.GA26157@pendragon.ideasonboard.com> (raw)
In-Reply-To: <2dbb2c41422cb4dbc8c3692646aeaf70c4d87df0.camel@ndufresne.ca>
Hi Nicolas,
On Tue, Jan 06, 2026 at 08:47:59AM -0500, Nicolas Dufresne wrote:
> Le mardi 06 janvier 2026 à 02:42 +0200, Laurent Pinchart a écrit :
> > On Mon, Jan 05, 2026 at 01:58:25PM -0500, Nicolas Dufresne wrote:
> > > Le lundi 05 janvier 2026 à 12:35 +0100, Stefan Klug a écrit :
> > > > Implement dynamic vertex map updates by handling the
> > > > V4L2_CID_DW100_DEWARPING_16x16_VERTEX_MAP control during streaming. This
> > > > allows to implement features like dynamic zoom, pan, rotate and dewarp.
> > > >
> > > > To stay compatible with the old version, updates of
> > > > V4L2_CID_DW100_DEWARPING_16x16_VERTEX_MAP are ignored during streaming
> > > > when requests are not used. Print a corresponding warning once.
> > > >
> > > > Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
> > > > ---
> > > > drivers/media/platform/nxp/dw100/dw100.c | 27 +++++++++++++++++++++------
> > > >
>
> [...]
>
> > > > dev_dbg(&ctx->dw_dev->pdev->dev,
> > > > "%ux%u %s mapping created (d:%pad-c:%p) for stream %ux%u->%ux%u\n",
> > > > @@ -351,6 +355,7 @@ static int dw100_s_ctrl(struct v4l2_ctrl *ctrl)
> > > > switch (ctrl->id) {
> > > > case V4L2_CID_DW100_DEWARPING_16x16_VERTEX_MAP:
> > > > ctx->user_map_is_set = true;
> > > > + ctx->user_map_needs_update = true;
> > >
> > > This will be called before the new mapping is applied by
> > > v4l2_ctrl_request_complete(), and then may be cleared too soon if you queue
> > > depth is high enough.
> >
> > v4l2_ctrl_request_complete() does not apply a mapping, what am I missing
> > ?
>
> Sorry for my confusion, after reading back, you are correct, this is called
> v4l2_ctrl_request_setup() inside the device_run() function. You can dismiss the
> bit about user_map_needs_update in my review (the paragraph below).
Thanks for the clarification.
> > > Instead, you should check in the request for the presence of
> > > V4L2_CID_DW100_DEWARPING_16x16_VERTEX_MAP to optimize the updates. Yo may still
> > > set this to true if if there is no request, in the case you also wanted to
> > > change the original behaviour of only updating that vertex on streamon, but I
> > > don't see much point though.
> > >
> > > > break;
> > > > }
> > > >
> > > > @@ -405,6 +410,7 @@ static void dw100_ctrl_dewarping_map_init(const struct v4l2_ctrl *ctrl,
> > > > }
> > > >
> > > > ctx->user_map_is_set = false;
> > > > + ctx->user_map_needs_update = true;
> > > > }
> > > >
> > > > static const struct v4l2_ctrl_type_ops dw100_ctrl_type_ops = {
> > > > @@ -1482,6 +1488,15 @@ static void dw100_device_run(void *priv)
> > > > v4l2_ctrl_request_setup(src_buf->vb2_buf.req_obj.req,
> > > > &ctx->hdl);
> > > >
> > > > + if (src_buf->vb2_buf.req_obj.req) {
> > > > + dw100_update_mapping(ctx);
> > > > + } else if (ctx->user_map_needs_update && !ctx->warned_dynamic_update) {
> > > > + ctx->warned_dynamic_update = true;
> > > > + dev_warn(&ctx->dw_dev->pdev->dev,
> > > > + "V4L2 requests are required to update the vertex map dynamically"
> > >
> > > Do you know about dev_warn_once() ? That being said, the driver is usable
> > > without requests and a static vertex (and must stay this way to not break the
> > > ABI). I don't think you should warn here at all.
> >
> > Applications should move to using requests. We'll do so in libcamera
> > unconditionally. I don't expect many other direct users, so warning that
> > the mapping won't be applied when an application sets the corresponding
> > control during streaming without using requests seems fair to me. It
> > will help debugging issues.
>
> It is also a miss-use of dev_warn which is meant to indicate a problem with the
> driver or the hardware. The V4L2 core uses dev_dbg() or customer log level for
> that in general. Also, don't re-implement _once() variants with
> warned_dynamic_update please.
Agreed about the _once() variant. That will move to printing the message
once per context to once globally, but I think it's fine given the
purpose of warning application developers of incorrect usage.
> Personally, I would just let the out-of request
> change the control on the next device_run(), even if that means its out of sync.
So you mean changing the current behaviour of applying the control at
next streamon to next .device_run() even if it means synchronization
between the control and the frame being processed can't be guaranteed ?
I don't think that's a good idea, synchronization is a key requirement.
We carried a local kernel patch that would do just that, and to make it
usable we had to ensure in libcamera that we never queued more than one
buffer at a time, to guarantee synchronous behaviour. I think
applications should use the request API for dynamic updates of the
dewarp map.
> > > > + );
> > > > + }
> > > > +
> > > > v4l2_ctrl_request_complete(src_buf->vb2_buf.req_obj.req,
> > > > &ctx->hdl);
> > > >
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2026-01-06 14:36 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-05 11:35 [PATCH 0/4] media: dw100: Dynamic vertex map updates and fixes for PREEMPT_RT Stefan Klug
2026-01-05 11:35 ` [PATCH 1/4] media: dw100: Implement V4L2 requests support Stefan Klug
2026-01-05 18:46 ` Nicolas Dufresne
2026-01-06 0:33 ` Laurent Pinchart
2026-01-06 14:16 ` Stefan Klug
2026-01-06 14:35 ` Nicolas Dufresne
2026-01-06 14:59 ` Laurent Pinchart
2026-01-06 15:44 ` Nicolas Dufresne
2026-01-06 14:53 ` Laurent Pinchart
2026-01-06 15:41 ` Nicolas Dufresne
2026-01-06 15:45 ` Laurent Pinchart
2026-01-06 15:56 ` Nicolas Dufresne
2026-01-06 17:25 ` Laurent Pinchart
2026-01-05 11:35 ` [PATCH 2/4] media: dw100: Implement dynamic vertex map update Stefan Klug
2026-01-05 18:58 ` Nicolas Dufresne
2026-01-06 0:42 ` Laurent Pinchart
2026-01-06 13:47 ` Nicolas Dufresne
2026-01-06 14:29 ` Stefan Klug
2026-01-06 15:27 ` Nicolas Dufresne
2026-01-06 17:30 ` Laurent Pinchart
2026-01-06 14:35 ` Laurent Pinchart [this message]
2026-01-05 11:35 ` [PATCH 3/4] media: dw100: Fix kernel oops with PREEMPT_RT enabled Stefan Klug
2026-01-05 19:02 ` Nicolas Dufresne
2026-01-05 23:59 ` Laurent Pinchart
2026-01-06 0:39 ` Steven Rostedt
2026-01-06 0:49 ` Laurent Pinchart
2026-01-06 17:11 ` Stefan Klug
2026-01-12 11:43 ` Sebastian Andrzej Siewior
2026-01-14 17:22 ` Stefan Klug
2026-01-23 8:24 ` Sebastian Andrzej Siewior
2026-01-05 11:35 ` [PATCH 4/4] media: dw100: Split interrupt handler to fix timeout error Stefan Klug
2026-01-05 19:03 ` Nicolas Dufresne
2026-01-05 21:37 ` Steven Rostedt
2026-01-05 23:44 ` Laurent Pinchart
2026-01-06 0:43 ` Steven Rostedt
2026-01-06 0:51 ` Laurent Pinchart
2026-01-06 0:57 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260106143539.GA26157@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=bigeasy@linutronix.de \
--cc=clrkwllms@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=mchehab@kernel.org \
--cc=nicolas@ndufresne.ca \
--cc=rostedt@goodmis.org \
--cc=stefan.klug@ideasonboard.com \
--cc=xavier.roumegue@oss.nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox