Re: [Q] Interleaved formats on the media bus

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Sylwester,

On Saturday 04 February 2012 18:00:10 Sylwester Nawrocki wrote:
> On 02/04/2012 12:34 PM, Laurent Pinchart wrote:
> > On Thursday 02 February 2012 12:14:08 Sylwester Nawrocki wrote:
> >> On 02/02/2012 10:55 AM, Laurent Pinchart wrote:
> >>> Do all those sensors interleave the data in the same way ? This sounds
> >>> quite
> >> 
> >> No, each one uses it's own interleaving method.
> >> 
> >>> hackish and vendor-specific to me, I'm not sure if we should try to
> >>> generalize that. Maybe vendor-specific media bus format codes would be
> >>> the way to go. I don't expect ISPs to understand the format, they will
> >>> likely be configured in pass-through mode. Instead of adding explicit
> >>> support for all those weird formats to all ISP drivers, it might make
> >>> sense to add a "binary blob" media bus code to be used by the ISP.
> >> 
> >> This could work, except that there is no way to match a fourcc with media
> >> bus code. Different fourcc would map to same media bus code, making it
> >> impossible for the brigde to handle multiple sensors or one sensor
> >> supporting multiple interleaved formats. Moreover there is a need to map
> >> media bus code to the MIPI-CSI data ID. What if one sensor sends "binary"
> >> blob with MIPI-CSI "User Define Data 1" and the other with "User Define
> >> Data 2" ?
> > 
> > My gut feeling is that the information should be retrieved from the sensor
> > driver. This is all pretty vendor-specific, and adding explicit support
> > for such sensors to each bridge driver wouldn't be very clean. Could the
> > bridge
> 
> We have many standard pixel codes in include/linux/v4l2-mediabus.h, yet each
> bridge driver supports only a subset of them. I wouldn't expect a sudden
> need for all existing bridge drivers to support some strange interleaved
> image formats.

Those media bus codes are standard, so implementing explicit support for them 
in bridge drivers is fine with me. What I want to avoid is adding explicit 
support for sensor-specific formats to bridges. There should be no dependency 
between the bridge and the sensor.

> > query the sensor using a subdev operation ?
> 
> There is also a MIPI-CSI2 receiver in between that needs to be configured.
> I.e. it must know that it processes the User Defined Data 1, which implies
> certain pixel alignment, etc. So far a media bus pixel codes have been
> a base information to handle such things.

For CSI user-defined data types, I still think that the information required 
to configure the CSI receiver should come from the sensor. Only the sensor 
knows what user-defined data type it will generate.

> >> Maybe we could create e.g. V4L2_MBUS_FMT_USER?, for each MIPI-CSI User
> >> Defined data identifier, but as I remember it was decided not to map
> >> MIPI-CSI data codes directly onto media bus pixel codes.
> > 
> > Would setting the format directly on the sensor subdev be an option ?
> 
> Do you mean setting a MIPI-CSI2 format ?

No, I mean setting the media bus code on the sensor output pad to a vendor-
specific value.

> It should work as long as the bridge driver can identify media bus code
> given a fourcc. I can't recall situation where a reverse lookup is
> necessary, i.e. struct v4l2_mbus_framefmt::code -> fourcc. This would
> fail since e.g. JPEG and YUV/JPEG would both correspond to User 1 format.

-- 
Regards,

Laurent Pinchart