Moi, On Thu, Oct 05, 2023 at 02:53:25PM +0300, Tomi Valkeinen wrote: > On 05/10/2023 13:10, Hans Verkuil wrote: > > On 03/10/2023 13:52, Sakari Ailus wrote: > > > Document how embedded data support should be implemented for camera > > > sensors, and when and how CCS embedded data format should be referenced. > > > > > > Signed-off-by: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> > > > --- > > > .../media/drivers/camera-sensor.rst | 28 +++++++++++++++++++ > > > 1 file changed, 28 insertions(+) > > > > > > diff --git a/Documentation/userspace-api/media/drivers/camera-sensor.rst b/Documentation/userspace-api/media/drivers/camera-sensor.rst > > > index 919a50e8b9d9..308f391c5ca1 100644 > > > --- a/Documentation/userspace-api/media/drivers/camera-sensor.rst > > > +++ b/Documentation/userspace-api/media/drivers/camera-sensor.rst > > > @@ -102,3 +102,31 @@ register programming sequences shall initialize the :ref:`V4L2_CID_HFLIP > > > values programmed by the register sequences. The default values of these > > > controls shall be 0 (disabled). Especially these controls shall not be inverted, > > > independently of the sensor's mounting rotation. > > > + > > > +Embedded data > > > +------------- > > > + > > > +Many sensors, mostly raw sensors, support embedded data which is used to convey > > > +the sensor configuration for the captured frame back to the host. While CSI-2 is > > > +the most common bus used by such sensors, embedded data is not entirely limited > > > +to CSI-2 bus due to e.g. bridge devices. > > > > I'm not quite sure what you mean with "embedded data is not entirely limited > > to CSI-2 bus due to e.g. bridge devices": do you just want to say: "embedded data > > can be available on other bus types as well."? > > Right, nothing CSI-2 specific here. I have a parallel sensor that sends > embedded data as the last (or was it first?) few lines of the frame. > > Also, is this about sensors only, and more specifically, about generating > the embedded data? If yes, why mention bridge devices (and should the title > be "Embedded data generation" or such)? If not, is it about metadata in > general, in which case bridges come into play? > > > > + > > > +Embedded data support should use an internal source pad and route to the > > > > should or shall/must? > > Is the above necessary? I don't see anything wrong with, say, having a > sensor represented with multiple subdevs, and one subdev is used for the > embedded data generation. > > Basically, anything that can be represented with internal pads can also be > done with multiple subdevs, although I think you don't want to go the > multiple subdev route unless absolutely necessary. True. This is trying to convey to the user space developers what's possible vs. suggesting driver developers what to do. I'd expect embedded data to use internal source pads, anything else will need to be separately agreed upon. -- Terveisin, Sakari Ailus
