[Letux-kernel] Looking for guidance/hints for fixing/implementing/understanding Tiler

[Matthijs van Duin]

> > It's currently hooked up to a HDMI display but I thought that would
> > be enough to get rotation working for all output types.

It should and I've used the uEVM for most development and testing, 
although we've had a weird issue specific to DSI.  I don't really 
remember the details, other than that I fixed it by reverting mainline 
commit 865afb11949e "drm/fb-helper: reject any changes to the fbdev"


> > I hope that I'm correct that Tiler code is located in 
> > /drivers/gpu/drm/omapdrm. What I'm not sure of is where I need to be 
> > fixing the 'problem'.
>
> The question is what you consider as "the problem".

My patches definitely still have plenty of open issues, some minor while 
others make it impossible to mainline them in their current form.

(For an overview of my patches see 
https://www.pyra-handheld.com/pipermail/kernel/2017-March/001747.html )

patch/tiler-memtype:

Instead of letting userspace control the memory type directly, it may be 
nicer to allow userspace to promise constraints on its usage (at the 
very least "will never read from userspace mapping", but it may be nice 
to add "will never write to userspace mapping" for symmetry, which if 
combined imply that no userspace mapping is needed) and select optimal 
memory type based on those constraints (+ whether or not the platform 
suffers from the tiler/cortex-a15 erratum).

patch/tiler-fast:

To avoid the performance penalty from frequent page faults, I forcibly 
pin tiled buffers as soon as they're allocated.  This won't be 
acceptable upstream since the page fault mechanism, while slow as fuck, 
was used because of issues with running out of TILER (or technically 
PAT) memory space, probably in part because tiled ("2d") and non-tiled 
("1d") competed for the same space prior to omap5.  It may be desirable 
to see if better memory/performance trade-offs are possible than my 
aggressive pin-on-allocate strategy, or at the very least it needs to be 
controlled by a module parameter (with the current mainline behaviour as 
default).

patch/tiler-buf-fbdev:

This one is a just a big mess.  Forcing the legacy fbdev to be 8192 
pixels wide to make it physically contiguous in tiler memory is 
completely excessive and unnecessary, and was just a quick hack to get 
it working asap.  The proper fix would be to properly implement kmap for 
tiled buffers (part of the dma-buf API and currently horribly broken) 
and use that to map the buffer contiguously into kernel virtual memory.

For mainline it will also need to be optional, since other targets may 
be not care about fbdev rotation and want to avoid wasting tiler memory.  
An interesting idea I had was that it should be possible to initially 
allocate framebuffers in non-tiled memory and move them to tiled memory 
the first time a rotated view is requested, but this would add a lot of 
complexity and it would still require the pitch (in bytes) to be rounded 
up to the page size (since this can't be changed later) hence it 
wouldn't be zero-cost to those who don't care about rotation.

patch/tiler-fbdev:

There is now a mainline mechanism to allow a panel to specify its 
natural orientation, and we should move to using that instead of a 
module parameter (if we haven't already).  Last time I worked on this 
mainline was still lacking support for sideways rotations, so that part 
of the patch should move to mainline unless there's some reason the 
approach I used isn't acceptable for mainline (in which case any 
objections will need to be addressed).

other issues:

dma-buf export of tiled buffers is currently broken.  I've started work 
on that in the past, but I don't remember how far I got.  I'd need to 
dig around in my work-in-progress.


> > I think my problem is that I don't understand the linux frameworks 
> > around either memory allocation or display subsystems 
> > (GEM/DRI/DRM/other?) and I don't know where to go looking to start 
> > understanding them. I'm not even sure if it could be a DMA issue 
> > that I should be looking at.

So, to clarify: rotation using TILER works in mainline, but

1. the performance of userspace mappings of tiled buffers is abysmal, in 
part due to generating excessive page faults (only two pages are mapped 
to userspace at any given time) and in part due to using an erratum on 
omap5 and vayu (dra7xx/am57xx) resulting from the way the Cortex-A15 
interacts with TILER, for which the workaround in mainline is far more 
detrimental to performance than it needs to be.

2. rotation isn't supported for the legacy fbdev.  (as mentioned above, 
some mainline support has been introduced at some point, but this 
doesn't suffice yet)


> Well, the main resource is Matthijs' knowledge. Unfortunately he does 
> not have much time to discuss anything and I am not even sure if he 
> follows these lists.

I try to, and sharing what I know is the least I can do.


Matthijs