linux-kernel - Re: [PATCH 3/3] drm: omapdrm: Do no allocate non-scanout GEMs through DMM/TILER

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: <9ba1a8a3-fd3e-7879-8f47-ec991888d5f7@gmail.com>
Date:   Fri, 2 Sep 2022 17:13:34 +0300
From:   Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>
To:     Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
        Yongqin Liu <yongqin.liu@...aro.org>, Andrew Davis <afd@...com>
Cc:     "Bajjuri, Praneeth" <praneeth@...com>, airlied@...ux.ie,
        merlijn@...zup.org, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, tony@...mide.com,
        linux-omap@...r.kernel.org, Sumit Semwal <sumit.semwal@...aro.org>
Subject: Re: [PATCH 3/3] drm: omapdrm: Do no allocate non-scanout GEMs through
 DMM/TILER



On 30.08.22 г. 21:23 ч., Tomi Valkeinen wrote:
> On 30/08/2022 21:08, Ivaylo Dimitrov wrote:
> 
>>>>          flags &= ~OMAP_BO_TILED_MASK;
>>>>          flags |= 0x00000008;
>>>>          flags |= OMAP_BO_WC;
>>>>
>>>>          bo = omap_bo_new(dev, size, flags);
>>>>
>>>> As you can see we use 0x00000008 (OMAP_BO_MEM_CONTIG) unconditionally.
>>>> This was a hack added since even non-scanout buffers sometimes need
>>>> to be contiguous (video decoder surfaces), but we had no way back
>>
>> Hmm, why would video decoder need linear memory? No MMU?
> 
> Not sure about this case, but many/most IPs don't have MMU. E.g. CSI-2 
> or parallel capture.
> 
>>>> If you tell me what the code should look like, I can rebuild the
>>>> lib and post a copy.
>>>>
>>>> Long term, I'd like to start using DMA-BUF Heaps for CMA memory
>>>> allocations in gralloc and elsewhere, then drop out the DMM/TILER
>>>> support from OMAPDRM, since it never really belonged there in
>>>> the first place (being a IOMMU unrelated to the display/GPU).
>>>>
>>
>> Umm, how will we rotate scanout buffers then?
> 
> Didn't we discuss this earlier in this thread. Or some other thread. 
> Related to VRFB... I'm not sure =).
> 

Yeah, I think so. VRFB is still on my list though, along with TE support 
for droid4 :).

> Anyway, neither VRFB nor DMM/TILER are part of the DSS. They're part of 
> the memory subsystem. They can be used without DSS being in the setup. 
> Thus the code for VRFB and DMM/TILER should not be in the DSS driver.
>

Makes sense.

> The DSS driver should still, of course, support DMM/TILER (and maybe 
> VRFB some day) in the "use" sense, i.e. so that DSS can use the 
> DMM/TILER provided from another driver.
> 

Ah, this is what I was missing all the time, for some reason I was left 
with the impression that userland will have to know about those details. 
Now it is clear.

> But how exactly that's to be implemented, I don't know.
> 

Seems Andrew has an idea.

Ivo

>   Tomi