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...