Hi,
Am 18.01.2018 um 07:59 schrieb Andreas Kemnade andreas@kemnade.info:
Hi,
there is again a mvduin/patch/tiler-fbdev-v3 in the letux kernel.
Yes. Matthijs was so friendly to rebase and adapt it to 4.15 so that I thought it would be ok to merge it back (e.g. to demonstrate latest Letux OS on Pyra).
And again framebuffer applications do not work sane. Mmapping /dev/fb0 and zeroing that causes trouble (Bus error or hangs) on the gta04.
Oops. Thanks for the report. I didn't notice because I am usually testing with X11/DRM.
Just text on framebuffer is ok (fixed by my patch)
If I understand it correctly: That patch series is the best we have to have proper rotation on the Pyra
Yes.
so that is why it is in altough the author knows that it breaks things (and probably also what) and therefore did not recommend to apply it anywhere.
Yes. We currently have to choose between Skylla and Charybdis.
Either have * no solution for OMAP5 or * a working (but not perfect) which makes problems with the OMAP3.
But for qtmoko we need a working framebuffer. So we need a solution.
But as the patch series contains as far as I can remember wrong approaches it does not make sense to further hack-fix it for me. And finding out bugs which somebody else knows and understands seems to be duplicated effort.
Please correct me if I am wrong.
You are right. But what is the solution?
a) Andreas fixes it for OMAP3 case b) Matthijs fixes it so that it does not influence OMAP3 and can be recommended and endorsed by him to be applied c) both work together d) we do nothing and wait that it resolves itself by upstream changes e) we wait until someone else (Tomi Valkainen?) independently implements proper TILER code upstream f) we ship different kernel binaries for every device (which is against the Letux OS idea and other Distro kernels) g) ???
BR, Nikolaus
Hi Tomi,
Am 18.01.2018 um 08:41 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 18.01.2018 um 07:59 schrieb Andreas Kemnade andreas@kemnade.info:
Hi,
there is again a mvduin/patch/tiler-fbdev-v3 in the letux kernel.
Yes. Matthijs was so friendly to rebase and adapt it to 4.15 so that I thought it would be ok to merge it back (e.g. to demonstrate latest Letux OS on Pyra).
And again framebuffer applications do not work sane. Mmapping /dev/fb0 and zeroing that causes trouble (Bus error or hangs) on the gta04.
Oops. Thanks for the report. I didn't notice because I am usually testing with X11/DRM.
Just text on framebuffer is ok (fixed by my patch)
If I understand it correctly: That patch series is the best we have to have proper rotation on the Pyra
Yes.
so that is why it is in altough the author knows that it breaks things (and probably also what) and therefore did not recommend to apply it anywhere.
Yes. We currently have to choose between Skylla and Charybdis.
Either have
- no solution for OMAP5 or
- a working (but not perfect) which makes problems with the OMAP3.
But for qtmoko we need a working framebuffer. So we need a solution.
But as the patch series contains as far as I can remember wrong approaches it does not make sense to further hack-fix it for me. And finding out bugs which somebody else knows and understands seems to be duplicated effort.
Please correct me if I am wrong.
You are right. But what is the solution?
a) Andreas fixes it for OMAP3 case b) Matthijs fixes it so that it does not influence OMAP3 and can be recommended and endorsed by him to be applied c) both work together d) we do nothing and wait that it resolves itself by upstream changes e) we wait until someone else (Tomi Valkainen?) independently implements proper TILER code upstream
I should have included you for direct discussion.
What is missing / has to be fixed in your opinion to integrate the OMAP5 TILER demo code written by Matthijs into mainline?
Or are you working yourself on a proper implementation?
f) we ship different kernel binaries for every device (which is against the Letux OS idea and other Distro kernels) g) ???
BR and thanks, Nikolaus Schaller
On 18/01/18 17:49, H. Nikolaus Schaller wrote:
What is missing / has to be fixed in your opinion to integrate the OMAP5 TILER demo code written by Matthijs into mainline?
Or are you working yourself on a proper implementation?
I haven't looked at Matthijs implementation, but I have done some TILER fixes along the way. They're at least in the TI's kernel, I'm not sure if I have upstreamed them yet. Nothing for fbdev, though.
But, overall, TILER rotation is not working. It is usable with CPU, but because of the TILER related errata, CPU access has been descoped, and is kind of unsupported.
TILER would be usable with other IPs (SGX, DSP, VIP, VPE, etc), but the TILER 2D memory layout is not supported with dmabuf, so we have no means to use TILER 2D with other IPs.
Tomi
Hi Tomi,
Am 18.01.2018 um 16:54 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 18/01/18 17:49, H. Nikolaus Schaller wrote:
What is missing / has to be fixed in your opinion to integrate the OMAP5 TILER demo code written by Matthijs into mainline?
Or are you working yourself on a proper implementation?
I haven't looked at Matthijs implementation, but I have done some TILER fixes along the way. They're at least in the TI's kernel, I'm not sure if I have upstreamed them yet. Nothing for fbdev, though.
Ok.
It may not even be necessary to have fbdev rotation, just omapdrm mode on OMAP5. OMAP3 is completely fine (unless we add Matthijs' patch set.
But, overall, TILER rotation is not working. It is usable with CPU, but because of the TILER related errata, CPU access has been descoped, and is kind of unsupported.
This seems to be "fixed" by Matthijs patches in a satisfying way. At least for OMAP5. But I have no technical understanding about the details and what Matthijs are really doing. You are much more experts than me with TILER. I just know that it can be used for rotate while writing to a framebuffer or for reading to the panel. We just need reading to be fast and not resource hungry.
For OMAP3 it seems that just some code is not properly disabled on OMAP3, which makes trouble on multi-arch kernels but there is no need for rotation on OMAP3 (at least for our projects).
TILER would be usable with other IPs (SGX, DSP, VIP, VPE, etc), but the TILER 2D memory layout is not supported with dmabuf, so we have no means to use TILER 2D with other IPs.
Having the full list solved, does not seem to be of highest priority - except maybe the SGX. But SGX can probably do its own rotation easily.
So we are mainly looking for a working addition for OMAP5 for text display (default console) and X11/Wayland. Ideally such that Option "Rotate" "right" in xorg.conf simply works.
Do you think you can find time to take a look at Matthijs implementation and what he really is doing to get our demos working flawless (despite errata)?
BR and thanks, Nikolaus
On 18/01/18 18:20, H. Nikolaus Schaller wrote:
Do you think you can find time to take a look at Matthijs implementation and what he really is doing to get our demos working flawless (despite errata)?
Well, you can't avoid the errata. The errata says that if you access TILER mapped memory with CPU, the device may lock up.
I will review mainline patches sent to dri-devel, but otherwise I'm not planning to work on TILER any time soon, unless we figure out a way to deal with the dmabuf problem.
Tomi
Am Fri, 19 Jan 2018 10:43:12 +0200 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Hi,
well, as far as I am aware, no one had encountered a CPU lockup on the shipped out prototypes so far, and we're all using TILER with the zmatt patch for transparent rotaton.
I've got no idea why - but it seems to work fine here :)
On 18/01/18 18:20, H. Nikolaus Schaller wrote:
Do you think you can find time to take a look at Matthijs implementation and what he really is doing to get our demos working flawless (despite errata)?
Well, you can't avoid the errata. The errata says that if you access TILER mapped memory with CPU, the device may lock up.
I will review mainline patches sent to dri-devel, but otherwise I'm not planning to work on TILER any time soon, unless we figure out a way to deal with the dmabuf problem.
Tomi
On 19/01/18 13:11, Michael Mrozek wrote:
Am Fri, 19 Jan 2018 10:43:12 +0200 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Hi,
well, as far as I am aware, no one had encountered a CPU lockup on the shipped out prototypes so far, and we're all using TILER with the zmatt patch for transparent rotaton.
I've got no idea why - but it seems to work fine here :)
It's not easy to hit, but it's there. Possibly it doesn't matter for some (many?) users. So I'm fine with supporting CPU access to TILER addresses in the mainline kernel, but at the same time, it's not something I will be working on. And possibly at some point I'll add a kernel kconfig option, so that one needs to explicitly enable (and thus acknowledge) the CPU accesses to TILER.
Tomi
Am 19.01.2018 um 12:15 schrieb Tomi Valkeinen tomi.valkeinen@ti.com:
On 19/01/18 13:11, Michael Mrozek wrote:
Am Fri, 19 Jan 2018 10:43:12 +0200 hat Tomi Valkeinen tomi.valkeinen@ti.com geschrieben:
Hi,
well, as far as I am aware, no one had encountered a CPU lockup on the shipped out prototypes so far, and we're all using TILER with the zmatt patch for transparent rotaton.
I've got no idea why - but it seems to work fine here :)
It's not easy to hit, but it's there. Possibly it doesn't matter for some (many?) users. So I'm fine with supporting CPU access to TILER addresses in the mainline kernel, but at the same time, it's not something I will be working on.
Ok this means Matthijs should provide proper patches?
And possibly at some point I'll add a kernel kconfig option, so that one needs to explicitly enable (and thus acknowledge) the CPU accesses to TILER.
That would be ok for us.
BR, Nikolaus
-
H. Nikolaus Schaller -
Michael Mrozek -
Tomi Valkeinen