Re: [PATCH v3 09/10] media: Add media bus codes for MIPI CCS embedded data

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Laurent,

On Wed, Sep 06, 2023 at 04:15:10PM +0300, Laurent Pinchart wrote:
> On Wed, Sep 06, 2023 at 01:03:18PM +0000, Sakari Ailus wrote:
> > On Tue, Sep 05, 2023 at 08:25:35PM +0300, Laurent Pinchart wrote:
> > > On Tue, Aug 08, 2023 at 10:55:37AM +0300, Sakari Ailus wrote:
> > > > Add new MIPI CCS embedded data media bus formats.
> > > > 
> > > > Signed-off-by: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx>
> > > > ---
> > > >  .../media/v4l/subdev-formats.rst              | 32 +++++++++++++++++++
> > > >  include/uapi/linux/media-bus-format.h         | 10 +++++-
> > > >  2 files changed, 41 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst b/Documentation/userspace-api/media/v4l/subdev-formats.rst
> > > > index c615da08502d..5d5407738af9 100644
> > > > --- a/Documentation/userspace-api/media/v4l/subdev-formats.rst
> > > > +++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst
> > > > @@ -8491,3 +8491,35 @@ and finally the bit number in subscript. "p" indicates a padding bit.
> > > >        - p
> > > >        - p
> > > >        - p
> > > > +
> > > > +MIPI CCS Embedded Data Formats
> > > > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > +
> > > > +`MIPI CCS <https://www.mipi.org/specifications/camera-command-set>`_ defines an
> > > 
> > > s/an$/a/
> > 
> > Yes. I think I had "embedded" there in the past...
> > 
> > > > +metadata format for sensor embedded data, which is used to store the register
> > > > +configuration used for capturing a given frame. The format is defined in the CCS
> > > > +specification.
> > > 
> > > Strictly speaking, the MIPI CCS embedded data format specifies not just
> > > the data packing (insertion of padding bytes) and the data encoding (the
> > > data format byte and the tag codes), but also the register addresses and
> > > values that are reported in the embedded data. Do you envision the media
> > > bus formats defined here as being applicable to sensors that use the
> > > same packing and encoding as CCS, but different registers, or only to
> > > fully compliant CCS sensors ?
> > 
> > There are sensors that aren't fully compatible with CCS (including those
> > compatible with SMIA and SMIA++) but I wouldn't expect the format to be
> > used by devices that are entirely incompatible with CCS.
> 
> So if a sensor uses the same packing and encoding as CCS, but a
> different register set, you would require other media bus codes ? If so,
> how would you require those media bus codes to be documented ? The
> packing and encoding could be documented as being identical to CCS, but
> what about the data itself ? Would you require the datasheet to be
> public ? Or the entire register set being documented in the V4L2 spec ?

I'd hope the registers the values of which are written in the embedded data
should be documented, either in V4L2 spec or other documentation.

But then, what do you do if you don't have documentation for all the
registers while you'd like to use what in general is needed there, exposure
time and gain? Do we say no, you can't do that because everything isn't
documented, or do we say yes, you can document this format partially.
That's what we should discuss and decide.

Note that commonly the case is that whoever would like to use the
information in the embedded data may well not have the full documentation
either. Also, even without documentation, it is in the vast majority of
the cases trivial to figure out where these values can be found.

-- 
Regards,

Sakari Ailus



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux