Hi Andrey,

Am 30.01.2017 um 22:54 schrieb Andrey Utkin andrey_utkin@fastmail.com:

On Mon, Jan 30, 2017 at 05:35:02PM +0100, H. Nikolaus Schaller wrote:

...

Hi, since we now have new Main & CPU boards and displayboards without SSD2858, I'd like to update our letux-kernel to rotate by tiler by default.

Panel driver and DSS work well.

It works fine without tiler (unrotated), but I get merge conflicts when trying to merge

http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/te...

on top of

http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/letux-4...

Can someone please point to instructions or explain what is going wrong?

Hi,

No idea what's happening for you, for me it merges cleanly. Or do I miss something?

$ git co letux/letux-4.10-rc6 Note: checking out 'letux/letux-4.10-rc6'.

You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example:

git checkout -b <new-branch-name>

HEAD is now at 4e7fd9336832... Merge branches 'work/hns/letux/rootfs', 'work/hacks', 'work/josua/debian-build', 'work/hns/input/tsc2007-v9', 'work/hns/power/twl4030_charger-v3', 'work/hns/usb/misc/usb3503', 'work/hns/dt/gta04', 'work/hns/dt/gta04a5', 'work/hns/dt/omap5-common-v3', 'work/hns/dt/omap5-uevm-v3', 'work/hns/dt/pyra', 'work/hns/dt/lc8', 'work/hns/misc/wwan', 'work/hns/misc/w2sg-tty-slave2-v4', 'work/hns/omapdss/tvfix-v3', 'work/hns/video/dss/displayprobing', 'work/hns/power/bq27xxx', 'work/marek/generic-adc-battery', 'work/kemnade/charging_fixes', 'work/kemnade/musb-fixes', 'work/hns/iio-input-bridge', 'work/hns/extcon', 'work/hns/mtd/onenand', 'work/kemnade/wifi-sdio-fixes-v3', 'work/hns/input/as5013', 'work/andrey/input/as5013', 'work/hns/power/bq2429x', 'work/hns/sound/ts3a225e', 'work/hns/mmc/txs02612', 'work/hns/video/ov9655', 'work/hns/input/crtouch-v2', 'work/hns/mips/mini-pm', 'work/hns/mips/minibook', 'work/test/bno055', 'work/marek/am335x-hwmon', 'work/hns/video/dss/panels+ssd2858', 'work/test/sgx544-v2' and 'work/hns/hw-test' into letux-4.10-rc6 [OK] 21:51:12 Mon 30 Jan j@dell-m4800 /src/linux $ git merge letux/work/test/tiler

Ah.

I had tried to merge some work/tiler-v2 branch I have in my local branches list. I do not remember what it is... Seems to be some 4.8-rc4 based stuff.

So this I had done the wrong merge. With letux/work/test/tiler I get the same merge success.

Merge made by the 'recursive' strategy. arch/arm/include/asm/pgtable.h | 3 +++ arch/arm/mach-omap2/omap-smp.c | 51 +++++++++++++++++++++++++++++++++++----------------

^^^ this file leads to a compile error:

CC arch/arm/mach-omap2/omap-smp.o - due to: arch/arm/mach-omap2/omap-smp.c arch/arm/include/asm/pgtable.h include/linux/clk/ti.h arch/arm/mach-omap2/omap-smp.c: In function 'omap4_smp_prepare_cpus': arch/arm/mach-omap2/omap-smp.c:301:3: error: too few arguments to function 'omap5_erratum_workaround_801819' omap5_erratum_workaround_801819(); ^ arch/arm/mach-omap2/omap-smp.c:76:13: note: declared here static void omap5_erratum_workaround_801819(unsigned int cpu, u32 *acr) ^ arch/arm/mach-omap2/omap-smp.c:325:3: error: 'startup_addr' undeclared (first use in this function) startup_addr = omap4460_secondary_startup; ^ arch/arm/mach-omap2/omap-smp.c:325:3: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [arch/arm/mach-omap2/omap-smp.o] Error 1 make[1]: *** [arch/arm/mach-omap2] Error 2 make: *** [__build_one_by_one] Error 2

drivers/gpu/drm/omapdrm/omap_gem.c | 30 +++++++++++++++++++----------- include/uapi/drm/omap_drm.h | 12 ++++++++---- 4 files changed, 65 insertions(+), 31 deletions(-) [OK] 21:51:32 Mon 30 Jan j@dell-m4800 /src/linux $ git rev-parse letux/work/test/tiler f72f7f29330518ffa86f8fde7829b17109459bb9

