Re: [PATCH] i.MX6: Support 16-bit BT.1120 video input

Hi Krzysztof,

On Wed, 2021-10-06 at 12:52 +0200, Krzysztof Hałasa wrote:

Hi Philipp,

Philipp Zabel [off-list ref] writes:

quoted

quoted

+ * - 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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel