Hi Krzysztof, On Wed, 2021-10-06 at 12:52 +0200, Krzysztof Hałasa wrote: > Hi Philipp, > > Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> writes: > > > > + * - BT.656 and BT.1120 (8/10-bit YUV422) data can always be processed > > > + * on-the-fly (converted to YUV420) > > > > This comment seems misleading. The CSI converts to YUV 4:4:4 internally. > > Well... this is surprising. You mean "on the internal bus", don't you? Yes, anything apart from the bayer/generic data modes, internally everything is converted into 32-bit YUVA/RGBA pixels (according to the Reference Manual, 37.4.2.3 FCW & FCR). That is represented by the MEDIA_BUS_FMT_AYUV8_1X32 media bus format at the CSI source pads. > Please correct me if the following is wrong: > > I always though that the "on-the-fly processing", in case of YUV422, > means in practice I can get YUV420 out of the IPU, without a need to do > e.g. NEON conversion. That is done in the IDMAC, which can write any supported YUV format from the internal YUV pixels (if not in bayer/generic data mode). > I know I can get the original YUV422 as well, > using the "generic data" mode, but it's incompatible with the CODA H.264 > encoder. You should also be able to store the YUV formatted pixels as NV12, NV16, YUYV, etc. > Ok, the DQRM (37.4.3.2.1) states that for parallel YUV the output from > CSI is always YUV444. Ack. > Then 37.4.3.9 says that the only YUV422 way is to use 16-bit "generic > data". This doesn't seem to be very true, however I'm not exactly sure > about the "on-the-fly" thing. I think that statement is limited to the parallel 16-bit interface in hsync/vsync mode, whereas in bt.656 / bt.1120 mode the interface operates as if the two components were clocked in as two separate 8-bit (or 10-bit) values. > The fact is the patch works. > Also, the CSIx_SENS_DATA_FORMAT field in IPUx_CSIx_SENS_CONF register > shows YUV422 YUYV and UYVY input data formats, clearly separate from > "Bayer of Generic data". > > DQIEC, 4.12.10.1, isn't very clear either: > 8) YCbCr 20-bit (10-bit Y + 10-bit U/V) is supported with BT.1120 only > 7) YCbCr 16-bit is supported under the same conditions as 8) > 6) YCbCr 16-bit (= YUV422) is also supported as "generic-data" > (no on-the-fly processing). This seems to imply 8) and 7) are > supported WITH o-t-f-p (and obviously I have tested it, 16-bit only). > > I think I will just remove the comment :-) That sounds good to me. regards Philipp
