All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Krzysztof Hałasa" <khalasa@piap.pl>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Steve Longerbeam <slongerbeam@gmail.com>,
	 Mauro Carvalho Chehab <mchehab@kernel.org>,
	 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Shawn Guo <shawnguo@kernel.org>,
	 Sascha Hauer <s.hauer@pengutronix.de>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	 Fabio Estevam <festevam@gmail.com>,
	 NXP Linux Team <linux-imx@nxp.com>,
	linux-kernel@vger.kernel.org,  linux-media@vger.kernel.org,
	linux-staging@lists.linux.dev,
	 linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] i.MX6: Support 16-bit BT.1120 video input
Date: Wed, 06 Oct 2021 12:52:57 +0200	[thread overview]
Message-ID: <m37deqmnli.fsf@t19.piap.pl> (raw)
In-Reply-To: <568f79774cc148c58b9045da7b94b4e9e500810b.camel@pengutronix.de> (Philipp Zabel's message of "Wed, 06 Oct 2021 11:36:47 +0200")

Hi Philipp,

Philipp Zabel <p.zabel@pengutronix.de> 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?

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. 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.

Ok, the DQRM (37.4.3.2.1) states that for parallel YUV the output from
CSI is always YUV444.



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.
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 :-)
-- 
Krzysztof "Chris" Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa

WARNING: multiple messages have this Message-ID (diff)
From: "Krzysztof Hałasa" <khalasa@piap.pl>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Steve Longerbeam <slongerbeam@gmail.com>,
	 Mauro Carvalho Chehab <mchehab@kernel.org>,
	 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Shawn Guo <shawnguo@kernel.org>,
	 Sascha Hauer <s.hauer@pengutronix.de>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	 Fabio Estevam <festevam@gmail.com>,
	 NXP Linux Team <linux-imx@nxp.com>,
	linux-kernel@vger.kernel.org,  linux-media@vger.kernel.org,
	linux-staging@lists.linux.dev,
	 linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] i.MX6: Support 16-bit BT.1120 video input
Date: Wed, 06 Oct 2021 12:52:57 +0200	[thread overview]
Message-ID: <m37deqmnli.fsf@t19.piap.pl> (raw)
In-Reply-To: <568f79774cc148c58b9045da7b94b4e9e500810b.camel@pengutronix.de> (Philipp Zabel's message of "Wed, 06 Oct 2021 11:36:47 +0200")

Hi Philipp,

Philipp Zabel <p.zabel@pengutronix.de> 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?

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. 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.

Ok, the DQRM (37.4.3.2.1) states that for parallel YUV the output from
CSI is always YUV444.



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.
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 :-)
-- 
Krzysztof "Chris" Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa

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

  reply	other threads:[~2021-10-06 10:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-06  6:13 [PATCH] i.MX6: Support 16-bit BT.1120 video input Krzysztof Hałasa
2021-10-06  6:13 ` Krzysztof Hałasa
2021-10-06  8:45 ` Dan Carpenter
2021-10-06  8:45   ` Dan Carpenter
2021-10-06  9:36 ` Philipp Zabel
2021-10-06  9:36   ` Philipp Zabel
2021-10-06 10:52   ` Krzysztof Hałasa [this message]
2021-10-06 10:52     ` Krzysztof Hałasa
2021-10-08 11:53     ` Philipp Zabel
2021-10-08 11:53       ` Philipp Zabel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m37deqmnli.fsf@t19.piap.pl \
    --to=khalasa@piap.pl \
    --cc=festevam@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=mchehab@kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=slongerbeam@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.