Hey all,
Last year I bought an OMAP5UEVM with the aim of assisting in the development of the Pyra. It's currently hooked up to a HDMI display but I thought that would be enough to get rotation working for all output types. After taking the time to flick through the entirety of the TRM, compiling uboot and the kernel, playing around with the configuration options and reading some of the source code I'm finally up to a stage where I can consider myself lost.
My background is an application developer in Java. I learned a little bit of C when I was younger but the rapid development requirements of business meant Java was better suited. I've normally developed on a Linux machine so know my way around as a user. Looking at the source code has been a big jump. A challenge that I'm hoping I can meet.
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'.
Is it the individual planes that should be rotated? Is it a problem that a viewport is not hooked up to omap_dmm_tiler?
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.
I have tried doing some searching on the pyra mailing list. https://www.pyra-handheld.com/pipermail/kernel/2016-June/000945.html is a nice discussion but doesn't point me at anything.
https://www.pyra-handheld.com/pipermail/kernel/2018-February/002328.html talks about using tiler for fbdev but that only gets us a 2D context?
I'm currently sitting on the 4.9 branch of the Letux kernel. Is that the correct one I should be aiming for a stable fix of the rotation before moving it to a more recent release?
Does anyone have resources to text or video that would help me better understand the subsystems that are involved to get TILER working?
The toughest question would be is there something that can be pointed to that would help me fix/implement a rotating display so that I could ultimately provide a patch? I don't know if that is going to come in the form of a branch or different repo. I understand if it was easy then this problem probably wouldn't exist.
Hopefully I'm asking in the right places. Pyra because that is the reason I am involved and Letux because that is the repository I am looking at.
Hi Russell,
Am 18.06.2019 um 06:38 schrieb Russell Mullens russellmullens@gmail.com:
Hey all,
Last year I bought an OMAP5UEVM with the aim of assisting in the development of the Pyra.
Fine! Welcome to the OMAP5 world :)
It's currently hooked up to a HDMI display but I thought that would be enough to get rotation working for all output types. After taking the time to flick through the entirety of the TRM, compiling uboot and the kernel, playing around with the configuration options and reading some of the source code I'm finally up to a stage where I can consider myself lost.
My background is an application developer in Java. I learned a little bit of C when I was younger but the rapid development requirements of business meant Java was better suited. I've normally developed on a Linux machine so know my way around as a user. Looking at the source code has been a big jump. A challenge that I'm hoping I can meet.
Well, the Tiler is amongst the most difficult topics to start with...
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".
We have working Tiler code for the Pyra but it is not mature to be included in kernel.org source trees. It is here:
http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/t...
Is it the individual planes that should be rotated? Is it a problem that a viewport is not hooked up to omap_dmm_tiler?
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.
I have tried doing some searching on the pyra mailing list. https://www.pyra-handheld.com/pipermail/kernel/2016-June/000945.html is a nice discussion but doesn't point me at anything.
https://www.pyra-handheld.com/pipermail/kernel/2018-February/002328.html talks about using tiler for fbdev but that only gets us a 2D context?
I'm currently sitting on the 4.9 branch of the Letux kernel. Is that the correct one I should be aiming for a stable fix of the rotation before moving it to a more recent release?
Try letux kernel 4.19.46 or later where rotation works. At least for the Pyra LCD panel in framebuffer mode (and X11). I also test it from time to time in newer kernels, e.g. letux-5.2-rc4.
Does anyone have resources to text or video that would help me better understand the subsystems that are involved to get TILER working?
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.
The toughest question would be is there something that can be pointed to that would help me fix/implement a rotating display so that I could ultimately provide a patch? I don't know if that is going to come in the form of a branch or different repo. I understand if it was easy then this problem probably wouldn't exist.
Hopefully I'm asking in the right places. Pyra because that is the reason I am involved and Letux because that is the repository I am looking at.
Yes, I think we are those who have invested most time into the OMAP5 tiler code.
So welcome again, but we need to define your problem with the existing tiler code first.
BR and thanks, Nikolaus
PS: there is an (almost up-to date) issue list where you can look for topics which need help: http://projects.goldelico.com/p/gta04-kernel/issues/
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
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.