Hey all,
While browsing the Pyra wiki I read with surprise that it used an external image rotation chip rather than using TILER. When I inquired about it on IRC one reason mentioned was "it was slow in tests", which seemed odd to me.
I don't have any omap-based board yet, but I had played a bit with TILER on a dm814x-based board I worked on for a project. I ran a quick benchmark in a baremetal environment, comparing a NEON-based fill of a 1920 x 1080 pixel (@ 32bpp) framebuffer via TILER versus directly in DDR3. The framebuffers were mapped as normal uncacheable memory.
6.9 ms -- no TILER, stride 7680 (contiguous) and 8192 8.6 ms -- TILER views 0-3, stride 32768 10.5 ms -- TILER views 4-7, stride 16384
So TILER did decrease performance, but only by 25% for views 0-3. Other initiators would probably see even less difference (if any at all) since only the cortex-A has a dedicated path to ram. Also, replacing the NEON-based fill by a fairly dumb wordwise fill increased time to 55.5 ms with or without TILER.
Of course the DM814x really isn't an OMAP5, and the test was rather simplistic, but it left me wondering what test was done exactly that exhibited poor performance when used with TILER.
I also wonder where the other claimed negatives in https://pyra-handheld.com/boards/threads/.74058/ came from, since TILER in fact works quite transparently. The only thing unusual about its format is the large stride, but I don't immediately see why it would be a problem, and if necessary or desired it can be reduced to 8192 using the MMU when a buffer is mapped into userspace.
So, EvilDragon asked me to forward these questions to this list, and here I am :-)
Matthijs
On 20/06/16 05:07, Matthijs van Duin wrote:
Hey all,
While browsing the Pyra wiki I read with surprise that it used an external image rotation chip rather than using TILER. When I inquired about it on IRC one reason mentioned was "it was slow in tests", which seemed odd to me.
TILER 1D works fine, but TILER 2D doesn't. It is unusably slow for CPU at the moment.
Also, what people usually want is transparent (to the SW) whole display rotation. TILER rotates the contents of a single plane, so the SW needs to deal with everything else involved. On a SoC with only a single full screen plane (DM814x?) it's probably not an issue.
I don't have any omap-based board yet, but I had played a bit with TILER on a dm814x-based board I worked on for a project. I ran a quick benchmark in a baremetal environment, comparing a NEON-based fill of a
Is that a realistic access pattern? If, say, CPU draws to the buffer, I would bet it doesn't do "NEON based fill".
1920 x 1080 pixel (@ 32bpp) framebuffer via TILER versus directly in DDR3. The framebuffers were mapped as normal uncacheable memory.
6.9 ms -- no TILER, stride 7680 (contiguous) and 8192 8.6 ms -- TILER views 0-3, stride 32768 10.5 ms -- TILER views 4-7, stride 16384
What do these views mean? I mean, 0-3 is obviously 0/90/180/270 degree rotations, but what's 4-7?
So TILER did decrease performance, but only by 25% for views 0-3. Other
I'd say 25% is not "only" =).
initiators would probably see even less difference (if any at all) since only the cortex-A has a dedicated path to ram. Also, replacing the NEON-based fill by a fairly dumb wordwise fill increased time to 55.5 ms with or without TILER.
Did you try with write-combining buffer?
Of course the DM814x really isn't an OMAP5, and the test was rather simplistic, but it left me wondering what test was done exactly that exhibited poor performance when used with TILER.
I also wonder where the other claimed negatives in https://pyra-handheld.com/boards/threads/.74058/
That post seems to contain errors.
came from, since TILER in fact works quite transparently. The only thing unusual about its format is the large stride, but I don't immediately see why it would be a problem, and if necessary or desired it can be reduced to 8192 using the MMU when a buffer is mapped into userspace.
I think TILER works relatively ok (meaning, probably slight perf decrease, slightly more complex driver setup) for non-CPU initiators.
But for CPU... One problem is that the TILER 2D buffer can only be mapped without any caching (not even write-combining) due to HW issues.
The second reason is a bit more unclear to me, as I've never really worked on TILER: omapdrm allocates just two pages for rotated memory mapped to userspace, and changes those pages according to the memory accesses.
If I remember right, it was related to how TILER arranges the memory. Without this two page mechanism, the userspace could have been able to access buffers allocated by someone else, or alternatively lots of TILER space would have been left unused.
Tomi
On 20 June 2016 at 20:49, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
TILER 1D works fine, but TILER 2D doesn't. It is unusably slow for CPU at the moment.
I have no idea what you mean by "TILER 1D" vs "TILER 2D".
Also, what people usually want is transparent (to the SW) whole display rotation. TILER rotates the contents of a single plane, so the SW needs to deal with everything else involved.
You can just place your overlays or planes at various locations within TILER's rather large virtual memory space.
Is that a realistic access pattern? If, say, CPU draws to the buffer, I would bet it doesn't do "NEON based fill".
Well it was necessary to make TILER the bottleneck. Less efficient access patterns made the CPU the bottleneck instead (or actually it may have been the 64-bit interface from the Cortex-A8 subsystem to the L3 interconnect).
What do these views mean? I mean, 0-3 is obviously 0/90/180/270 degree rotations, but what's 4-7?
Actually 0-3 are normal, flip horizontal, flip vertical, and rotate 180 degrees. 4-7 are the remaining rotations/flips, which (unlike 0-3) interchange the x- and y-axis.
Note that it's probably more efficient to place the buffer(s) unrotated in the CPU's view and rotated in DSS' view than doing it the other way around.
Did you try with write-combining buffer?
As I mentioned I mapped the buffers as normal memory, which is always write-combining.
But for CPU... One problem is that the TILER 2D buffer can only be mapped without any caching (not even write-combining) due to HW issues.
You mean it gets mapped as Device memory? That will be horribly slow... what issue(s) are you referring to exactly?
The second reason is a bit more unclear to me, as I've never really worked on TILER: omapdrm allocates just two pages for rotated memory mapped to userspace, and changes those pages according to the memory accesses.
Huh? Two pages? That makes no sense, that's just a single line of the framebuffer...
Matthijs
On 21/06/16 00:02, Matthijs van Duin wrote:
On 20 June 2016 at 20:49, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
TILER 1D works fine, but TILER 2D doesn't. It is unusably slow for CPU at the moment.
I have no idea what you mean by "TILER 1D" vs "TILER 2D".
Ok. It sounds to me that what you know as "TILER" is not the "TILER" on OMAP5.
TILER 1D is used as a normal IOMMU, you can use it to create a contiguous view of scattered pages. TILER 2D is used for rotation.
Also, what people usually want is transparent (to the SW) whole display rotation. TILER rotates the contents of a single plane, so the SW needs to deal with everything else involved.
You can just place your overlays or planes at various locations within TILER's rather large virtual memory space.
Yes, but the plane positions, sizes are in display coordinates. You only rotate the content of those planes. It's quite trivial to deal with, of course, but the point is still that it's not a transparent whole display rotation, and the SW in question must know about that and deal with it.
Is that a realistic access pattern? If, say, CPU draws to the buffer, I would bet it doesn't do "NEON based fill".
Well it was necessary to make TILER the bottleneck. Less efficient access patterns made the CPU the bottleneck instead (or actually it may have been the 64-bit interface from the Cortex-A8 subsystem to the L3 interconnect).
What do these views mean? I mean, 0-3 is obviously 0/90/180/270 degree rotations, but what's 4-7?
Actually 0-3 are normal, flip horizontal, flip vertical, and rotate 180 degrees. 4-7 are the remaining rotations/flips, which (unlike 0-3) interchange the x- and y-axis.
Note that it's probably more efficient to place the buffer(s) unrotated in the CPU's view and rotated in DSS' view than doing it the other way around.
Did you try with write-combining buffer?
As I mentioned I mapped the buffers as normal memory, which is always write-combining.
Hmm, what? What's "normal memory"? =) To me, normal memory, from CPU's point of view, is fully cached.
But for CPU... One problem is that the TILER 2D buffer can only be mapped without any caching (not even write-combining) due to HW issues.
You mean it gets mapped as Device memory? That will be horribly
I think so, but I don't really know what is "device memory". We have three different options for caching: no caching, write-combining, and cached.
Normally we use write-combining for framebuffers, so that no explicit flushing is needed, but writes are still buffered a bit.
slow... what issue(s) are you referring to exactly?
I don't think there's an errata for it, but the commit is 7cb0d6c17b96b8bf3c25de2dfde4fdeb9191f4c3
The second reason is a bit more unclear to me, as I've never really worked on TILER: omapdrm allocates just two pages for rotated memory mapped to userspace, and changes those pages according to the memory accesses.
Huh? Two pages? That makes no sense, that's just a single line of the framebuffer...
Yes, doesn't make sense from the performance point of view, but there were real reasons for it. Unfortunately I don't know/remember the details, so I can't be more specific. It's maybe possible that this could be changed in the driver, but I'm quite sure there would be downsides to it too.
Tomi
On 21 June 2016 at 08:49, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Ok. It sounds to me that what you know as "TILER" is not the "TILER" on OMAP5.
TILER is identical on all TI devices that have it afaik. I'm just using terminology from the TRM.
TILER 1D is used as a normal IOMMU, you can use it to create a contiguous view of scattered pages.
That would be PAT.
TILER 2D is used for rotation.
That would be TILER.
Also, what people usually want is transparent (to the SW) whole display rotation. TILER rotates the contents of a single plane, so the SW needs to deal with everything else involved.
You can just place your overlays or planes at various locations within TILER's rather large virtual memory space.
Yes, but the plane positions, sizes are in display coordinates. You only rotate the content of those planes. It's quite trivial to deal with, of course, but the point is still that it's not a transparent whole display rotation, and the SW in question must know about that and deal with it.
You can just use the default TILER view for the CPU and tell DSS to scan out the buffer(s) in any rotation, this would avoid changing the physical address and stride of the buffer when you change the screen rotation.
As I mentioned I mapped the buffers as normal memory, which is always write-combining.
Hmm, what? What's "normal memory"?
See section A3.5.1 of the ARMv7-A/R Architecture Reference Manual.
We have three different options for caching: no caching, write-combining, and cached.
That would be terminology from x86 forced by linux onto other architectures. At least that's my impression, I don't actually know much about x86.
ARM does not consider write-combining to be a form of caching.
Normally we use write-combining for framebuffers, so that no explicit flushing is needed, but writes are still buffered a bit.
Write-combining is not synonymous to write-buffering. Device writes are still buffered, just not combined. To avoid buffering you'd need Strongly-Ordered memory but that's really horribly slow and should be avoided at all cost. Also, the A15 has errata related to strongly ordered memory and linux actually seems to remap it to device memory to avoid them (I noticed this while doing some tests with /dev/mem on a beagleboard-x15).
slow... what issue(s) are you referring to exactly?
I don't think there's an errata for it, but the commit is 7cb0d6c17b96b8bf3c25de2dfde4fdeb9191f4c3
That has no information whatsoever. "errors from the memory manager" ?
If this commit is indeed responsible for making TILER unusable slow, it would be nice to have some actual detail on why it was deemed necessary
The second reason is a bit more unclear to me, as I've never really worked on TILER: omapdrm allocates just two pages for rotated memory mapped to userspace, and changes those pages according to the memory accesses.
Huh? Two pages? That makes no sense, that's just a single line of the framebuffer...
Yes, doesn't make sense from the performance point of view, but there were real reasons for it. Unfortunately I don't know/remember the details, so I can't be more specific. It's maybe possible that this could be changed in the driver, but I'm quite sure there would be downsides to it too.
That's too vague to be able to usefully respond to :P
Matthijs
On 21/06/16 11:09, Matthijs van Duin wrote:
On 21 June 2016 at 08:49, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Ok. It sounds to me that what you know as "TILER" is not the "TILER" on OMAP5.
TILER is identical on all TI devices that have it afaik. I'm just using terminology from the TRM.
TILER 1D is used as a normal IOMMU, you can use it to create a contiguous view of scattered pages.
That would be PAT.
TILER 2D is used for rotation.
That would be TILER.
Ok. As I said, I have never really worked with it. TILER 1D and 2D terminology seems to be used in discussions. The TRM does talk about 1D and 2D, but doesn't explicitly mention "TILER 1D" or "TILER 2D".
Also, what people usually want is transparent (to the SW) whole display rotation. TILER rotates the contents of a single plane, so the SW needs to deal with everything else involved.
You can just place your overlays or planes at various locations within TILER's rather large virtual memory space.
Yes, but the plane positions, sizes are in display coordinates. You only rotate the content of those planes. It's quite trivial to deal with, of course, but the point is still that it's not a transparent whole display rotation, and the SW in question must know about that and deal with it.
You can just use the default TILER view for the CPU and tell DSS to scan out the buffer(s) in any rotation, this would avoid changing the physical address and stride of the buffer when you change the screen rotation.
Yes, but you still need to manage the rotated planes.
If you have a panel in its native orientation, and want a 10x20 plane in the left-top corner, you'll configure the plane to position 0,0 with size 10x20.
If you have the panel in 90 degree orientation, you need to rotate the contents of the plane, and also set the plane's size to 20x10, and position in in an other corner.
As I mentioned I mapped the buffers as normal memory, which is always write-combining.
Hmm, what? What's "normal memory"?
See section A3.5.1 of the ARMv7-A/R Architecture Reference Manual.
We have three different options for caching: no caching, write-combining, and cached.
That would be terminology from x86 forced by linux onto other architectures. At least that's my impression, I don't actually know much about x86.
ARM does not consider write-combining to be a form of caching.
Normally we use write-combining for framebuffers, so that no explicit flushing is needed, but writes are still buffered a bit.
Write-combining is not synonymous to write-buffering. Device writes are still buffered, just not combined. To avoid buffering you'd need Strongly-Ordered memory but that's really horribly slow and should be avoided at all cost. Also, the A15 has errata related to strongly ordered memory and linux actually seems to remap it to device memory to avoid them (I noticed this while doing some tests with /dev/mem on a beagleboard-x15).
Ok. Well, I'm speaking in Linux kernel terms, when dealing with the memory. We use pgprot_noncached or pgprot_writecombine for no-caching or writecombining.
slow... what issue(s) are you referring to exactly?
I don't think there's an errata for it, but the commit is 7cb0d6c17b96b8bf3c25de2dfde4fdeb9191f4c3
That has no information whatsoever. "errors from the memory manager" ?
If this commit is indeed responsible for making TILER unusable slow, it would be nice to have some actual detail on why it was deemed necessary
Yep... I'm not sure why I didn't include the error message, but I believe it was an L3 error.
I have internal emails about the issue which I can't share, but the conclusion was that it's recommended to use the memory without write-combining (in Linux terms). This did remove the errors.
Could be that the issue is somewhere else, and this change just seemed to fix it. I'm not sure if this was ever fully debugged and root-caused, as TI is not using the TILER much at all.
Tomi
On 21 June 2016 at 08:49, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Ok. It sounds to me that what you know as "TILER" is not the "TILER" on OMAP5.
Although TILER is still the same, I just noticed OMAP5 did actually extend PAT: its input range is twice the output range of TILER, with page-mode ("1D") being mapped to the upper half while 8/16/32-bit mode ("2D") is mapped to the lower half, which allows the two to use independent mappings to physical memory. That's where the distinction came from.
On 21/06/16 11:09, Matthijs van Duin wrote:
You can just use the default TILER view for the CPU and tell DSS to scan out the buffer(s) in any rotation, this would avoid changing the physical address and stride of the buffer when you change the screen rotation.
I just realized this is sillyness: no matter how you do it, landscape vs portrait will never be transparent to anyone using the framebuffer since the dimensions are simply different. However, for any fixed orientation, the fact that the buffer is being rotated can be entirely invisible to applications.
(What I said is however still true, which means that you could flip horizontal/vertical or rotate 180 degrees without userspace having to know or care, although I'm not sure how practical it would be to use the Pyra upside down ;P Square overlays could be changed to any orientation.)
On 21 June 2016 at 11:48, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Yes, but you still need to manage the rotated planes.
Where by "you" you probably mean "the omapdrm driver" :-)
It still doesn't strike me as particularly complicated management. It just means you need to swizzle a few numbers when setting up DSS...
... or rather use the helper functions that tiler already seems to provide... are you sure this hasn't been implemented yet already? It strikes me as odd that so much tiler stuff would be implemented without also properly supporting it in omapdrm, although I'm not really eager to try to dredge through the whole driver; as someone said:
<ayjay> i took a look into drm and aged 10 years
Ok. Well, I'm speaking in Linux kernel terms, when dealing with the memory. We use pgprot_noncached or pgprot_writecombine for no-caching or writecombining.
Like I said, x86 terminology.
pgprot_noncached however maps to Strongly-Ordered on ARM. Although as I said I got the impression linux remaps this to Device on the Cortex-A15 I haven't actually confirmed this. The mmu code is kind of a maze. You could try using MT_DEVICE just like ioremap() does to at least make sure Device memory is used rather than Strongly Ordered.
If this commit is indeed responsible for making TILER unusable slow, it would be nice to have some actual detail on why it was deemed necessary
Yep... I'm not sure why I didn't include the error message, but I believe it was an L3 error.
I have internal emails about the issue which I can't share, but the conclusion was that it's recommended to use the memory without write-combining (in Linux terms). This did remove the errors.
"Fixing" it by making the feature unusably slow is not much of a fix.
It seems to me that it can be undone with a simple DT change right? So it would be easy for anyone with an omap5 board to test that and see what error gets spit out? It would also be useful to check whether any particular kind of access is needed to trigger it
Mattthijs
On 21/06/16 15:06, Matthijs van Duin wrote:
On 21 June 2016 at 08:49, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Ok. It sounds to me that what you know as "TILER" is not the "TILER" on OMAP5.
Although TILER is still the same, I just noticed OMAP5 did actually extend PAT: its input range is twice the output range of TILER, with page-mode ("1D") being mapped to the upper half while 8/16/32-bit mode ("2D") is mapped to the lower half, which allows the two to use independent mappings to physical memory. That's where the distinction came from.
Ok.
On 21/06/16 11:09, Matthijs van Duin wrote:
You can just use the default TILER view for the CPU and tell DSS to scan out the buffer(s) in any rotation, this would avoid changing the physical address and stride of the buffer when you change the screen rotation.
I just realized this is sillyness: no matter how you do it, landscape vs portrait will never be transparent to anyone using the framebuffer since the dimensions are simply different. However, for any fixed orientation, the fact that the buffer is being rotated can be entirely invisible to applications.
Yes, changing rotation at runtime will never be transparent.
(What I said is however still true, which means that you could flip horizontal/vertical or rotate 180 degrees without userspace having to know or care, although I'm not sure how practical it would be to use the Pyra upside down ;P Square overlays could be changed to any orientation.)
True, flipping and 180 degree rotations are invisible to the user. Well, except that the buffers have to have been allocated from the TILER 2D region. And plane positions are not rotated. And if you're doing really low level HC stuff, you need to remember that after vertical blank, the bottom pixels of your framebuffer will start to be shown on the screen.
On 21 June 2016 at 11:48, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Yes, but you still need to manage the rotated planes.
Where by "you" you probably mean "the omapdrm driver" :-)
No, I mean the userspace.
It still doesn't strike me as particularly complicated management. It just means you need to swizzle a few numbers when setting up DSS...
... or rather use the helper functions that tiler already seems to provide... are you sure this hasn't been implemented yet already? It strikes me as odd that so much tiler stuff would be implemented without also properly supporting it in omapdrm, although I'm not really eager to try to dredge through the whole driver; as someone said:
Rotating the display is different than rotating a plane/framebuffer. We can only do the latter with TILER.
This means that there is no knob to change the display rotation, which would automatically rotate everything, translate the plane sizes and coordinated, etc.
It means that the display is still unrotated. Its width is the same, video timings are the same, the plane sizes/coordinates are the same. Things like scaling happen in unrotated context, meaning the scaling limits are not rotated. And so on. Only the contents of a plane are read in a rotated orientation.
Maybe we could add a 'rotation' knob to a DRM output, and the driver would try to manage everything else automatically. But it does sound scary to me, and all but trivial. Just "swizzling a few numbers" here or there does not sound like a good estimate of the work involved =).
If this commit is indeed responsible for making TILER unusable slow, it would be nice to have some actual detail on why it was deemed necessary
Yep... I'm not sure why I didn't include the error message, but I believe it was an L3 error.
I have internal emails about the issue which I can't share, but the conclusion was that it's recommended to use the memory without write-combining (in Linux terms). This did remove the errors.
"Fixing" it by making the feature unusably slow is not much of a fix.
Well, the alternatives were spamming with L3 errors, having broken display, versus slow. But yes, it's a workaround, not "fix".
It seems to me that it can be undone with a simple DT change right? So it would be easy for anyone with an omap5 board to test that and see what error gets spit out? It would also be useful to check whether any particular kind of access is needed to trigger it
You need to change the driver to undo it, but yes, simple change.
I did a quick test today, without seeing any issue, but it was on AM5. And, it's been ages since I used TILER, so there's a chance my setup wasn't quite correct. I was able to rotate just fine, though.
Tomi
On 21/06/16 15:06, Matthijs van Duin wrote:
It seems to me that it can be undone with a simple DT change right? So it would be easy for anyone with an omap5 board to test that and see what error gets spit out? It would also be useful to check whether any particular kind of access is needed to trigger it
I get this if I change OMAP_BO_UNCACHED to OMAP_BO_WC on omap5, with X11 + omap-driver, using xrandr to invert the output:
[ 641.208891] ------------[ cut here ]------------ [ 641.213556] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x220/0x34c() [ 641.222909] 44000000.ocp:L3 Custom Error: MASTER MPU TARGET DMM1 (Read): Data Access in User mode during Functional access [ 641.234001] Modules linked in: omapdrm drm_kms_helper drm panel_tlc59108 panel_dsi_cm panel_dpi connector_analog_tv connector_hdmi connector_dvi encoder_t c358768 encoder_sii9022 dra7_evm_encoder_tpd12s015 encoder_tpd12s015 encoder_tfp410 omapdss6 omapdss omapdss_base cfbfillrect cfbimgblt cfbcopyarea [last unl oaded: omapdss_base] [ 641.263585] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 4.4.12-00346-gbd33ea6cbfbb #14 [ 641.272585] Hardware name: Generic OMAP5 (Flattened Device Tree) [ 641.278619] Backtrace: [ 641.281096] [<c0015788>] (dump_backtrace) from [<c0015980>] (show_stack+0x18/0x1c) [ 641.288699] r7:00000000 r6:20070193 r5:ffffffff r4:00000000 [ 641.294440] [<c0015968>] (show_stack) from [<c03a88f8>] (dump_stack+0xac/0xe0) [ 641.301702] [<c03a884c>] (dump_stack) from [<c0042c20>] (warn_slowpath_common+0x80/0xbc) [ 641.307388] dmm 4e000000.dmm: timed out waiting for done [ 641.315158] r10:f8000100 r9:ee1c3190 r8:c03d9a90 r7:c09856c4 r6:00000093 r5:00000009 [ 641.323083] r4:c0aadd28 r3:00000000 [ 641.326703] [<c0042ba0>] (warn_slowpath_common) from [<c0042c94>] (warn_slowpath_fmt+0x38/0x40) [ 641.335440] r8:00000000 r7:c098553c r6:00000002 r5:c09855f0 r4:c0985694 [ 641.342237] [<c0042c60>] (warn_slowpath_fmt) from [<c03d9a90>] (l3_interrupt_handler+0x220/0x34c) [ 641.351149] r3:ee1c3300 r2:c0985694 [ 641.354763] r4:80080003 [ 641.357327] [<c03d9870>] (l3_interrupt_handler) from [<c00ada38>] (handle_irq_event_percpu+0x48/0x51c) [ 641.366675] r10:00000000 r9:00000000 r8:00000018 r7:c0aaf5f0 r6:c0aae98c r5:ee1aba60 [ 641.374597] r4:ee1ccd00 [ 641.377159] [<c00ad9f0>] (handle_irq_event_percpu) from [<c00adf4c>] (handle_irq_event+0x40/0x64) [ 641.386070] r10:00000001 r9:c0aadef8 r8:00000000 r7:c0aaf5f0 r6:c0ab53a8 r5:ee1aba60 [ 641.393994] r4:ee1aba00 [ 641.396556] [<c00adf0c>] (handle_irq_event) from [<c00b1468>] (handle_fasteoi_irq+0x108/0x1d4) [ 641.405205] r7:c0aaf5f0[ 641.407375] dmm 4e000000.dmm: timed out waiting for done [ 641.407389] omapdrm omapdrm.0: failed to pin: -110
[ 641.417716] r6:c0ab53a8 r5:ee1aba60 r4:ee1aba00 [ 641.417736] [<c00b1360>] (handle_fasteoi_irq) from [<c00acfc0>] (generic_handle_irq+0x28/0x3c) [ 641.417740] r7:c0aaf5f0 r6:00000018 r5:c0aa78c4 r4:c0aa78c4 [ 641.417762] [<c00acf98>] (generic_handle_irq) from [<c00ad30c>] (__handle_domain_irq+0x98/0x130) [ 641.417771] [<c00ad274>] (__handle_domain_irq) from [<c00095c8>] (gic_handle_irq+0x4c/0x9c) [ 641.417790] r10:fa213000 r9:00000000 r8:c0aaf844 r7:fa212000 r6:c0b276c8 r5:c0aadef8 [ 641.417796] r4:fa21200c [ 641.417808] [<c000957c>] (gic_handle_irq) from [<c076fcf8>] (__irq_svc+0x58/0x98) [ 641.417813] Exception stack(0xc0aadef8 to 0xc0aadf40) [ 641.417820] dee0: 00000001 00000001 [ 641.417828] df00: 00000000 c0ab1c78 c0aae9ec 00000000 00000000 c0b6fad0 c077847c c0aaf5f0 [ 641.417836] df20: c0b6e959 c0aadf54 c0aadf18 c0aadf48 c009d5fc c00114bc 20070013 ffffffff [ 641.417857] r10:c0b6e959 r9:c0aaf5f0 r8:c077847c r7:c0aadf2c r6:ffffffff r5:20070013 [ 641.417865] r4:c00114bc r3:001522f2 [ 641.417877] [<c0011494>] (arch_cpu_idle) from [<c0091e8c>] (default_idle_call+0x28/0x38) [ 641.417886] [<c0091e64>] (default_idle_call) from [<c00922fc>] (cpu_startup_entry+0x408/0x4f4) [ 641.417895] [<c0091ef4>] (cpu_startup_entry) from [<c0767a00>] (rest_init+0x134/0x174) [ 641.417902] r7:c0aae8c0 [ 641.417912] [<c07678cc>] (rest_init) from [<c0a34cd8>] (start_kernel+0x37c/0x3f4) [ 641.417922] r5:c0b85000 r4:c0b85050 [ 641.417931] [<c0a3495c>] (start_kernel) from [<8000807c>] (0x8000807c) [ 641.417936] ---[ end trace 40e778d49bff5062 ]---
On 21 June 2016 at 14:37, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Maybe we could add a 'rotation' knob to a DRM output, and the driver would try to manage everything else automatically
That would be exactly what I was suggesting :-) Only the DSS driver would know the display is actually 720x1280, as far as the rest of the kernel (and userspace, and other initiators like SGX) is concerned the display is 1280x720.
This would make the rotation pretty transparent, and also avoid non-default tiler orientation for the CPU and SGX.
But it does sound scary to me, and all but trivial.
I have faith in you!
On 21 June 2016 at 15:25, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
using xrandr to invert the output
Am I understanding correctly that the problem doesn't appear in the default orientation, even if the buffer is allocated in tiled memory? If so then this is probably not an issue for the Pyra use case
[ 641.222909] 44000000.ocp:L3 Custom Error: MASTER MPU TARGET DMM1 (Read): Data Access in User mode during Functional access
OK, so we have a read error from userspace. Moreover it never seems to result in data abort, which seems to confirm it was caused by speculative data prefetching.
If that were the only problem then it would just be a false alarm caused by the l3 interconnect driver.
[ 641.407375] dmm 4e000000.dmm: timed out waiting for done [ 641.407389] omapdrm omapdrm.0: failed to pin: -110
This however is a bigger issue. Hard to say what's going on here though, some more status info would be useful.
I also noticed that the driver never enables ERR_LUT_MISS irqs and silently discards all other error irqs... that's not a very helpful way to "handle" errors.
Matthijs
On 21/06/16 20:19, Matthijs van Duin wrote:
On 21 June 2016 at 14:37, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Maybe we could add a 'rotation' knob to a DRM output, and the driver would try to manage everything else automatically
That would be exactly what I was suggesting :-) Only the DSS driver would know the display is actually 720x1280, as far as the rest of the kernel (and userspace, and other initiators like SGX) is concerned the display is 1280x720.
This would make the rotation pretty transparent, and also avoid non-default tiler orientation for the CPU and SGX.
But it does sound scary to me, and all but trivial.
I have faith in you!
Yep, I'm happy to review patches for this! =)
On 21 June 2016 at 15:25, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
using xrandr to invert the output
Am I understanding correctly that the problem doesn't appear in the default orientation, even if the buffer is allocated in tiled memory? If so then this is probably not an issue for the Pyra use case
Well, to be honest, I'm not sure if the error I pasted is the same that we needed the workaround for a few years back. I don't remember the error, and I wasn't able to find it from my mail archives. And I also have to say I did only very quick tests.
But something is obviously badly broken there at the moment when using WC, so it's likely the same error.
Tomi
On 21 June 2016 at 20:09, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Yep, I'm happy to review patches for this! =)
Naw
On 21 June 2016 at 15:25, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
using xrandr to invert the output
Am I understanding correctly that the problem doesn't appear in the default orientation, even if the buffer is allocated in tiled memory? If so then this is probably not an issue for the Pyra use case
Well, to be honest, I'm not sure if the error I pasted is the same that we needed the workaround for a few years back. I don't remember the error, and I wasn't able to find it from my mail archives. And I also have to say I did only very quick tests.
But something is obviously badly broken there at the moment when using WC, so it's likely the same error.
Yes that sounds likely, however you didn't answer my question: does the error still occur if the framebuffer is allocated in tiled memory but not rotated/mirrored?
Matthijs
On 21/06/16 22:10, Matthijs van Duin wrote:
On 21 June 2016 at 20:09, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Yep, I'm happy to review patches for this! =)
Naw
On 21 June 2016 at 15:25, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
using xrandr to invert the output
Am I understanding correctly that the problem doesn't appear in the default orientation, even if the buffer is allocated in tiled memory? If so then this is probably not an issue for the Pyra use case
Well, to be honest, I'm not sure if the error I pasted is the same that we needed the workaround for a few years back. I don't remember the error, and I wasn't able to find it from my mail archives. And I also have to say I did only very quick tests.
But something is obviously badly broken there at the moment when using WC, so it's likely the same error.
Yes that sounds likely, however you didn't answer my question: does the error still occur if the framebuffer is allocated in tiled memory but not rotated/mirrored?
I did not see an error there, only after I inverted it with xrandr. But, I didn't test much.
I also did a quick test with kmsxx's library's test tools, but I didn't see any error there with 90 degree rotation. But, again, I didn't test much and I don't think the test case was identical to X server's.
Tomi
On 21/06/16 11:09, Matthijs van Duin wrote:
The second reason is a bit more unclear to me, as I've never really worked on TILER: omapdrm allocates just two pages for rotated memory mapped to userspace, and changes those pages according to the memory accesses.
Huh? Two pages? That makes no sense, that's just a single line of the framebuffer...
Yes, doesn't make sense from the performance point of view, but there were real reasons for it. Unfortunately I don't know/remember the details, so I can't be more specific. It's maybe possible that this could be changed in the driver, but I'm quite sure there would be downsides to it too.
That's too vague to be able to usefully respond to :P
Maybe Rob remembers better =).
Tomi
On Tue, Jun 21, 2016 at 5:49 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
On 21/06/16 11:09, Matthijs van Duin wrote:
The second reason is a bit more unclear to me, as I've never really worked on TILER: omapdrm allocates just two pages for rotated memory mapped to userspace, and changes those pages according to the memory accesses.
Huh? Two pages? That makes no sense, that's just a single line of the framebuffer...
Yes, doesn't make sense from the performance point of view, but there were real reasons for it. Unfortunately I don't know/remember the details, so I can't be more specific. It's maybe possible that this could be changed in the driver, but I'm quite sure there would be downsides to it too.
That's too vague to be able to usefully respond to :P
Maybe Rob remembers better =).
I thought it was more than two pages, and/or configurable.. but either way, performance was a secondary concern. It was really just for sw fallbacks. You really don't want to be using tiler 2d buffers if you are doing sw rendering. IIRC there was some reaons on omap5 that we couldn't even mmap 2d buffers as writecombine, they had to be unbuffered, which makes it somewhat useless for sw rendering.
BR, -R
Tomi
Hi Rob,
On 21/06/16 15:04, Rob Clark wrote:
On Tue, Jun 21, 2016 at 5:49 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
On 21/06/16 11:09, Matthijs van Duin wrote:
The second reason is a bit more unclear to me, as I've never really worked on TILER: omapdrm allocates just two pages for rotated memory mapped to userspace, and changes those pages according to the memory accesses.
Huh? Two pages? That makes no sense, that's just a single line of the framebuffer...
Yes, doesn't make sense from the performance point of view, but there were real reasons for it. Unfortunately I don't know/remember the details, so I can't be more specific. It's maybe possible that this could be changed in the driver, but I'm quite sure there would be downsides to it too.
That's too vague to be able to usefully respond to :P
Maybe Rob remembers better =).
I thought it was more than two pages, and/or configurable.. but either way, performance was a secondary concern. It was really just for sw fallbacks. You really don't want to be using tiler 2d buffers if you are doing sw rendering. IIRC there was some reaons on omap5 that we couldn't even mmap 2d buffers as writecombine, they had to be unbuffered, which makes it somewhat useless for sw rendering.
Yes, that was discussed earlier in this thread. However, this page mechanism was there much earlier than the forced-unbuffered work-around.
Tomi
On Tue, Jun 21, 2016 at 8:07 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
Hi Rob,
On 21/06/16 15:04, Rob Clark wrote:
On Tue, Jun 21, 2016 at 5:49 AM, Tomi Valkeinen tomi.valkeinen@ti.com wrote:
On 21/06/16 11:09, Matthijs van Duin wrote:
> The second reason is a bit more unclear to me, as I've never really > worked on TILER: omapdrm allocates just two pages for rotated memory > mapped to userspace, and changes those pages according to the memory > accesses.
Huh? Two pages? That makes no sense, that's just a single line of the framebuffer...
Yes, doesn't make sense from the performance point of view, but there were real reasons for it. Unfortunately I don't know/remember the details, so I can't be more specific. It's maybe possible that this could be changed in the driver, but I'm quite sure there would be downsides to it too.
That's too vague to be able to usefully respond to :P
Maybe Rob remembers better =).
I thought it was more than two pages, and/or configurable.. but either way, performance was a secondary concern. It was really just for sw fallbacks. You really don't want to be using tiler 2d buffers if you are doing sw rendering. IIRC there was some reaons on omap5 that we couldn't even mmap 2d buffers as writecombine, they had to be unbuffered, which makes it somewhat useless for sw rendering.
Yes, that was discussed earlier in this thread. However, this page mechanism was there much earlier than the forced-unbuffered work-around.
correct, it was in place since o4..
But like I said, it was intended for sw fallbacks (there are some things w/ x11 that always fall back to sw rendering). The trade-off was that more pages == less 2d space available for dynamically pinned/unpinned buffers. (We were at least using that for video decoder, to avoid running out of 2d space.)
BR, -R
Tomi