Hi,

Am 29.10.2018 um 21:49 schrieb H. Nikolaus Schaller <hns@goldelico.com>:

Hi,

Am 26.10.2018 um 19:12 schrieb H. Nikolaus Schaller <hns@goldelico.com>:

Kernel 4.15 still showed the console on the screen with rotated TILER-
Setting, so the full framebuffer was working.
If the framebuffer / console doesn't show, something is broken...

I did set up an SD card without X11 so that it does not disturb the console.

tiler-ctl 0 (the default) shows a non-rotated image, i.e. the cursor is
binking in the lower left corner.

cat /dev/urandom /dev/fb0

writes a random picture.

After doing tiler-ctl 270 the screen is black.

And there is a difference between kernels.

4.15 (up to 4.15.17) is then showing the cursor in the upper left corner.
And the cp command fills the image top down.

But with 4.16-rc1 (not -rc4 as with the Audio issue) the screen remains
black and there is no fill by cp.

Now we can compare letux-4.15(.0) and letux-4.16-rc1.

There is no diff in device trees.

There are diffs in drivers/gpu/drm/omapdrm.

At a first glance they are mostly cosmetic or not related to TILER
operation (but I may have missed something).

Then I compared letux_defconfig.

There is one suspicious entry, a new one introduced in 4.16-rc1:

CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=m

Looking for the code that is configured by it shows:

drivers/gpu/drm/drm_panel_orientation_quirks.c:

new file introduced as <404d1a3edc387>

Kconfig:

# Separate option because drm_panel_orientation_quirks.c is shared with fbdev
config DRM_PANEL_ORIENTATION_QUIRKS
tristate

The commit message says:

commit 404d1a3edc3873b339198ec3f3d6a09be2ddda4f
Author: Hans de Goede <j.w.r.degoede@gmail.com>
Date:   Sat Nov 25 20:35:48 2017 +0100

   drm: Add panel orientation quirks, v6.

   Some x86 clamshell design devices use portrait tablet screens and a display
   engine which cannot rotate in hardware, so the firmware just leaves things
   as is and we cannot figure out that the display is oriented non upright
   from the hardware.

   So at least on x86, we need a quirk table for this. This commit adds a DMI
   based quirk table which is initially populated with 5 such devices: Asus
   T100HA, GPD Pocket, GPD win, I.T.Works TW891 and the VIOS LTH17.

   This quirk table will be used by the drm code to let userspace know that
   the display is not mounted upright inside the devices case through a new
   panel orientation drm-connector property, as well as to tell fbcon to
   rotate the console so that it shows the right way up.

   Changes in v5:
   -Add a kernel-doc comment documenting drm_get_panel_orientation_quirk()
   -Remove board_* matches from the dmi-matches for the VIOS LTH17 laptop,
    keeping only the (identical) sys_vendor and product_name matches.
    This is necessary because an older version of the bios has
    board_vendor set to VOIS instead of VIOS

   Changes in v6:
   -Add reference to added kernel-docs in Documentation/gpu/drm-kms-helpers.rst

   Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
   Signed-off-by: Hans de Goede <hdegoede@redhat.com>
   Link: https://patchwork.freedesktop.org/patch/msgid/20171125193553.23986-3-hdegoede@redhat.com




See: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.19&id=404d1a3edc3873b339198ec3f3d6a09be2ddda4f
and: https://elixir.bootlin.com/linux/v4.16-rc1/source/drivers/gpu/drm/drm_panel_orientation_quirks.c

So this has something to do with panel orientation!

It may be in conflict with our TILER code and tiler-ctl...

But:

/* There are no quirks for non x86 devices yet */

It seems to depend on CONFIG_DMI which we do not have set.
I.e. this is (almost) dead code on ARM.

But it might still have a side-effect on the console if we
tell DRM that we have rotation...

Or we must add a Pyra quirk here so that the rotation defined
by tiler-ctl is not undone somewhere else in the fbcon or the
fbdev driver.

A hint for such a mixup of rotation setup is here:

https://elixir.bootlin.com/linux/v4.16-rc1/source/drivers/gpu/drm/drm_fb_helper.c#L2417

This function is new and was introduced by:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.19&id=8f0cb418393ba8023c1496eb3ab0a2adca8fbaa2

and probably drm_setup_crtc_rotation() conflicts with

http://git.goldelico.com/?p=letux-kernel.git;a=commitdiff;h=259bfe5d9140c27f459dbc8bb2fa0c3d1968411d

So in summary it looks as if a solution for rotated panels was developed
upstream. But we did not notice.

Any since we are not heavily working on pushing our work as fast as possible upstream,
kernel maintainers also didn't notice that we are working on it.

Finally both solutions conflict. That happens if we deviate too much from mainline or
forget to upstream something.

That are my new findings for this topic.

Solutions are welcome or ED can't finish the hardware tester script used for mass production.

Maybe a simple hack to disable drm_setup_crtc_rotation() suffices.
Or moving the fbdev_rotation module parameter to drm_panel_orientation_quirks.c

It seems as if I won the contest to find a workaround :)

It is a combination of both ideas that works: move the fbdev_rotation
module parameter into drm_setup_crtc_rotation().

Code is included here:

http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/work-fixes-for-ed

and a photo (tiler-ctl 270; ls -l >dev/tty1) attached.

Another observation while writing the core: maybe ED is correct in his claim that
the TILER is disabled now...

I have found a comment around the place where I added the hack:

/*
* TODO: support 90 / 270 degree hardware rotation,
* depending on the hardware this may require the framebuffer
* to be in a specific tiling format.
*/

and code

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.

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. I can only see if the image is rotated, and it now is. It
also is rotated for my X11 setup without any change in user-space.

BR,
Nikolaus