| Message ID | 20231003115237.76828-10-sakari.ailus@linux.intel.com |
|---|---|
| State | New |
| Headers | show |
| Series | Generic line based metadata support, internal pads | expand |
Hi Hans, On Thu, Oct 05, 2023 at 12:10:29PM +0200, 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@linux.intel.com> > > --- > > .../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."? Bridge devices that transmit what they received over CSI-2 may result in embedded data on parallel bus, for instance. I'm fine with using the text you suggested, it's equally true as well. > > > + > > +Embedded data support should use an internal source pad and route to the > > should or shall/must? I'll change this to shall.
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@linux.intel.com> > > > --- > > > .../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.
Hi Hans, On Thu, Oct 05, 2023 at 12:14:05PM +0200, 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@linux.intel.com> > > --- > > .../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. > > + > > +Embedded data support should use an internal source pad and route to the > > "internal source pad" -> "internal sink pad"? > > > +external pad. If embedded data output can be disabled in hardware, it should be > > "external pad" -> "external source pad"? > > Or perhaps "a source pad of the entity"? The documentation discusses "internal source pads" that are in fact internal pads with the INTERNAL and SINK flags set. This is probably present in other patches, too. The terms are indeed confusing, I'll see if I could rephrase it. Of the two options, I prefer the former.
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. + +Embedded data support should use an internal source pad and route to the +external pad. If embedded data output can be disabled in hardware, it should be +possible to disable the embedded data route via ``VIDIOC_SUBDEV_S_ROUTING`` +IOCTL. + +In general, changing the embedded data format from the driver-configured values +is not supported. The height of the metadata is hardware specific and the width +is that (or less of that) of the image width, as configured on the pixel data +stream. + +CCS and non-CCS embedded data +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Embedded data which is compliant with CCS definitions shall use ``CCS embedded +data format <MEDIA-BUS-FMT-CCS-EMBEDDED>``. Device specific embedded data which +is compliant up to MIPI CCS embedded data levels 1 or 2 only shall refer to CCS +embedded data formats and document the level of conformance. The rest of the +device specific embedded data format shall be documented in the context of the +data format itself.
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@linux.intel.com> --- .../media/drivers/camera-sensor.rst | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+)