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
- 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.
- 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.