[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20250925105508.2323797-1-Anthony.McGivern@arm.com>
Date: Thu, 25 Sep 2025 11:55:08 +0100
From: Anthony McGivern <Anthony.McGivern@....com>
To: jacopo.mondi@...asonboard.com
Cc: bcm-kernel-feedback-list@...adcom.com,
florian.fainelli@...adcom.com,
hverkuil@...nel.org,
kernel-list@...pberrypi.com,
kieran.bingham@...asonboard.com,
laurent.pinchart@...asonboard.com,
linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org,
linux-rpi-kernel@...ts.infradead.org,
m.szyprowski@...sung.com,
mchehab@...nel.org,
nicolas.dufresne@...labora.com,
sakari.ailus@...ux.intel.com,
tfiga@...omium.org,
tomi.valkeinen@...asonboard.com
Subject: [PATCH v2 12/27] media: v4l2-subdev: Introduce v4l2 subdev context
Hi Jacopo,
On Thu, Jul 24, 2025 at 16:10:19 +0200, Jacopo Mondi write:
> Introduce a new type in v4l2 subdev that represents a v4l2 subdevice
> contex. It extends 'struct media_entity_context' and is intended to be
> extended by drivers that can store driver-specific information
> in their derived types.
>
> Signed-off-by: Jacopo Mondi <jacopo.mondi@...asonboard.com>
I am interested in how the sub-device context will handle the Streams API? Looking at the commits the v4l2_subdev_enable/disable_streams functions still appear to operate on the main sub-device only. I take it we would have additional context-aware functions here that can fetch the subdev state from the sub-device context, though I imagine some fields will have to be moved into the context such as s_stream_enabled, or even enabled_pads for non stream-aware drivers?
Anthony
Powered by blists - more mailing lists