Re: [PATCH v3 07/10] media: uapi: Add generic 8-bit metadata format definitions

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

 



On Thu, Sep 07, 2023 at 08:06:10AM +0000, Sakari Ailus wrote:
> Hi Laurent,
> 
> On Wed, Sep 06, 2023 at 04:47:37PM +0300, Laurent Pinchart wrote:
> > On Wed, Sep 06, 2023 at 01:39:59PM +0000, Sakari Ailus wrote:
> > > Hi Laurent,
> > > 
> > > On Wed, Sep 06, 2023 at 04:30:57PM +0300, Laurent Pinchart wrote:
> > > > On Wed, Sep 06, 2023 at 01:25:53PM +0000, Sakari Ailus wrote:
> > > > > On Wed, Sep 06, 2023 at 03:36:58PM +0300, Laurent Pinchart wrote:
> > > > > > On Wed, Sep 06, 2023 at 11:36:45AM +0000, Sakari Ailus wrote:
> > > > > > > On Tue, Sep 05, 2023 at 07:47:20PM +0300, Laurent Pinchart wrote:
> > > > > > > > On Fri, Aug 11, 2023 at 09:11:39AM +0000, Sakari Ailus wrote:
> > > > > > > > > On Fri, Aug 11, 2023 at 08:31:16AM +0200, Jacopo Mondi wrote:
> > > > > > > > > > > > +V4L2_META_FMT_GENERIC_CSI2_10
> > > > > > > > > > > > +-----------------------------
> > > > > > > > > > > > +
> > > > > > > > > > > > +V4L2_META_FMT_GENERIC_CSI2_10 contains packed 8-bit generic metadata, 10 bits
> > > > > > > > > > > > +for each 8 bits of data. Every four bytes of metadata is followed by a single
> > > > > > > > > > > > +byte of padding. The way the data is stored follows the CSI-2 specification.
> > > > > > > > > > > > +
> > > > > > > > > > > > +This format is also used on CSI-2 on 20 bits per sample format that packs two
> > > > > > > > > > > > +bytes of metadata into one sample.
> > > > > > > > > > > > +
> > > > > > > > > > > > +This format is little endian.
> > > > > > > > > > > > +
> > > > > > > > > > > > +**Byte Order Of V4L2_META_FMT_GENERIC_CSI2_10.**
> > > > > > > > > > > > +Each cell is one byte. "M" denotes a byte of metadata and "p" a byte of padding.
> > > > > > > > > > >
> > > > > > > > > > > I think you should document whether the padding is always 0 or can be any value.
> > > > > > > > > > > Perhaps 'X' is a better 'name' for the padding byte in the latter case.
> > > > > > > > > > 
> > > > > > > > > > Did I get this right that this format is supposed to work as the RAW10
> > > > > > > > > > CSI-2 packed image format, where 4 bytes contain the higher 8 bits of
> > > > > > > > > > the 10 bits sample and the 5th byte every 4 contains the lower 2 bits of
> > > > > > > > > > the previous 4 sample ?
> > > > > > > > > > 
> > > > > > > > > > If that's the case, is 'padding' the correct term here ?
> > > > > > > > > 
> > > > > > > > > What else would you call it? It'll be zeros that exist just due to the bit
> > > > > > > > > depth used and as such not interesting at all.
> > > > > > > > 
> > > > > > > > It's actually not 0, CCS requires the padding bytes to be 0x55.
> > > > > > > > 
> > > > > > > > I wonder if the conformance test suite tests the contents of the padding
> > > > > > > > bytes.
> > > > > > > 
> > > > > > > I don't know. I could add the value is unspecified but as it has not been
> > > > > > > specified, there's no change in meaning (just size).
> > > > > > 
> > > > > > I started writing that I don't see how it could help applications to
> > > > > > know that the padding byte is 0x55, but the SMIA++ embedded data parser
> > > > > > in libcamera actually checks for it, and considers the embedded data to
> > > > > > be erroneous if it has a different value.
> > > > > 
> > > > > I think it's fine to check for it if you know it's CCS/SMIA++/SMIA embedded
> > > > > data. But documenting it here isn't a great idea as then other uses of this
> > > > > format definition would be excluded.
> > > > 
> > > > I'm OK with that, but note that you've mentioned in a different patch in
> > > > the same series that you wouldn't use the CCS media bus code for sensors
> > > > that are compliant with the CCS packing and encoding but not the CCS
> > > > register set. That's not very consistent :-)
> > > 
> > > Which specific patch are you referring to?
> > 
> > "[PATCH v3 09/10] media: Add media bus codes for MIPI CCS embedded data"
> > 
> > You wrote
> > 
> > "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."
> 
> Ah, right.
> 
> I meant that if a sensor implementation isn't related to any of these
> standards, it's highly unlikely to use the same embedded data format. Of
> course, if it does, then I think we should use the mbus code, too. But I'm
> not holding my breath.

To clarify: to use that format, I'd expect the sensor to use standard CCS
registers. If it doesn't, a new mbus code should be added and documented.
The CCS embedded data header isn't enough to justify the use of the mbus
code --- the documentation here also says "which is used to store the
register configuration used for capturing a given frame".

-- 
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