On 10.11.21 г. 11:01 ч., Tomi Valkeinen wrote:
On 10/11/2021 10:29, Ivaylo Dimitrov wrote:
Hi,
On 9.11.21 г. 11:22 ч., Tomi Valkeinen wrote:
Hi,
On 08/11/2021 19:43, Ivaylo Dimitrov wrote:
Sorry, mail was sent to the old Tomi's address.
On 8.11.21 г. 19:05 ч., Ivaylo Dimitrov wrote:
Hi,
Currently omapdrm supports TILER rotation only, which excludes
omap3 and earlier SoCs. I have the hardware (N900/N950), time and
will to implement VRFB rotation support in omapdrm driver, however,
I'll appreciate some hints. Or, if there is already something
ready, please point me to it so I can take it from where it is.
Besides partially reverting
517a8a9564c0dea98e6d4e2c7f0fe4cbb9b8c9ba and copying VRFB code from
omapfb, is there anything else I shall take in consideration? Or,
VRFB driver should not be a part of omapdrm, but a standalone one?
We already have DMM driver in the omapdrm module, and I think VRFB
fits along just fine. I don't think there ever has been any other
users for VRFB than DSS, and as it's such an old IP, I don't think
there ever will.
Ok, I guess if a need appears, it can always be moved out of omapdrm.
The same applies to DMM/TILER code I guess.
Yes.
I don't have any particular hints in mind.
Do you have omap4/5 so you can test that DMM still works after your
changes?
So, first, a few clarifications about DMM/TILER. There are two somewhat
separate things. I'm not sure what are the exactly correct words for
these, but these are the terms I've used:
- DMM (sometimes called wrongly TILER 1D), which acts as a basic iommu.
It doesn't do rotation, just mapping scattered pages to a contiguous
memory view.
- TILER (or TILER 2D) which on top of the above, adds support for rotation.
Thanks for the clarification, I'll try to stick to those.
Yes, I have motorola droid4 (4430/sgx540) to test with. Which brings
another issue on the table - I was not able to find a way to allocate
a TILER dma_buf. The only way seems to be by using omap_bo_xxx
functions, which is a 'vendor' API. Do I miss something or omapdrm is
lacks
Yes, omap_bo_xxx is omap specific API. But I don't understand your
question about omapdrm. omap_bo functions use omapdrm's API. The
userspace can skip libdrm and just call the ioctls directly if they so
want.
omap_bo functions/ioctls do, but if we try to use GBM dma_buf API
(gbm_bo_create() and friends), we cannot allocate anything but CMA
memory which omapdrm refuses to rotate, IIUC. Well at least I was not
able to make framebuffer rotate with GBM allocated BO.
The terms I use:
dma_buf - BO that is allocated using GBM API and seems to end up here:
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/omapdrm/omap_gem.c#L1300.
Seems it cannot go through the TILER.
omap_bo: BO that is allocated using omap_bo functions. IIUC this is
basically a dumb buffer, but it can be allocated to be accesses through
TILER by passing the appropriate flags to omap_bo_new().
functionality? Also, is there any particular reason why TILER is not
enabled by default for dma_buf BOs? Is it a limited resource (like,
there is a finite number of BOs that can use TILER) or there is some
Yes, TILER is a limited resource, there's a maximum size for the
currently mapped memory. Going through TILER is also slower, and while
for 0 degree rotation the diff probably isn't much, it's still there.
Yeah, so we should go through TILER only when needed. The same as VRFB.
Also TILER is not really quite supported, as I never got it working with
all the YUV modes, and also because there's a HW issue, which may cause
the device to lock up in some rare cases. And last, TILER creates such a
memory layout that it's not possible to share it safely with dmabuf, as
dmabuf lacks the features to properly describe the layout.
All that said, I think TILER should mostly work in upstream.
But, only from omap_bo BOs
However, DMM is supported, and used by default. If you allocate a dumb
buffer, it uses DMM by default.
not for dma_buf BOs though. Not really an issue as on omap3 there is no
DMM so we must use CMA either ways.
other reason. Also, is it possible to 'migrate' non-TILER BO to a
TILER one? The same issue will arise with VRFB (with its 12 contexts
on omap3) as well.
No, not possible to migrate.
So, in short:
- omap3: VRFB driver to be added to omapdrm.
- omap3/omap4/omap5: dma_buf lacks TILER/VRFB support
Can you elaborate on what's missing?
GBM BOs (which I call dma_buf BOs) lack TILER support
Adding VRFB should be trivial, but I am more concerned about how to
rotate dma_buf buffers. I imagine something like - on setting the
plane "rotate" property, migrate physical address from 'normal' CMA
memory to a TILER/VRFB one. Is that possible? What if we already have
that bo mmap-ed? What if SGX MMU is already set up to access the
memory? Or, is it possible to use TILER for read access, the same way
VRFB can be set-up, so instead of writing through TILER/VRFB, DSS to
be set-up to read FB memory through TILER/VRFB thus avoiding the need
to migrate SG and/or page tables?
I have to say I don't quite remember how VRFB works.
it has 12 'contexts' that can represent up to that number of 'images' in
memory with rotated views
But for TILER, we
have to specifically allocate a TILER buffer. And then everyone else
uses TILER 0 degree view, but DSS can use 0/90/180/270 view when showing
it on the display.
oh, so in theory omapdrm should be able to show dma_buf BOs rotated? We
only lack a way to allocate TILER GBM BO, right?
I ported xf86-video-omap to use GBM API instead of omap_bo API and it
works fine in native orientation. However, when it tries to set
'rotated' property to framebuffer, it receives an error. Should I trace
to see why it fails in the kernel or this is not supported?
But I think the case is the same for VRFB too: if you want to use VRFB,
all access has to go through VRFB, as the pixels are written to memory
in a special way.
Yes, I think you are right.
Sorry for asking so much questions but I want to have a clear picture on
what is supposed to work and what is missing.
Thanks,
Ivo