BR, Nikolaus

Hi Matthijs,

Am 31.01.2017 um 08:48 schrieb Matthijs van Duin matthijsvanduin@gmail.com:

Please don't merge my work/* branches, they are where I gather a varied pile of Stuff™ to test a kernel and they were not designed with merging in mind. Instead, merge or rebase the relevant patch/* branches.

Ah,ok. I haven't updated my local copies of your branches for a while. So maybe the compile error I reported one mail ago might already be fixed.

The main patch series is: • master # (baseline for patches) • patch/tiler-memtype # fix memtype for tiler memory • patch/tiler-fast # all tiler performance fixes combined • patch/tiler-buf-fbdev # force legacy fbdev into tiler memory • patch/tiler-fbdev # add hacky rotation mechanism via kernel parameter Merging patch/tiler-fbdev suffices since this implicitly includes the earlier patches.

Some independent patches of interest that should be safe to merge are: • patch/omap-l3 # make the mostly-useless l3 intercon driver optional • patch/fast-nc-read # tiler-unrelated speedup for omap5/dra7 • patch/of-alias # some fixes for unreliable device numbering Don't merge patch/tiler-buf-dumb: it forces "dumb buffers" to be allocated in tiler memory, but this is rude and unnecessary, and it breaks SGX.

Ok. I'll give it a try asap.

BR and thanks, Nikolaus

On 01/31/2017 05:28 PM, H. Nikolaus Schaller wrote:

I now pulled your patch/tiler-fbdev and rebased to letux-base (which is linus/v4.10-rc6 plus some other stuff), had to fix a rebase conflict in drivers/gpu/drm/drm_fb_helper.c because DRM_ROTATE_0 was being changed upstream and had fixed another issue [1]. Then I could merge it fine [2] :)

Now it compiles and the kernel boots. But still shows an unrotated panel. Maybe some config or command line tool missing to setup the tiler to rotate?

from my tiler notes:

# change by reloading module (needed to fix fbdev dimension if width/height swapped) echo 0 >/sys/class/vtconsole/vtcon1/bind modprobe -r omapdrm modprobe drm_kms_helper fbdev_rotation=8 modprobe omapdrm

# change without reloading echo 2 >/sys/module/drm_kms_helper/parameters/fbdev_rotation true <>/dev/dri/card0 ---- kernel cmdline : drm_kms_helper.fbdev_rotation

0 0 2 90 ccw 4 180 8 270

On pyraos im using a systemd service that runs this script at boot:

#!/bin/sh echo 0 >/sys/class/vtconsole/vtcon1/bind modprobe -r omapdrm modprobe drm_kms_helper fbdev_rotation=8 modprobe omapdrm cat /dev/dri/card0 > /dev/null &

The last line is a hack to stop the screen from turning off after a few seconds, haven't found out exactly why, but this stops it from happening.

Hi,

Am 31.01.2017 um 19:36 schrieb H. Nikolaus Schaller hns@goldelico.com:

Hi,

...

Am 31.01.2017 um 19:22 schrieb aTc atc@k-n-p.org:

On 01/31/2017 05:28 PM, H. Nikolaus Schaller wrote:

...

I now pulled your patch/tiler-fbdev and rebased to letux-base (which is linus/v4.10-rc6 plus some other stuff), had to fix a rebase conflict in drivers/gpu/drm/drm_fb_helper.c because DRM_ROTATE_0 was being changed upstream and had fixed another issue [1]. Then I could merge it fine [2] :)

Now it compiles and the kernel boots. But still shows an unrotated panel. Maybe some config or command line tool missing to setup the tiler to rotate?

from my tiler notes:

# change by reloading module (needed to fix fbdev dimension if width/height swapped) echo 0 >/sys/class/vtconsole/vtcon1/bind modprobe -r omapdrm modprobe drm_kms_helper fbdev_rotation=8 modprobe omapdrm

# change without reloading echo 2 >/sys/module/drm_kms_helper/parameters/fbdev_rotation true <>/dev/dri/card0

---

kernel cmdline : drm_kms_helper.fbdev_rotation

0 0 2 90 ccw 4 180 8 270

On pyraos im using a systemd service that runs this script at boot:

#!/bin/sh echo 0 >/sys/class/vtconsole/vtcon1/bind modprobe -r omapdrm modprobe drm_kms_helper fbdev_rotation=8 modprobe omapdrm cat /dev/dri/card0 > /dev/null &

