OK, thanks to Andrey Utkin the DSS regression has been fixed, and for some reason after I merged letux-4.8-rc1 with latest mainline 4.8-rc and did some minor kernel config cleanups I discovered sound was working again too. Haven't bisected it, I'm just glad it works again.
I have a revised patch/tiler-fbdev (note: the "2" suffix is gone) which makes the fbdev rotation a module parameter. Tiny change, but a fair bit more convenient than having to recompile the kernel.
To rotate the screen clockwise add the kernel parameter: drm_kms_helper.fbdev_rotation=8
Alternatively you can change it at runtime by doing, e.g.: echo 0 >/sys/class/vtconsole/vtcon1/bind modprobe -r omapdrm modprobe drm_kms_helper fbdev_rotation=8 modprobe omapdrm
Changing the rotation in a way that doesn't swap width/height is even possible on the fly: echo 2 >/sys/module/drm_kms_helper/parameters/fbdev_rotation true <>/dev/dri/card0 # trigger modeset-restore
Rotation values are same as for the DRM "rotation" property: 1 = 0 degrees 2 = 90 degrees (CCW) 4 = 180 degrees 8 = 270 degrees (i.e. 90 degrees CW) (bit 4 or 5 can be set for mirroring)
Some git repo news:
work/merged is currently work/merged-base (see below) + work/omap5-uevm (some DT patches, mainly for leds) + patch/tiler-fbdev (see above). Note that even with rotation disabled the framebuffer is still allocated in tiled memory, making it suitable for performance tests.
patch/tiler-fast (which is part of patch/tiler-fbdev) no longer forces tiled allocation of DRM dumb buffers. I've put this in a separate branch for now, patch/tiler-buf-dumb, since I haven't needed it recently and it breaks SGX.
work/merged-base is a new branch currently consisting of letux-4.8-rc1 with latest mainline 4.8-rc merged in along with some benign patches of mine. I've also polished the letux_defconfig a bit to remove stuff irrelevant to omap5 and some other changes here and there. I try to keep invasive stuff that might break things out of this branch. If you discover work/merged-base breaks something that worked in letux (on omap5-uevm or pyra), please let me know.
Matthijs
Wow cool! I wish I could be back earlier to immediately integrate into letux-rc... Is it possible to define default rotation as a (Pane?l) DT property?
On the Road --- hns
Am 28.08.2016 um 02:08 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
OK, thanks to Andrey Utkin the DSS regression has been fixed, and for some reason after I merged letux-4.8-rc1 with latest mainline 4.8-rc and did some minor kernel config cleanups I discovered sound was working again too. Haven't bisected it, I'm just glad it works again.
I have a revised patch/tiler-fbdev (note: the "2" suffix is gone) which makes the fbdev rotation a module parameter. Tiny change, but a fair bit more convenient than having to recompile the kernel.
To rotate the screen clockwise add the kernel parameter: drm_kms_helper.fbdev_rotation=8
Alternatively you can change it at runtime by doing, e.g.: echo 0 >/sys/class/vtconsole/vtcon1/bind modprobe -r omapdrm modprobe drm_kms_helper fbdev_rotation=8 modprobe omapdrm
Changing the rotation in a way that doesn't swap width/height is even possible on the fly: echo 2 >/sys/module/drm_kms_helper/parameters/fbdev_rotation true <>/dev/dri/card0 # trigger modeset-restore
Rotation values are same as for the DRM "rotation" property: 1 = 0 degrees 2 = 90 degrees (CCW) 4 = 180 degrees 8 = 270 degrees (i.e. 90 degrees CW) (bit 4 or 5 can be set for mirroring)
Some git repo news:
work/merged is currently work/merged-base (see below)
- work/omap5-uevm (some DT patches, mainly for leds)
- patch/tiler-fbdev (see above).
Note that even with rotation disabled the framebuffer is still allocated in tiled memory, making it suitable for performance tests.
patch/tiler-fast (which is part of patch/tiler-fbdev) no longer forces tiled allocation of DRM dumb buffers. I've put this in a separate branch for now, patch/tiler-buf-dumb, since I haven't needed it recently and it breaks SGX.
work/merged-base is a new branch currently consisting of letux-4.8-rc1 with latest mainline 4.8-rc merged in along with some benign patches of mine. I've also polished the letux_defconfig a bit to remove stuff irrelevant to omap5 and some other changes here and there. I try to keep invasive stuff that might break things out of this branch. If you discover work/merged-base breaks something that worked in letux (on omap5-uevm or pyra), please let me know.
Matthijs
Hi Matthijs,
Am 28.08.2016 um 02:08 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
OK, thanks to Andrey Utkin the DSS regression has been fixed, and for some reason after I merged letux-4.8-rc1 with latest mainline 4.8-rc and did some minor kernel config cleanups I discovered sound was working again too. Haven't bisected it, I'm just glad it works again.
I think sound not working was spurious in -rc1.
I have a revised patch/tiler-fbdev (note: the "2" suffix is gone) which makes the fbdev rotation a module parameter. Tiny change, but a fair bit more convenient than having to recompile the kernel.
Well, kernel parameters are IMHO very old style. I think the better way would be to have some DT property which defines that a panel is mounted rotated. Similar to an touch screen swap-x-y flag.
Then we also don't have to recompile the kernels. Just load this or that DT variant. Or can even modify by DT overlays or ftd tools in u-boot.
To rotate the screen clockwise add the kernel parameter: drm_kms_helper.fbdev_rotation=8
Alternatively you can change it at runtime by doing, e.g.: echo 0 >/sys/class/vtconsole/vtcon1/bind modprobe -r omapdrm modprobe drm_kms_helper fbdev_rotation=8 modprobe omapdrm
Changing the rotation in a way that doesn't swap width/height is even possible on the fly: echo 2 >/sys/module/drm_kms_helper/parameters/fbdev_rotation true <>/dev/dri/card0 # trigger modeset-restore
That is cool!
Rotation values are same as for the DRM "rotation" property: 1 = 0 degrees 2 = 90 degrees (CCW) 4 = 180 degrees 8 = 270 degrees (i.e. 90 degrees CW) (bit 4 or 5 can be set for mirroring)
that looks like a strange encoding for a rotation angle... Can you mix 90 and 270?
Some git repo news:
work/merged is currently work/merged-base (see below)
- work/omap5-uevm (some DT patches, mainly for leds)
- patch/tiler-fbdev (see above).
Note that even with rotation disabled the framebuffer is still allocated in tiled memory, making it suitable for performance tests.
patch/tiler-fast (which is part of patch/tiler-fbdev) no longer forces tiled allocation of DRM dumb buffers. I've put this in a separate branch for now, patch/tiler-buf-dumb, since I haven't needed it recently and it breaks SGX.
Great! I have merged them into letux-4.8-rc5.
But I might have forgotten something or made a mistake during integration, because I get this compile error:
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
This might help to identify the conflicting patches and how to fix it:
hns$ git blame arch/arm/mach-omap2/omap-smp.c | fgrep omap5_erratum_workaround_801819 89c9fb83 (Matthijs van Duin 2016-07-16 13:47:07 +0200 76) static void omap5_erratum_workaround_801819(unsigned int cpu, u32 *acr) 89c9fb83 (Matthijs van Duin 2016-07-16 13:47:07 +0200 97) static inline void omap5_erratum_workaround_801819(unsigned int cpu, u32 *acr) 89c9fb83 (Matthijs van Duin 2016-07-16 13:47:07 +0200 111) omap5_erratum_workaround_801819(cpu, &acr); 32518852 (Tony Lindgren 2016-06-22 01:59:40 -0700 301) omap5_erratum_workaround_801819(); hns$ git blame arch/arm/mach-omap2/omap-smp.c | fgrep startup_addr 32518852 (Tony Lindgren 2016-06-22 01:59:40 -0700 47) void *startup_addr; 32518852 (Tony Lindgren 2016-06-22 01:59:40 -0700 54) .startup_addr = omap4_secondary_startup, 32518852 (Tony Lindgren 2016-06-22 01:59:40 -0700 59) .startup_addr = omap4460_secondary_startup, 32518852 (Tony Lindgren 2016-06-22 01:59:40 -0700 64) .startup_addr = omap5_secondary_startup, 32518852 (Tony Lindgren 2016-06-22 01:59:40 -0700 296) cfg.startup_addr = c->startup_addr; 32518852 (Tony Lindgren 2016-06-22 01:59:40 -0700 300) cfg.startup_addr = omap5_secondary_hyp_startup; 89c9fb83 (Matthijs van Duin 2016-07-16 13:47:07 +0200 325) startup_addr = omap4460_secondary_startup; 32518852 (Tony Lindgren 2016-06-22 01:59:40 -0700 338) omap_auxcoreboot_addr(virt_to_phys(cfg.startup_addr)); 32518852 (Tony Lindgren 2016-06-22 01:59:40 -0700 340) writel_relaxed(virt_to_phys(cfg.startup_addr), hns$
Please check with Tony how to fix it - I do not understand enough to find the correct resolution.
Checkout latest letux-4.8-rc5 and work/test/tiler and merge the latter:
http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/letux-4... http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/te...
work/merged-base is a new branch currently consisting of letux-4.8-rc1 with latest mainline 4.8-rc merged in along with some benign patches of mine.
I've also polished the letux_defconfig a bit to remove stuff irrelevant to omap5 and some other changes here and there.
Well, please rename the config to a private one (pyraonly_defconfig?).
The core principle of letux_defconfig is to support a multitude of devices (e.g. OpenPandora, PandaBoard, GTA04, uEVM, Pyra, BeagleBone, ...) with the same kernel binary and modules.tgz. This allows swapping SD cards between devices (and solves the nightmare to point people to the correct download link for their specific device) and heavily simplifies writing generic user-space code which sometimes has assumptions about availability of kernel features.
So these configs shouldn't be removed or changed in letux_defconfig if any platform needs them available in a specific way. Fortunately, conflicts are rare and most drivers are loadable kernel modules.
One patch you have for letux_defconfig is really interesting:
# CONFIG_REGULATOR_PV88080 is not set # CONFIG_REGULATOR_PV88090 is not set # CONFIG_REGULATOR_PWM is not set -# CONFIG_REGULATOR_TI_ABB is not set +CONFIG_REGULATOR_TI_ABB=y # CONFIG_REGULATOR_TPS51632 is not set CONFIG_REGULATOR_TPS6105X=m # CONFIG_REGULATOR_TPS62360 is not set
Looking into the description of the CONFIG:
"It is recommended that this option be enabled on required TI SoC. Certain Operating Performance Points on TI SoCs may be unstable without enabling this as it provides device specific optimized bias to allow/optimize functionality."
Sounds like our 1.5GHz OPP problem...
Unfortunately, I can't test if it makes a difference because I currently have no working Pyra hardware here and the EVM was (almost) stable for me.
I don't know when and why it was disabled (probably because it was never enabled when introduced...). So I have applied it anyways. Should not harm.
If you have some changes that are required or should be changed in letux_defconfig, please let's discuss the reasons to avoid that we break a non-OMAP5 device.
I try to keep invasive stuff that might break things out of this branch. If you discover work/merged-base breaks something that worked in letux (on omap5-uevm or pyra), please let me know.
Matthijs
BR and thanks, Nikolaus
PS: is there a working update for the SGX544 drivers? http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/te...
Limited time right now, but I'll at least reply to a few things:
On 5 September 2016 at 18:43, H. Nikolaus Schaller hns@goldelico.com wrote:
Well, kernel parameters are IMHO very old style. I think the better way
As I've pointed out more than once these are just dirty hacks to get things into a state where testing could be done with TILER-based rotation. I even marked the hacky commits with XXX in the subject line to discourage merging.
The kernel param was simply the closest thing within reach of copy-paste to at least let me avoid the need to recompile.
Of course it /should/ be handled by the panel advertising its native orientation via DT, although I'm not quite decided yet on which code can and should carry the responsibility of taking it into account. Right now I hacked it into drm_kms_helper but that's just for legacy fbdev, which we may want to ditch altogether sooner or later. In fact sorting out how we want to organise userspace w.r.t graphics is much higher on my priority list right now then cleaning up my patches.
In principle the kernel could completely hide the true orientation of the panel from userspace, but it would be non-trivial, break libdrm-omap (don't really care about that though), and unnecessarily decrease 3D performance (compared to allocating non-tiled buffers and reporting the screen rotation from the WSEGL backend in userspace).
Rotation values are same as for the DRM "rotation" property:
that looks like a strange encoding for a rotation angle
Yeah it's a bit dirty but it lets DRM use a bitmask property type to indicate which orientations are actually supported.
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();
I've only touched that file in patch/fast-nc-read (commit 912c3f254c9e), which applies cleanly against mainline rc5 for me.
Note that this patch is a performance enhancement separate from TILER work.
I've also polished the letux_defconfig a bit to remove stuff irrelevant to omap5 and some other changes here and there.
Well, please rename the config to a private one (pyraonly_defconfig?).
Will do.
The core principle of letux_defconfig is to support a multitude of devices
Keep in mind that 4GB of ram in the Pyra will mean an LPAE kernel is required, which will not boot at all on cortex-a8/a9 devices.
Matthijs
Hi Matthijs,
Am 05.09.2016 um 23:13 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
Limited time right now, but I'll at least reply to a few things:
no problem.
I did need 4 weeks to merge 3 patches... So I don't expect 4 fixes in 3 hours :)
On 5 September 2016 at 18:43, H. Nikolaus Schaller hns@goldelico.com wrote:
Well, kernel parameters are IMHO very old style. I think the better way
As I've pointed out more than once these are just dirty hacks to get things into a state where testing could be done with TILER-based rotation.
Yes, I know. And I want to start testing.
I even marked the hacky commits with XXX in the subject line to discourage merging.
Indeed my work on rc5 is just to prepare for final merging (hopefully soon) and do some testing. So that we have a working reference system (not necessarily optimized but working) as soon as the first Pyra devices come from production.
An to test if I can replace the branch in the letux git repo with any newer version as it arrives.
The kernel param was simply the closest thing within reach of copy-paste to at least let me avoid the need to recompile.
Yes, it is easier to hack into an arbitrary driver than DT properties.
Of course it /should/ be handled by the panel advertising its native orientation via DT, although I'm not quite decided yet on which code can and should carry the responsibility of taking it into account. Right now I hacked it into drm_kms_helper but that's just for legacy fbdev, which we may want to ditch altogether sooner or later. In fact sorting out how we want to organise userspace w.r.t graphics is much higher on my priority list right now then cleaning up my patches.
Ok, I see. Well, I had though that I can help with testing, but in the current state I don't even know how to set it up...
In principle the kernel could completely hide the true orientation of the panel from userspace,
That would be nice.
but it would be non-trivial, break libdrm-omap (don't really care about that though), and unnecessarily decrease 3D performance (compared to allocating non-tiled buffers and reporting the screen rotation from the WSEGL backend in userspace).
Ok, but unless it needs modifying drivers and tools I would (initially) sacrifice optimal performance for having a robust and working basic setup.
Rotation values are same as for the DRM "rotation" property:
that looks like a strange encoding for a rotation angle
Yeah it's a bit dirty but it lets DRM use a bitmask property type to indicate which orientations are actually supported.
Ah, I see.
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();
I've only touched that file in patch/fast-nc-read (commit 912c3f254c9e), which applies cleanly against mainline rc5 for me.
Note that this patch is a performance enhancement separate from TILER work.
Hm. I have just merged your patch/tiler-fbdev on top of letux-4.8-rc5 which also includes mainline rc5. At least I assume that is what I have done...
Maybe there is an effect by the sequence of merges being applied? Or rebasing did mangle up something?
Probably I should simply git diff work/merged-base arch/arm/mach-omap2/omap-smp.c To see how it should be.
I've also polished the letux_defconfig a bit to remove stuff irrelevant to omap5 and some other changes here and there.
Well, please rename the config to a private one (pyraonly_defconfig?).
Will do.
The core principle of letux_defconfig is to support a multitude of devices
Keep in mind that 4GB of ram in the Pyra will mean an LPAE kernel is required, which will not boot at all on cortex-a8/a9 devices.
Well, since we don't have working 4GB hardware yet, I didn't care about yet.
But having LPAE enabled for one set of devices and disabled for the other set makes it much more difficult to maintain. Maintaining two defconfigs in parallel is probably not what we want. So we might have to compile twice after running sed on .config and emit an uImage and an uImage-lpae. Then U-Boot can decide which uImage variant to load on a specific device from the given /boot on the booted rootfs. This would maintain swappability between different OMAP generations.
So I think this can be solved. Unless LPAE has an influence on kernel modules. Does it? Then we would also need two sets of /lib/modules and add a proper kernel name suffix.
BR, Nikolaus
-
Dr. H. Nikolaus Schaller -
H. Nikolaus Schaller
-
Matthijs van Duin