Hi Andreas,
Am 08.02.2017 um 06:52 schrieb Andreas Kemnade andreas@kemnade.info:
Hi,
As I wanted to test the new alsa routing patches, there was one problem: No Framebuffer output,
Suspicious pieces in console log: [ 2.556823] omapdrm omapdrm.0: DMM not available, disable DMM support [ 2.565490] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 2.565551] [drm] No driver support for vblank timestamp query. [ 2.566528] omapdrm omapdrm.0: Tiled buffers require DMM [ 2.567382] omapdrm omapdrm.0: failed to allocate buffer object [ 2.567718] omapdrm omapdrm.0: omap_fbdev_init failed [ 2.567932] [drm] Initialized omapdrm 1.0.0 20110917 on minor 0
I have to add that I have compiled the framebuffer statically and using it for console output.
After reverting the following branches, the framebuffer worked again.
extern/mvduin/patch/tiler-buf-dumb extern/mvduin/patch/tiler-fbdev
Thanks for noting!
This means the TILER should somehow be made OMAP5 (Pyra) only or fixed to gracefully handle OMAP3.
BR and thanks, Nikolaus
On 8 February 2017 at 07:19, H. Nikolaus Schaller hns@goldelico.com wrote:
After reverting the following branches, the framebuffer worked again.
extern/mvduin/patch/tiler-buf-dumb extern/mvduin/patch/tiler-fbdev
Oh come on Nikolaus, I've tried to make clear that these are really dirty hacks that are for testing/demo purposes, you should never have merged these into a tree intended for general use.
I also explicitly mentioned patch/tiler-buf-dumb should not be merged at all, not even for pyra.
Matthijs
Hi,
Am 10.02.2017 um 09:29 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
On 8 February 2017 at 07:19, H. Nikolaus Schaller <hns@goldelico.com mailto:hns@goldelico.com> wrote:
After reverting the following branches, the framebuffer worked again.
extern/mvduin/patch/tiler-buf-dumb extern/mvduin/patch/tiler-fbdev
Oh come on Nikolaus, I've tried to make clear that these are really dirty hacks that are for testing/demo purposes,
Well, I have simply forgotten your advice... And obviously I assumed it is in a better state than it now looks to be. So Andreas did stumble over the OMAP3 issue in letux-4.10-rc6 (we are still in -rc phase).
you should never have merged these into a tree intended for general use.
It is easy to remove them completely - but then we have no default kernel to test the Pyra with properly rotated screen.
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...
But IMHO the best step forwards would be to provide a better patch (even if it is still a hack) since we urgently need something to show around.
Well, I still have one old pyra with ssd rotator. It is also a big hack but works.
BR and thanks, Nikolaus
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.
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.
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.
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?
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.
Matthijs
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
-
H. Nikolaus Schaller -
Matthijs van Duin