The last line is a hack to stop the screen from turning off after a few seconds, haven't found out exactly why, but this stops it from happening.

So this means that PyraOS would already do the right thing?

I have a SD card with PyraOS (don't remember exactly which version) and would just have to install the latest kernel. Or I make a new one.

Well, the result is interesting. Before I installed the latest kernel I got the pyra logo and a window - but unrotated.

Now I get a pyra_install login: on tty1 - but rotated upside down :) And it reacts to keyboard...

So X11 is not booting (maybe my patched kernel has damaged something in the X11 setup). But it seems to be rotating.

And I think I will also go the helper script approach. It can be extended to check the DT if it is configured for SSD2858 rotation and then skip the tiler.

So I would keep an universal system that runs on all combinations for cross-testing, even on the OMAP5432EVM.

I have added this to my rootfs (wasn't difficult), but still get no sign of rotation.

drm_kms_helper gets the right fbdev_rotation=8

root@letux:~# grep '' /sys/module/drm_kms_helper/parameters/* /sys/module/drm_kms_helper/parameters/dp_aux_i2c_speed_khz:10 /sys/module/drm_kms_helper/parameters/dp_aux_i2c_transfer_size:16 /sys/module/drm_kms_helper/parameters/fbdev_emulation:Y /sys/module/drm_kms_helper/parameters/fbdev_rotation:8 /sys/module/drm_kms_helper/parameters/poll:Y root@letux:~# grep '' /sys/module/omapdrm/parameters/* /sys/module/omapdrm/parameters/num_crtc:2 /sys/module/omapdrm/parameters/ywrap:Y root@letux:~#

Or is the tiler rotating the HDMI port which is also enabled in my setup?

BR, Nikolaus

Hi Matthijs,

Am 01.02.2017 um 18:37 schrieb Matthijs van Duin matthijsvanduin@gmail.com:

On 1 February 2017 at 14:49, H. Nikolaus Schaller hns@goldelico.com wrote: Or is the tiler rotating the HDMI port which is also enabled in my setup?

It rotates any output of the legacy fbdev framebuffer, of which there is only one per DRM device. I'm not sure which output it will pick if more than one is connected.

Ah, I see. I am not using fbdev for X11 because it did not work any more with debian jessie.

This would explain why I got a rotated console but no rotated pyra logo on my patched PyraOS image (X11 was broken and hence the console became visible).

Applications that perform DRM modesetting does not get automatically rotated currently, but they can request any rotation of a framebuffer via the DRM api provided the buffer is allocated in tiler memory. Either they can use libdrm-omap for that allocation (like e.g. the xorg-video-omap driver) or you can apply my patch/tiler-buf-dumb to force all buffer allocations into tiler memory.

Since I use the xorg-video-omap driver the best thing seems to be to try the patch. And if I understand the recommendations correctly, then xrandr should be able to rotate or who else is controlling the DRM api?

I've considered implementing rotation transparently for all drm clients (including the legacy fbdev), and I still may, but it is a non-trivial amount of work and may not be worth it since only one process can do modesetting at any given time, so normally this task in centralized in one of a very small number of applications (x11, wayland, plymouth...) and they all use libdrm so it could also be implemented there instead.

I also see it not as the most urgent task. I just want to hack a working demo/testing setup...

BR and thanks, Nikolaus

Am 01.02.2017 um 22:55 schrieb Matthijs van Duin matthijsvanduin@gmail.com:

On 1 February 2017 at 20:48, H. Nikolaus Schaller hns@goldelico.com wrote: Since I use the xorg-video-omap driver the best thing seems to be to try the patch. And if I understand the recommendations correctly, then xrandr should be able to rotate or who else is controlling the DRM api?

if you're using xorg-video-omap then you can already use xrandr to rotate the screen. This even worked before my patches, except it was very slow.

Really? Last time I tried (maybe 1-2 years ago) it was rejected as not implemented. Maybe it depends on the panel driver to support rotation.

Now I have tested with running

xrandr --output HDMI-1 --auto --rotate left

which did rotate the HDMI out :)

And for LCD I was able to rotate as well:

xrandr --output Unknown16-1 --auto --rotate right

Operation appears to be fast, but I have not done any speed test. So I don't know if the Tiler is running at all or how this rotation works.

One issue is that the LXDE desktop does not know about rotation and the toolbar line is rotated off-screen...

Probably I should run xrandr for LCD rotation before starting X, but X is needed to run xrandr :(

Is there a command line tool to achieve the same without X so that it can configure rotation before X is started?

BR and thanks, Nikolaus