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. -- Regards, Laurent Pinchart
