Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <91ff0bbb-ea3a-2663-3453-dea96ccd6dd8@amd.com> <YCuPhOT4GhY3RR/6@phenom.ffwll.local>
 <9178e19f5c0e141772b61b759abaa0d176f902b6.camel@ndufresne.ca>
In-Reply-To: <9178e19f5c0e141772b61b759abaa0d176f902b6.camel@ndufresne.ca>
From:   Daniel Stone <daniel@fooishbar.org>
Date:   Thu, 23 Jun 2022 00:34:58 +0100
Message-ID: <CAPj87rPYQNkgVEdHECQcHcYe2nCpgF3RYQKk_=wwhvJSxwHXCg@mail.gmail.com>
Subject: Re: DMA-buf and uncached system memory
To:     Nicolas Dufresne <nicolas@ndufresne.ca>
Cc:     Daniel Vetter <daniel@ffwll.ch>,
        =?UTF-8?Q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>,
        "Sharma, Shashank" <Shashank.Sharma@amd.com>,
        lkml <linux-kernel@vger.kernel.org>,
        dri-devel <dri-devel@lists.freedesktop.org>,
        linaro-mm-sig@lists.linaro.org,
        Sumit Semwal <sumit.semwal@linaro.org>,
        linux-media <linux-media@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi Nicolas,

On Wed, 22 Jun 2022 at 20:39, Nicolas Dufresne <nicolas@ndufresne.ca> wrote=
:
> Le mardi 16 f=C3=A9vrier 2021 =C3=A0 10:25 +0100, Daniel Vetter a =C3=A9c=
rit :
> > So I think if AMD also guarantees to drop clean cachelines just do the
> > same thing we do right now for intel integrated + discrete amd, but in
> > reserve. It's fragile, but it does work.
>
> Sorry to disrupt, but if you pass V4L2 vmalloc data to Intel display driv=
er, you
> also get nice dirt on the screen. If you have a UVC webcam that produces =
a pixel
> format compatible with your display, you can reproduce the issue quite ea=
sily
> with:
>
>   gst-launch-1.0 v4l2src device=3D/dev/video0 ! kmssink
>
> p.s. some frame-rate are less likely to exhibit the issue, make sure you =
create
> movement to see it.

Right, this is because the UVC data in a vmalloc() area is not
necessarily flushed from the CPU cache, and the importer expects it
will be.

> The only solution I could think of (not implemented) was to detect in the
> attach() call what the importers can do (with dev->coherent_dma_mask if I
> recall), and otherwise flush the cache immediately and start flushing the=
 cache
> from now on signalling it for DQBUF (in vb2 workqueue or dqbuf ioctl, I d=
on't
> have an idea yet). I bet this idea is inapplicable to were you have fence=
s, we
> don't have that in v4l2.
>
> This idea was hinted by Robert Becket (now in CC), but perhaps I picked i=
t up
> wrong, explaining it wrong, etc. I'm no expert, just noticed there wasn't=
 really
> a good plan for that, so one needs to make one up. I'm not aware oh an im=
porter
> could know how the memory was allocated by the exporter, and worst, how a=
n
> importer could figure-out that the export is going to produce buffer with=
 hot
> CPU cache (UVC driver does memcpy from USB chunks of variable size to pro=
duce a
> fixed size image).

This is exactly what Christian was saying above.

Cheers,
Daniel