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