Re: [RFC v5 04/15] media: Documentation: Add subdev configuration models, raw sensor model

[Mirela Rabulea <mirela.rabulea@nxp.com>]

Hi Sakari,

On 09.02.2025 17:42, Mirela Rabulea wrote:
> Hi Sakari,
>
> Reviewed-by: Mirela Rabulea <mirela.rabulea@nxp.com>
>
> Regards,
>
> Mirela
>
> On 03.02.2025 10:58, Sakari Ailus wrote:
>> Sub-device configuration models define what V4L2 API elements are
>> available on a compliant sub-device and how do they behave.
>>
>> The patch also adds a model for common raw sensors.
>>
>> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
>> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
>> ---
>>   .../media/drivers/camera-sensor.rst           |   4 +
>>   .../media/v4l/common-raw-sensor.dia           | 441 ++++++++++++++++++
>>   .../media/v4l/common-raw-sensor.svg           | 134 ++++++
>>   .../userspace-api/media/v4l/dev-subdev.rst    |   2 +
>>   .../media/v4l/subdev-config-model.rst         | 209 +++++++++
>>   5 files changed, 790 insertions(+)
>>   create mode 100644 
>> Documentation/userspace-api/media/v4l/common-raw-sensor.dia
>>   create mode 100644 
>> Documentation/userspace-api/media/v4l/common-raw-sensor.svg
>>   create mode 100644 
>> Documentation/userspace-api/media/v4l/subdev-config-model.rst
>>
>> ...

>> +
>> +Common raw camera sensor model
>> +------------------------------
>> +
>> +The common raw camera sensor model defines a set of enumeration and
>> +configuration interfaces (formats, selections etc.) that cover the 
>> vast majority
>> +of functionality of raw camera sensors. Not all of the interfaces are
>> +necessarily offered by all drivers.
>> +
>> +A sub-device complies with the common raw sensor model if the
>> +``V4L2_CONFIG_MODEL_COMMON_RAW`` bit is set in the 
>> ``V4L2_CID_CONFIG_MODEL``
>> +control of the sub-device.
>> +
>> +The common raw camera sensor model is aligned with
>> +:ref:`media_using_camera_sensor_drivers`. Please refer to that 
>> regarding aspects
>> +not specified here.
>> +
>> +Each camera sensor implementing the common raw sensor model exposes 
>> a single
>> +V4L2 sub-device. The sub-device contains a single source pad (0) and 
>> two or more
>> +internal pads: an image data internal pad (1) and optionally an 
>> embedded data
>> +pad (2). Additionally, further internal pads may be supported for other
>> +features, in which case they are documented separately for the given 
>> device.

One more question here, to be sure I understand correctly. So, in order 
to be compliant with the common raw camera sensor model, in case a raw 
sensor will need more than 2 internal pads, the expectation is to keep 
image on pad 0, edata on pad 1, and add more needed pads? Or is it 
acceptable that a driver completely changes the pad numbering according 
to it's needs, as long as it is documented?

The case I am targeting is os08a20 hdr sensor, with: pad1-image long 
exposure, pad2-edata, pad3-image short exposure. So far, so good, I guess.

I don't know if there will be such a case for a sensor driver which does 
not support embedded data, but will need to support other internal pads, 
and in such a case, how should pad numbering look like?


Thanks,

Mirela