Moi, On Wed, Aug 23, 2023 at 04:16:13PM +0300, Tomi Valkeinen wrote: > Hi Sakari, > > On 08/08/2023 10:55, Sakari Ailus wrote: > > Add generic serial metadata mbus formats. These formats describe data > > width and packing but not the content itself. The reason for specifying > > such formats is that the formats as such are fairly device specific but > > they are still handled by CSI-2 receiver drivers that should not be aware > > of device specific formats. What makes generic metadata formats possible > > is that these formats are parsed by software only, after capturing the > > data to system memory. > > If I'm not mistaken, the CSI-2 spec doesn't say much about embedded data, > except that it may exist. Afaics, in CSI-2, the embedded data is split into > "lines", although the amount of data can be different than in the video > lines. > > The CCS specs talks more about embedded data. Some of it is quite odd, like: > "The length of the embedded data line shall not exceed the length of the > image data line. The embedded data line should have the same length as the > image data line.". I think it means the embedded line can be shorter than > image line, but not longer. That's what it means, yes. The CCS also has means to obtain the actual length --- frame format descriptors. > > CCS also says that an embedded line should use 0x07 as padding at the end of > the line, if there's less data than the image line. > > CCS also talks about how the embedded data would be packed, and in some > cases that packing would be the same as for pixel data. In fact the packing is the same as for pixel data: the CSI-2 does not really differentiate there. > > But I don't think these formats are generic. They're defined in CCS, so > shouldn't the format be, e.g., MEDIA_BUS_FMT_META_CCS_RAW_12 or such? The reason for having generic definitions is that we do not need receiver drivers to be aware of formats that are specific to another driver. If there is a need for new generic formats that do not match this, we can always add more. But the point is: drivers for devices that do not produce the data should never deal with (device) specific formats. What comes to CSI-2 and these formats --- on parallel buses you might have the data aligned to the least significant bits instead. But is there a need to transport such data on parallel buses, at least so it would be expressed in mbus formats? > > The MEDIA_BUS_FMT_META_8 is quite safe one, as it just means byte data > without any padding or packing. As you're always dealing with 8 bits only, there is of course less room for variation. -- Regards, Sakari Ailus
