[Letux-kernel] Fixing TILER

[H. Nikolaus Schaller]

Hi Matthijs,

> Am 03.11.2018 um 07:51 schrieb Matthijs van Duin <matthijsvanduin at gmail.com>:
> 
> On Tue, 23 Oct 2018 at 19:42, H. Nikolaus Schaller <hns at goldelico.com> wrote:
>> 2. in xserverrc (should not make a difference if a systemd rule is used): /root/tiler-ctl 270
> 
> Note that rotating the framebuffer should not require any tools at
> runtime. Adding drm_kms_helper.fbdev_rotation=8 (it was 8 right? or
> 2?) to the kernel parameters should suffice.

Well, the /root/tiler-ctl simply unloads the module and reloads with
different fbdev_rotation parameters.

This is easier that changing the command line for every device.

LetuxOS kernel is thought to be (mostly) device independent, so it
uses a static command line and only the device tree is different.

> 
>>   this already makes the console rotate (except that there is no visible cursor for 90/270 and cat /dev/urandom >/dev/fb0 also does not show a pattern)
> 
> But other than this the console still works normally, i.e. text still
> shows up? That's... really bizarre.

Ah, no. My description wasn't precise. There is only black picture for
90/270.

> 
> Note btw that using read() or write() on /dev/fb0 (e.g. with cat) uses
> the kernel-mapping of the fbdev (like the framebuffer console) rather
> than a userspace-mapping (like every other fbdev client, including
> xorg-video-fbdev), and the code paths involved are quite different.
> 
>> 4. xrandr --output Unknown16-1 --rotate right / left / normal / inverted shows all 4 rotations
> 
> That either means:
> 1. you're using software rotation, or
> 2. you're using xorg-video-omap, which has always worked (even without
> my patches).

I think I use Driver "omap" but xrandr refuses to rotate left/right
unless your patches are included. I have not checked which one does
make the difference.

> 
> 
> On Thu, 25 Oct 2018 at 03:14, Michael Mrozek <EvilDragon at openpandora.org> wrote:
>> If you're using X with omapdrm or modesetting, the framebuffer isn't
>> used and thus, you are not using TILER.
> 
> That's not accurate. There are two parts to my patches:
> 1. (tiler/fast) Improve performance of userspace mappings of
> TILER-allocated framebuffers.
> 2. (tiler/fbdev) Hack the legacy fbdev to allocate it in TILER and rotate it.
> 
> The effect on X11 depends on the video backend used:
> 1. xorg-video-fbdev: simply renders into the legacy fbdev hence will
> be rotated without being aware of it. No xrandr support unless
> emulated (slowly) in software.
> 2. xorg-video-omap: does not use the legacy fbdev. This supports
> rotation and has always used TILER. It benefits from the performance
> improvements of my patches.
> 3. xorg-video-modesetting: does not use the legacy fbdev. Its attempts
> to rotate will fail because it uses "dumb" buffers which are not
> allocated in TILER. I did once make a patch that forces "dumb" buffers
> (patch/tiler-buf-dumb) to be allocated in TILER, but this breaks all
> dma-buf users (such as SGX) because dma-buf export of TILER buffers
> was never implemented correctly in omapdrm.
> 
> 
> On Fri, 26 Oct 2018 at 19:12, H. Nikolaus Schaller <hns at goldelico.com> wrote:
>> The problem is that I have not even the tiniest idea how the tiler patches
>> work and make use of the TILER. They basically modify frame buffer layout
>> and enable some more write modes and user-space mapping.
> 
> The crucial changes are:
> 1. (patch/tiler-buffer-fbdev) allocate a tiled buffer in
> omap_fbdev_create (pass OMAP_BO_TILED_32 to omap_gem_new)
> 2. (patch/tiler-fbdev) add a kernel parameter to set the rotation of
> the legacy fbdev
> 
> It all ended up a bit hacky, for a large part because omapdrm had no
> support for kernel-mapping of tiled buffers and I wasn't sure how to
> implement it properly :P
> 
>> But that is all. There is no explicit code in the patch set to write any TILER
>> control register differently
> 
> Why would you expect any?

Well, if people say that this are patches to make use of the OMAP5 TILER
and some change from 4.15 to 4.16 has broken TILER rotation, the first order
assumption is that there are commands to program the TILER.

Of course your description and my now a little increased understanding
is that TILER control is already part of omapdrm - but not enabled in a
way that we can simply rotate the framebuffer.

So your patches do that "higher level" stuff.

> 
> 
> On Tue, 30 Oct 2018 at 21:20, H. Nikolaus Schaller <hns at goldelico.com> wrote:
>> So this has something to do with panel orientation!
>> 
>> It may be in conflict with our TILER code and tiler-ctl...
> 
> I agree, it sounds like there's good potential for interaction. It
> also sounds like it could at least replace the final commit of my
> patch/tiler-fbdev branch, though I haven't yet looked at it to confirm
> (but I will after sending this email).

My new "solution" (also a hack) removes your drm_kms_helper patch and replaces
it by a different way to read and apply the fbdev_rotation parameter.

> 
>> if (rotation != DRM_MODE_ROTATE_180 || !plane->rotation_property) {
>> fb_helper->sw_rotations |= rotation;
>> return;
>> }
>> 
>> which makes me think that this code indeed disables hardware rotation for /dev/fb0.
> 
> No, plane->rotation_property != NULL, so it should not use software rotation.
> 
>> It may still use TILER for X11. But I have no means or do not know any means to test
>> if TILER is used or not.
> 
> grep rotation /sys/kernel/debug/dri/[0-9]/state

Ah, good to know!

BR and thanks,
Nikolaus