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