Message-ID: <175916461248.2234821.1065883006028083651@freya>
Date: Mon, 29 Sep 2025 22:20:12 +0530
From: Jai Luthra <jai.luthra@...asonboard.com>
To: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
Cc: Hans Verkuil <hverkuil@...nel.org>, Mauro Carvalho Chehab <mchehab@...nel.org>, Sakari Ailus <sakari.ailus@...ux.intel.com>, Laurent Pinchart <laurent.pinchart@...asonboard.com>, Tomi Valkeinen <tomi.valkeinen@...asonboard.com>, Jacopo Mondi <jacopo.mondi@...asonboard.com>, linux-media@...r.kernel.org, Ricardo Ribalda <ribalda@...omium.org>, Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>, Al Viro <viro@...iv.linux.org.uk>, Ma Ke <make24@...as.ac.cn>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 01/10] media: v4l2-core: Introduce state management for video devices

Hi Mauro,

Quoting Mauro Carvalho Chehab (2025-09-24 15:45:45)
> Em Fri, 19 Sep 2025 15:25:53 +0530
> Jai Luthra <jai.luthra@...asonboard.com> escreveu:
> 
> > Similar to V4L2 subdev states, introduce state support for video devices
> > to provide a centralized location for storing device state information.
> > This includes the current (active) pixelformat used by the device and
> > the temporary (try) pixelformat used during format negotiation.
> 
> I didn't look at the patch series yet, so I may be just jumping too
> fast here, but storing "try" attempts doesn't seem the right thing to
> do.
> 
> Btw, IMHO, the first patch on this series should be against documentation,
> where you would be describing not only the new feature with the supported 
> states, but also the state machine transitions that are supported,
> preferably with some graphs.
> 
> So, before actually looking on any code changes, I'd like to see a clear
> description of this new feature, what it is proposing to address, how
> and what impacts (if any) this would bring to userspace.
> 
> The current diffstat:
> 
>  include/media/v4l2-ctrls.h                         |   5 +-
>  include/media/v4l2-dev.h                           |  84 +++++
>  include/media/v4l2-fh.h                            |   2 +
>  include/media/v4l2-ioctl.h                         | 238 ++++++-------
>  include/media/v4l2-mem2mem.h                       |  48 ++-
>  include/media/videobuf2-v4l2.h                     |  33 +-
> 
> implies that this affects for now only Documentation/driver-api/media/...

There shouldn't be any change to userspace with this series. The state
structure introduced here is only for internal use by the drivers, which
currently store the applied formats in driver-specific structures.

In the next revision, I will add documentation in v4l2-dev.rst similar to
how the subdev state is described in v4l2-subdev.rst.

> 
> > In the
> > future, this may be extended or subclassed by device drivers to store
> > their internal state variables.
> > 
> > Also introduce a flag for drivers that wish to use this state
> > management. When set, the framework automatically allocates the state
> > during device registration and stores a pointer to it within the
> > video_device structure.
> > 
> > This change aligns video devices with V4L2 subdevices by storing
> > hardware state in a common framework-allocated structure. This is the
> > first step towards enabling the multiplexing of the underlying hardware
> > by using different software "contexts", each represented by the combined
> > state of all video devices and V4L2 subdevices in a complex media graph.
> 
> ... but when you mention "contexts", I'm assuming that you're aiming
> at either userspace API changes and/or behavoral changes that will
> affect uAPI as well.

Yes, the userspace side changes are documented in Jacopo's series adding
context support for media devices, for example:

https://lore.kernel.org/linux-media/20250724-multicontext-mainline-2025-v2-7-c9b316773486@ideasonboard.com/

> 
> Thanks,
> Mauro

Thanks,
Jai

Powered by blists - more mailing lists