Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 15 Feb 2021 09:06:01 +0000
To:     =?utf-8?Q?Christian_K=C3=B6nig?= <christian.koenig@amd.com>
From:   Simon Ser <contact@emersion.fr>
Cc:     linux-media <linux-media@vger.kernel.org>,
        dri-devel <dri-devel@lists.freedesktop.org>,
        linaro-mm-sig@lists.linaro.org,
        lkml <linux-kernel@vger.kernel.org>,
        "Sharma, Shashank" <Shashank.Sharma@amd.com>
Reply-To: Simon Ser <contact@emersion.fr>
Subject: Re: DMA-buf and uncached system memory
Message-ID: <GUuZYSQk2hxgykDhSxfB2GWo47lQlVrKBtWMwQUG7Ar2GAag5WQDxBI0zq6nDTooPBzTktyRpnu25Ju1UKE3FYD9yHbkNMAHcmSI96hoJhA=@emersion.fr>
In-Reply-To: <91ff0bbb-ea3a-2663-3453-dea96ccd6dd8@amd.com>
References: <91ff0bbb-ea3a-2663-3453-dea96ccd6dd8@amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Monday, February 15th, 2021 at 9:58 AM, Christian K=C3=B6nig <christian.=
koenig@amd.com> wrote:

> we are currently working an Freesync and direct scan out from system
> memory on AMD APUs in A+A laptops.
>
> On problem we stumbled over is that our display hardware needs to scan
> out from uncached system memory and we currently don't have a way to
> communicate that through DMA-buf.
>
> For our specific use case at hand we are going to implement something
> driver specific, but the question is should we have something more
> generic for this?
>
> After all the system memory access pattern is a PCIe extension and as
> such something generic.

Intel also needs uncached system memory if I'm not mistaken?

Where are the buffers allocated? If GBM, then it needs to allocate memory t=
hat
can be scanned out if the USE_SCANOUT flag is set or if a scanout-capable
modifier is picked.

If this is about communicating buffer constraints between different compone=
nts
of the stack, there were a few proposals about it. The most recent one is [=
1].

Simon

[1]: https://xdc2020.x.org/event/9/contributions/615/