From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Cc: linux-media@vger.kernel.org, Chen-Yu Tsai <wens@csie.org>,
Eugen Hristev <eugen.hristev@collabora.com>,
Hans Verkuil <hverkuil-cisco@xs4all.nl>,
Jacopo Mondi <jacopo.mondi@ideasonboard.com>,
Kieran Bingham <kieran.bingham@ideasonboard.com>,
Maxime Ripard <mripard@kernel.org>,
Sakari Ailus <sakari.ailus@iki.fi>,
linux-renesas-soc@vger.kernel.org, linux-sunxi@lists.linux.dev
Subject: Re: [PATCH v2 7/7] [DNI] media: renesas: vsp1: Validate all links through .link_validate()
Date: Mon, 26 Aug 2024 15:25:53 +0300 [thread overview]
Message-ID: <20240826122553.GF27785@pendragon.ideasonboard.com> (raw)
In-Reply-To: <ac44fb59-e0bd-4198-b75f-d6e5f5b1a681@ideasonboard.com>
On Mon, Aug 26, 2024 at 03:22:02PM +0300, Tomi Valkeinen wrote:
> On 26/08/2024 15:18, Laurent Pinchart wrote:
> > Hi Tomi,
> >
> > On Mon, Aug 26, 2024 at 02:43:47PM +0300, Tomi Valkeinen wrote:
> >> On 22/08/2024 18:45, Laurent Pinchart wrote:
> >>> Move validation of the links between video devices and subdevs,
> >>> performed manually in vsp1_video_streamon(), to the video device
> >>> .link_validate() handler.
> >>>
> >>> This is how drivers should be implemented, but sadly, doing so for the
> >>> vsp1 driver could break userspace, introducing a regression. This patch
> >>> serves as an example to showcase usage of the .link_validate()
> >>> operation, but should not be merged.
> >>>
> >>> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> >>> ---
> >>> .../media/platform/renesas/vsp1/vsp1_video.c | 98 +++++++------------
> >>> 1 file changed, 37 insertions(+), 61 deletions(-)
> >>>
> >>> diff --git a/drivers/media/platform/renesas/vsp1/vsp1_video.c b/drivers/media/platform/renesas/vsp1/vsp1_video.c
> >>> index e728f9f5160e..14575698bbe7 100644
> >>> --- a/drivers/media/platform/renesas/vsp1/vsp1_video.c
> >>> +++ b/drivers/media/platform/renesas/vsp1/vsp1_video.c
> >>> @@ -45,51 +45,6 @@
> >>> * Helper functions
> >>> */
> >>>
> >>> -static struct v4l2_subdev *
> >>> -vsp1_video_remote_subdev(struct media_pad *local, u32 *pad)
> >>> -{
> >>> - struct media_pad *remote;
> >>> -
> >>> - remote = media_pad_remote_pad_first(local);
> >>> - if (!remote || !is_media_entity_v4l2_subdev(remote->entity))
> >>> - return NULL;
> >>> -
> >>> - if (pad)
> >>> - *pad = remote->index;
> >>> -
> >>> - return media_entity_to_v4l2_subdev(remote->entity);
> >>> -}
> >>> -
> >>> -static int vsp1_video_verify_format(struct vsp1_video *video)
> >>> -{
> >>> - struct v4l2_subdev_format fmt = {
> >>> - .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> >>> - };
> >>> - struct v4l2_subdev *subdev;
> >>> - int ret;
> >>> -
> >>> - subdev = vsp1_video_remote_subdev(&video->pad, &fmt.pad);
> >>> - if (subdev == NULL)
> >>> - return -EINVAL;
> >>> -
> >>> - ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, &fmt);
> >>> - if (ret < 0)
> >>> - return ret == -ENOIOCTLCMD ? -EINVAL : ret;
> >>> -
> >>> - if (video->rwpf->fmtinfo->mbus != fmt.format.code ||
> >>> - video->rwpf->format.height != fmt.format.height ||
> >>> - video->rwpf->format.width != fmt.format.width) {
> >>> - dev_dbg(video->vsp1->dev,
> >>> - "Format mismatch: 0x%04x/%ux%u != 0x%04x/%ux%u\n",
> >>> - video->rwpf->fmtinfo->mbus, video->rwpf->format.width,
> >>> - video->rwpf->format.height, fmt.format.code,
> >>> - fmt.format.width, fmt.format.height);
> >>> - return -EPIPE;
> >>> - }
> >>> -
> >>> - return 0;
> >>> -}
> >>> -
> >>> static int __vsp1_video_try_format(struct vsp1_video *video,
> >>> struct v4l2_pix_format_mplane *pix,
> >>> const struct vsp1_format_info **fmtinfo)
> >>> @@ -991,14 +946,6 @@ vsp1_video_streamon(struct file *file, void *fh, enum v4l2_buf_type type)
> >>>
> >>> mutex_unlock(&mdev->graph_mutex);
> >>>
> >>> - /*
> >>> - * Verify that the configured format matches the output of the connected
> >>> - * subdev.
> >>> - */
> >>> - ret = vsp1_video_verify_format(video);
> >>> - if (ret < 0)
> >>> - goto err_stop;
> >>> -
> >>> /* Start the queue. */
> >>> ret = vb2_streamon(&video->queue, type);
> >>> if (ret < 0)
> >>> @@ -1087,14 +1034,43 @@ static const struct v4l2_file_operations vsp1_video_fops = {
> >>>
> >>> static int vsp1_video_link_validate(struct media_link *link)
> >>> {
> >>> - /*
> >>> - * Ideally, link validation should be implemented here instead of
> >>> - * calling vsp1_video_verify_format() in vsp1_video_streamon()
> >>> - * manually. That would however break userspace that start one video
> >>> - * device before configures formats on other video devices in the
> >>> - * pipeline. This operation is just a no-op to silence the warnings
> >>> - * from v4l2_subdev_link_validate().
> >>> - */
> >>> + struct v4l2_subdev_format fmt = {
> >>> + .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> >>> + };
> >>> + struct v4l2_subdev *subdev;
> >>> + struct media_entity *entity;
> >>> + struct media_pad *remote;
> >>> + struct vsp1_video *video;
> >>> + int ret;
> >>> +
> >>> + if (is_media_entity_v4l2_video_device(link->source->entity)) {
> >>> + entity = link->source->entity;
> >>> + remote = link->sink;
> >>> + } else {
> >>> + entity = link->sink->entity;
> >>> + remote = link->source;
> >>> + }
> >>
> >> This looks a bit odd. So this device can be either a source and a sink?
> >
> > Correct. The VSP has both capture and output video devices, and this
> > helper function is used for both.
> >
> >> This made me also wonder about the .link_validate(). It's the only
> >> media_entity_operations op that does not get the media_entity as a
> >> parameter. Which here means the driver has to go and "guess" whether it
> >> is the source or the sink of the given link.
> >>
> >> I wonder if there's a reason why .link_validate() doesn't have the
> >> media_entity parameter?
> >
> > Because it validates a link. Which of the sink or source entity would
> > you pass to the function ?
>
> The one where the op is defined.
With the exception of links from video output devices to subdevs, it's
always the sink. I don't expect most drivers to use a single validation
function for the capture and output video devices, so I don't think
passing the entity pointer is that crucial. We could however improve
this on top in case it ends up being a common use case.
> >>> +
> >>> + fmt.pad = remote->index;
> >>> +
> >>> + subdev = media_entity_to_v4l2_subdev(remote->entity);
> >>> + ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, &fmt);
> >>> + if (ret < 0)
> >>> + return ret == -ENOIOCTLCMD ? -EINVAL : ret;
> >>> +
> >>> + video = to_vsp1_video(media_entity_to_video_device(entity));
> >>> +
> >>> + if (video->rwpf->fmtinfo->mbus != fmt.format.code ||
> >>> + video->rwpf->format.height != fmt.format.height ||
> >>> + video->rwpf->format.width != fmt.format.width) {
> >>> + dev_dbg(video->vsp1->dev,
> >>> + "Format mismatch: 0x%04x/%ux%u != 0x%04x/%ux%u\n",
> >>> + video->rwpf->fmtinfo->mbus, video->rwpf->format.width,
> >>> + video->rwpf->format.height, fmt.format.code,
> >>> + fmt.format.width, fmt.format.height);
> >>> + return -EPIPE;
> >>> + }
> >>
> >> Why don't we have a common videodev state which could be used to do
> >> these validations in a common function? =)
> >
> > Because you haven't sent patches yet ;-)
> >
> > But jokes aside, because there's no 1:1 mapping between media bus codes
> > and pixel formats, so drivers have to validate at least that part.
> >
> >> Fwiw:
> >> Reviewed-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2024-08-26 12:26 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-22 15:45 [PATCH v2 0/7] media: v4l2: Improve media link validation Laurent Pinchart
2024-08-22 15:45 ` [PATCH v2 1/7] media: microchip-isc: Drop v4l2_subdev_link_validate() for video devices Laurent Pinchart
2024-08-26 10:58 ` Tomi Valkeinen
2024-08-22 15:45 ` [PATCH v2 2/7] media: sun4i_csi: Implement link validate for sun4i_csi subdev Laurent Pinchart
2024-08-26 10:59 ` Tomi Valkeinen
2024-08-22 15:45 ` [PATCH v2 3/7] media: sun4i_csi: Don't use v4l2_subdev_link_validate() for video device Laurent Pinchart
2024-08-26 11:04 ` Tomi Valkeinen
2024-08-26 11:56 ` Laurent Pinchart
2024-08-22 15:45 ` [PATCH v2 4/7] media: v4l2-subdev: Refactor warnings in v4l2_subdev_link_validate() Laurent Pinchart
2024-08-26 11:10 ` Tomi Valkeinen
2024-08-26 12:05 ` Laurent Pinchart
2024-08-22 15:45 ` [PATCH v2 5/7] media: v4l2-subdev: Support hybrid links " Laurent Pinchart
2024-08-26 11:23 ` Tomi Valkeinen
2024-08-26 12:11 ` Laurent Pinchart
2024-08-22 15:45 ` [PATCH v2 6/7] media: renesas: vsp1: Implement .link_validate() for video devices Laurent Pinchart
2024-08-26 11:49 ` Tomi Valkeinen
2024-08-26 12:14 ` Laurent Pinchart
2024-08-22 15:45 ` [PATCH v2 7/7] [DNI] media: renesas: vsp1: Validate all links through .link_validate() Laurent Pinchart
2024-08-26 11:43 ` Tomi Valkeinen
2024-08-26 12:18 ` Laurent Pinchart
2024-08-26 12:22 ` Tomi Valkeinen
2024-08-26 12:25 ` Laurent Pinchart [this message]
2024-08-26 12:36 ` Tomi Valkeinen
-- strict thread matches above, loose matches on Subject: below --
2024-08-22 15:35 [PATCH v2 0/7] media: v4l2: Improve media link validation Laurent Pinchart
2024-08-22 15:35 ` [PATCH v2 7/7] [DNI] media: renesas: vsp1: Validate all links through .link_validate() Laurent Pinchart
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=20240826122553.GF27785@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=eugen.hristev@collabora.com \
--cc=hverkuil-cisco@xs4all.nl \
--cc=jacopo.mondi@ideasonboard.com \
--cc=kieran.bingham@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=mripard@kernel.org \
--cc=sakari.ailus@iki.fi \
--cc=tomi.valkeinen@ideasonboard.com \
--cc=wens@csie.org \
/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