[Letux-kernel] Fixing TILER
H. Nikolaus Schaller
hns at goldelico.com
Tue Oct 30 21:20:26 CET 2018
Hi,
> Am 29.10.2018 um 21:49 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>
> Hi,
>
>> Am 26.10.2018 um 19:12 schrieb H. Nikolaus Schaller <hns at 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 at 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 at ffwll.ch>
>> Signed-off-by: Hans de Goede <hdegoede at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20181030/2bc97d44/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DSC00944.jpeg
Type: image/jpeg
Size: 74771 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20181030/2bc97d44/attachment-0001.jpeg>
More information about the Letux-kernel
mailing list