[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