On Thu, Jun 20, 2019 at 3:49 PM Matthijs van Duin <matthijsvanduin@gmail.com> wrote:
> > 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

Perfect. Thanks to both Matthijs and Nikolaus  for all the information. Has definitely given me a lot to go back over and review.
I was stuck on 4.19.24 for a long time because I didn't want the base to be moving underneath me whilst I tried to get a fundamental understanding. I have just updated but haven't had a chance to push the new build to the device.

Sorry for not signing up to the mailing lists properly when I first sent this message. It has been corrected.

I'll go back into my hole and see what I can dig up.

--
Russell Mullens