The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Philipp Zabel <p.zabel@pengutronix.de>
To: Steve Longerbeam <slongerbeam@gmail.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-media@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] media: imx: prpencvf: enable double write reduction
Date: Mon, 24 Jul 2017 09:21:03 +0200	[thread overview]
Message-ID: <1500880863.2391.13.camel@pengutronix.de> (raw)
In-Reply-To: <a3299b77-917a-f946-d9fc-33efcf3f2721@gmail.com>

Hi Steve,

On Sat, 2017-07-22 at 15:04 -0700, Steve Longerbeam wrote:
> Hi Philipp,
> 
> This is the same as your patch to CSI, applied to ic-prpencvf.
> 
> I'm not really sure what this cpmem bit is doing. The U/V planes
> in memory are already subsampled by 2 in both width and height.
> This must be referring to what the IDMAC is transferring on the bus,

Right, the IDMAC is just receiving AYUV 4:4:4 pixels from the FIFO, the
CPMEM settings decide how they are written to the AXI bus. If this bit
is not enabled, all pixels are written fully, even though chroma samples
of even and odd lines end up in the same place for 4:2:0 chroma
subsampled output formats. If the bit is set, the chroma writes for odd
lines are skipped, so there is no overdraw.

Unfortunately this does not work for reading, unless there is a line
buffer (which only the VDIC has), because otherwise odd lines end up
without chroma information. This one of the reasons that YUY2 is the
most memory efficient format to read, not NV12.

> but why would it place duplicate U/V samples on the bus in the first
> place?

Don't ask me why the hardware was designed this way :)
I see no reason to ever disable this bit for YUV420 or NV12 write
channels.

> Anyway, thanks for the heads-up on this.

regards
Philipp

  reply	other threads:[~2017-07-24  7:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-22 21:21 [PATCH] media: imx: prpencvf: enable double write reduction Steve Longerbeam
2017-07-22 22:04 ` Steve Longerbeam
2017-07-24  7:21   ` Philipp Zabel [this message]
2017-07-24  7:21 ` 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=1500880863.2391.13.camel@pengutronix.de \
    --to=p.zabel@pengutronix.de \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox