linux-kernel - Re: [PATCH] drm/sun4i: mixer: Enable register value caching

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] [day] [month] [year] [list]

Message-ID: <20200727133846.kgrnmsocy4pel6cn@gilmour.lan>
Date:   Mon, 27 Jul 2020 15:38:46 +0200
From:   Maxime Ripard <maxime@...no.tech>
To:     Jernej Skrabec <jernej.skrabec@...l.net>
Cc:     wens@...e.org, airlied@...ux.ie, daniel@...ll.ch,
        dri-devel@...ts.freedesktop.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-sunxi@...glegroups.com
Subject: Re: [PATCH] drm/sun4i: mixer: Enable register value caching

Hi,

On Fri, Jul 24, 2020 at 10:35:49PM +0200, Jernej Skrabec wrote:
> It was discovered in the past by Ondrej Jirman that mixer register read
> may occasionally return wrong value, most likely zero. It turns out
> that all mixer units are affected by this issue. This becomes especially
> obvious with applications like video player. After a few minutes of a
> playback visual glitches appeared but not always in the same way. After
> register inspection it was clear that some bits are not set even when
> they should be.

There was a similar issue on the earlier backend stuff, and it turned
out to be because we were accessing registers while the registers
"commit" wasn't completed yet.

It looks that in the DE2, it's the register GLB_DBUFFER that controls it
(offset 0x08). It would be worth looking into whether it happens only
when the bit 0 is still high.

I ended up writing a small program using devmem back then to write a
known value in known to be faulty register and checking it in a tight
loop (and then with a poll on that bit) to see if that fixed it or not.

> Best solution would be to shuffle the code a bit to avoid
> read-modify-write operations and use only register writes. However,
> quicker solution is to enable caching support in regmap which is also
> used here. Such fix is also easier to backport in stable kernels.

It only partially fixes the issue though. None of the volatile registers
would be covered, and this includes GLB_CTL too at least.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)