[Letux-kernel] tiled fbdev
H. Nikolaus Schaller
hns at goldelico.com
Mon Sep 5 18:43:06 CEST 2016
> Am 28.08.2016 um 02:08 schrieb Matthijs van Duin <matthijsvanduin at 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:
> 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'
> 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),
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:
> 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_TPS51632 is not set
# 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.
BR and thanks,
PS: is there a working update for the SGX544 drivers?
More information about the Letux-kernel