linux-kernel - Re: [PATCH] media: imx: prpencvf: enable double write reduction

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1500880863.2391.13.camel@pengutronix.de>
Date:   Mon, 24 Jul 2017 09:21:03 +0200
From:   Philipp Zabel <p.zabel@...gutronix.de>
To:     Steve Longerbeam <slongerbeam@...il.com>
Cc:     Mauro Carvalho Chehab <mchehab@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-media@...r.kernel.org, devel@...verdev.osuosl.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] media: imx: prpencvf: enable double write reduction

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