Hi Matthijs,
Am 14.02.2017 um 04:18 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
Nikolaus, when I tried to merge my rebased patch branches into letux-4.10-rc8 I got a big mess of merge conflicts because you merged previous patches from me into it already. Please don't.
You can merge your own letux-4.10-rc8 from all branches by using the Letux/scripts/merge script and the mergefile (potentially modified): http://download.goldelico.com/letux-kernel/letux-4.10-rc8/src/mergefile
The problem we have here is that we are not working on the same base.
letux-4.10-rc8 is build from v4.10-rc8 merged into letux-base and a big set of feature branches based on letux-base. This is similar to how linux/next is piled up. There you have the same problem if you want to change patches already merged.
So if possible development should not be done on top of letux-4.10-rc8 but on letux-base while merging your own version.
What also works quite well is if you develop patches on top of letux-4.10-rc8 and cherry-pick them into the feature branch for later inclusion.
This model is a little difficult to manage, but has turned out to be the only one that works in practise if there is more than one developer. When we have upstreamed as many such feature branches as possible, then we could assume linus/master to be the common base and work more independently.
On 10 February 2017 at 11:37, H. Nikolaus Schaller hns@goldelico.com wrote: It is easy to remove them completely
Please do so from your main letux branch while the patches are still in development, I'm currently relying on it being a (or rather the only) known-working kernel for the pyra which I can use to test my patches.
Yes, a big task of upstreaming work is still ahead of us. Especially device tree sources and the bq2429x driver are the key components.
but then we have no default kernel to test the Pyra with properly rotated screen.
You can make such a kernel at any time by merging the latest version of my patch/tiler-fbdev into the base letux kernel.
That is what the merge script should do. But it can't pick the latest version from remote repositories. And it does only if manually triggered (once a week). Btw. it can handle -v3 suffixes to find the latest of multiple versions.
I also explicitly mentioned patch/tiler-buf-dumb should not be merged at all, not even for pyra.
Treat it as my attempt to do a quality assessment...
What part about "should not be merged at all" is so hard to get?
Well, I read it this way:
Am 01.02.2017 um 18:37 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
On 1 February 2017 at 14:49, H. Nikolaus Schaller hns@goldelico.com wrote:
Applications that perform DRM modesetting does not get automatically rotated currently, but they can request any rotation of a framebuffer via the DRM api provided the buffer is allocated in tiler memory. Either they can use libdrm-omap for that allocation (like e.g. the xorg-video-omap driver) or you can apply my patch/tiler-buf-dumb to force all buffer allocations into tiler memory.
From that I did read that I should better apply this patch to get rotation working. Maybe I misunderstood because I am not that deeply experienced in the details as you are.
I don't need a quality assessment of it, I'm perfectly aware that it is neither necessary nor useful for the rotated fbdev, breaks all dma-buf clients of omapdrm (including SGX) on targets with tiler, and breaks omapdrm almost entirely on targets without tiler.
PLEASE STOP MERGING THAT PATCH.
There is no need to shout...
I have removed it from the mergefile and rebuilt -rc8 (this is what -rc are good for to find out software integration problems).
What is the alternative to configure the tiler from user-space?
BR, Nikolaus