Hi Laurent, On Fri, Nov 30, 2018 at 01:09:37AM +0200, Laurent Pinchart wrote: > Hi Sakari, > > > On Friday, 9 November 2018 12:09:54 EET Sakari Ailus wrote: > > On Wed, Nov 07, 2018 at 12:16:47PM +0800, Bing Bu Cao wrote: > > > On 11/01/2018 08:03 PM, Sakari Ailus wrote: > > >> On Mon, Oct 29, 2018 at 03:22:54PM -0700, Yong Zhi wrote: > > [snip] > > > >>> ImgU media topology print: > > >>> > > >>> # media-ctl -d /dev/media0 -p > > >>> Media controller API version 4.19.0 > > >>> > > >>> Media device information > > >>> ------------------------ > > >>> driver ipu3-imgu > > >>> model ipu3-imgu > > >>> serial > > >>> bus info PCI:0000:00:05.0 > > >>> hw revision 0x80862015 > > >>> driver version 4.19.0 > > >>> > > >>> Device topology > > >>> - entity 1: ipu3-imgu 0 (5 pads, 5 links) > > >>> type V4L2 subdev subtype Unknown flags 0 > > >>> device node name /dev/v4l-subdev0 > > >>> pad0: Sink > > >>> [fmt:UYVY8_2X8/1920x1080 field:none colorspace:unknown > > >> > > >> This doesn't seem right. Which formats can be enumerated from the pad? > > > > Looking at the code, the OUTPUT video nodes have 10-bit GRBG (or a variant) > > format whereas the CAPTURE video nodes always have NV12. Can you confirm? > > > > If the OUTPUT video node format selection has no effect on the rest of the > > pipeline (device capabilities, which processing blocks are in use, CAPTURE > > video nodes formats etc.), I think you could simply use the FIXED media bus > > code for each pad. That would actually make sense: this device always works > > from memory to memory, and thus does not really have a pixel data bus > > external to the device which is what the media bus codes really are for. > > Isn't the Bayer variant useful information to configure debayering ? I would > expect it to be passed through the format on pad 0. That's already configured on the video node. The FIXED media bus code is intended for links where there's nothing to configure --- which is the case here. -- Regards, Sakari Ailus sakari.ailus@xxxxxxxxxxxxxxx
