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
