| Message ID | m337yp5gvv.fsf@t19.piap.pl (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Am Dienstag, den 08.09.2015, 12:45 +0200 schrieb Krzysztof Ha?asa: > Trying to make some progress... I was missing the etnaviv DRM kernel > driver. Now I have both IMX and etnaviv drivers, Linux v4.0-stable: > > git://git.pengutronix.de/git/lst/linux.git (etnaviv DRM driver) > PLL5 DTS patch (enables HDMI with LVDS driver loaded): > > --- a/arch/arm/boot/dts/imx6q-gw54xx.dts > +++ b/arch/arm/boot/dts/imx6q-gw54xx.dts > @@ -21,3 +21,11 @@ > &sata { > status = "okay"; > }; > + > +&clks { > + assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>, > + <&clks IMX6QDL_CLK_LDB_DI1_SEL>; > + assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>, > + <&clks IMX6QDL_CLK_PLL3_USB_OTG>; > +}; > + > > also had to apply: > > --- a/drivers/staging/etnaviv/Makefile > +++ b/drivers/staging/etnaviv/Makefile > @@ -11,7 +11,6 @@ etnaviv-y := \ > etnaviv_gem_submit.o \ > etnaviv_gpu.o \ > etnaviv_iommu.o \ > - etnaviv_iommu_v2.o \ > etnaviv_mmu.o \ > etnaviv_buffer.o > > > X.org etc.: > git://github.com/laanwj/etna_viv.git > git://ftp.arm.linux.org.uk/~rmk/libdrm-armada.git/ > git://ftp.arm.linux.org.uk/~rmk/xf86-video-armada.git unstable-devel > (I can't use master branch of xf86-video-armada.git because it doesn't > support etnaviv - does it?) > > X log (relevant(?) stuff only): > > [ 18919.848] (II) armada(0): hardware: imx-drm > [ 18919.923] (--) armada(0): Vivante GC320 GPU revision 5007 (etnaviv) 2d PE2.0 > [ 18919.925] (II) armada(0): [DRI2] Setup complete > [ 18919.925] (II) armada(0): [DRI2] DRI driver: etnadrm > [ 18919.925] (II) armada(0): direct rendering: DRI2 enabled > [ 18919.925] (II) armada(0): RandR 1.2 enabled, ignore the following RandR disabled message. > [ 18919.927] (==) armada(0): DPMS enabled > [ 18919.927] (==) armada(0): hotplug detection enabled > [ 18919.928] (II) armada(0): etnaviv: Xv: using YUY2 tiled format intermediate YUV target > [ 18919.971] (EE) AIGLX error: dlopen of /lib/dri/etnadrm_dri.so failed (I don't have this yet) > [ 18920.072] (II) armada(0): etnaviv: A8 target not supported > > If I try to use pengutronix/etnaviv-4.1-wip branch (etnaviv DRM - for > v4.2), dmesg contains a lot of: > [drm:etnaviv_ioctl_gem_submit [etnaviv]] *ERROR* cmdstream bo has flag ETNA_BO_CMDSTREAM not set > and it doesn't work. I assume I shouldn't use it yet? > You need changes to the X.Org driver for that to work. I'm currently working on a new version of the etnaviv-drm driver which will break the kernel userspace interface another time - hopefully for the last time now. I'm almost done and will publish patches for both the kernel and the X.Org driver today. > Changing to pengutronix/etnaviv-for-upstream, it works - sort of. > > I now have two Xvideo adapters: > Adaptor: 0 > Name: Marvell Armada Overlay Video > Port: 88 > (which unfortunately doesn't work, the window is black, the XV > attributes are set to minimums and I can't set them). > > Is it expected? > This is expected, it's the overlay adapter which doesn't really work with imx-drm yet. Regards, Lucas
On Tue, Sep 08, 2015 at 12:56:18PM +0200, Lucas Stach wrote: > This is expected, it's the overlay adapter which doesn't really work > with imx-drm yet. No, it's imx-drm which isn't working. As I explained in my previous email, overlay planes are expected to do scaling. imx-drm errors out attempts for that. This is a kernel bug, not an Xorg driver bug.
Lucas Stach <l.stach@pengutronix.de> writes: >> [drm:etnaviv_ioctl_gem_submit [etnaviv]] *ERROR* cmdstream bo has flag ETNA_BO_CMDSTREAM not set >> and it doesn't work. I assume I shouldn't use it yet? >> > You need changes to the X.Org driver for that to work. I'm currently > working on a new version of the etnaviv-drm driver which will break the > kernel userspace interface another time - hopefully for the last time > now. > > I'm almost done and will publish patches for both the kernel and the > X.Org driver today. Great, I'm looking forward to be the first guinea pig :-) Thanks.
Am Dienstag, den 08.09.2015, 12:01 +0100 schrieb Russell King - ARM Linux: > On Tue, Sep 08, 2015 at 12:56:18PM +0200, Lucas Stach wrote: > > This is expected, it's the overlay adapter which doesn't really work > > with imx-drm yet. > > No, it's imx-drm which isn't working. As I explained in my previous > email, overlay planes are expected to do scaling. imx-drm errors out > attempts for that. This is a kernel bug, not an Xorg driver bug. > I would argue that this is a bug of the interface between kernel and userspace. Scaling isn't something that can be expected to be usable on every hardware (and in fact the IPU isn't able to do arbitrary scaling with its 1024 in/out pixel constraints), but there is no clear way to communicate this to userspace other than flat out rejecting the plane update. Atomic may provide some better ways, but we are not there yet for imx-drm. Regards, Lucas
On Tue, Sep 08, 2015 at 01:07:47PM +0200, Lucas Stach wrote: > Am Dienstag, den 08.09.2015, 12:01 +0100 schrieb Russell King - ARM > Linux: > > On Tue, Sep 08, 2015 at 12:56:18PM +0200, Lucas Stach wrote: > > > This is expected, it's the overlay adapter which doesn't really work > > > with imx-drm yet. > > > > No, it's imx-drm which isn't working. As I explained in my previous > > email, overlay planes are expected to do scaling. imx-drm errors out > > attempts for that. This is a kernel bug, not an Xorg driver bug. > > > I would argue that this is a bug of the interface between kernel and > userspace. Yes, only in so far as knowing beforehand whether scaling is possible. The only time that you get to know is when the call to display the plane fails. That's a really poor interface. > Scaling isn't something that can be expected to be usable on every > hardware (and in fact the IPU isn't able to do arbitrary scaling with > its 1024 in/out pixel constraints), but there is no clear way to > communicate this to userspace other than flat out rejecting the plane > update. Atomic may provide some better ways, but we are not there yet > for imx-drm. I think that depends on your point of view - I suspect x86 people would be surprised by that comment. :) There was talk a while back when the overlay plane support went in that it was possible to do >1024 pixels, but it was complex, but the impression I was left with was one day it would work - and I'm still waiting. I suspect that the iMX6 is going to be obsolete before we have a decent working video playback story on this hardware.
Am Dienstag, den 08.09.2015, 12:29 +0100 schrieb Russell King - ARM Linux: > On Tue, Sep 08, 2015 at 01:07:47PM +0200, Lucas Stach wrote: > > Am Dienstag, den 08.09.2015, 12:01 +0100 schrieb Russell King - ARM > > Linux: > > > On Tue, Sep 08, 2015 at 12:56:18PM +0200, Lucas Stach wrote: > > > > This is expected, it's the overlay adapter which doesn't really work > > > > with imx-drm yet. > > > > > > No, it's imx-drm which isn't working. As I explained in my previous > > > email, overlay planes are expected to do scaling. imx-drm errors out > > > attempts for that. This is a kernel bug, not an Xorg driver bug. > > > > > I would argue that this is a bug of the interface between kernel and > > userspace. > > Yes, only in so far as knowing beforehand whether scaling is possible. > The only time that you get to know is when the call to display the plane > fails. That's a really poor interface. > > > Scaling isn't something that can be expected to be usable on every > > hardware (and in fact the IPU isn't able to do arbitrary scaling with > > its 1024 in/out pixel constraints), but there is no clear way to > > communicate this to userspace other than flat out rejecting the plane > > update. Atomic may provide some better ways, but we are not there yet > > for imx-drm. > > I think that depends on your point of view - I suspect x86 people would > be surprised by that comment. :) > I think some of the recent Intel chips had the same problem, in that they lost the ability to scale planes and ended up not exposing them due to the poor interface. > There was talk a while back when the overlay plane support went in that > it was possible to do >1024 pixels, but it was complex, but the impression > I was left with was one day it would work - and I'm still waiting. Don't wait for that. We can't do >1024 without doing a copy in memory, which would be a big stretch of the plane definition and benefit. In addition the IPU scaler has pitch and alignment constraints that make the needed tiling extremely complex to get right. We fiddled with this extensively to get it to the point that it is usable as a V4L2 mem2mem device. Moving this to the display path is not going to happen, ever. As all relevant resolutions already require a copy you are much better of doing it with the GPU and get all the testing effort focused on that path. > I > suspect that the iMX6 is going to be obsolete before we have a decent > working video playback story on this hardware. > MX6Plus is just around the corner and will probably keep us busy for a while. ;) Regards, Lucas
On Tue, Sep 08, 2015 at 02:43:53PM +0200, Lucas Stach wrote: > Am Dienstag, den 08.09.2015, 12:29 +0100 schrieb Russell King - ARM > Linux: > > There was talk a while back when the overlay plane support went in that > > it was possible to do >1024 pixels, but it was complex, but the impression > > I was left with was one day it would work - and I'm still waiting. > > Don't wait for that. We can't do >1024 without doing a copy in memory, > which would be a big stretch of the plane definition and benefit. > > In addition the IPU scaler has pitch and alignment constraints that make > the needed tiling extremely complex to get right. We fiddled with this > extensively to get it to the point that it is usable as a V4L2 mem2mem > device. Moving this to the display path is not going to happen, ever. > > As all relevant resolutions already require a copy you are much better > of doing it with the GPU and get all the testing effort focused on that > path. And at that point, you might as well use the filter blit and blit directly to the screen. I've run some performance analysis on this on iMX6 hardware, and the time taken for the CPU to copy the Xv data passed to it is about the same time that it takes the CPU to flush the caches, then ask the GPU to copy the data, and then wait for the GPU to report that the copy has finished. My analysis shows that you actually lose performance by using the GPU to merely copy and then pass it to Xv. Also, you mention that the IPU scaler has pitch and alignment constraints. So does the GPU. The Xv interface can cope with that just fine, because the Xv backend gets to define the pitch and buffer size for any given format/width/height, and offsets in the buffer for planar image formats. It isn't able to specify the alignment of the actual buffer though - for SHM, that's going to be the size of a struct page due to the way shmem works. For raw XvPutImage, things are harder to cope with, but the GPU can cope provided the offset is aligned to a pixel boundary. > MX6Plus is just around the corner and will probably keep us busy for a > while. ;) You might be excited about that, but for the rest of us, we have to put up with the hardware we have, which is basically iMX6. We need solutions now on existing iMX6 hardware, not the next set of likely to be problematical hardware. I know the grass is always greener on the other side - and I expect that when MX6+ comes out, you'll then have no time to work on etnaviv DRM, and we'll still be stuck without any progress on that.
>> I >> suspect that the iMX6 is going to be obsolete before we have a decent >> working video playback story on this hardware. >> > MX6Plus is just around the corner and will probably keep us busy for a > while. ;) Lucas, In which case, it "might" be a good idea to get the current version of etnaviv in mainline for current imx6's before you guys disappear again for mx6plus development.. As you guys are basically repeating what happened with the limadriver: http://limadriver.org/ Remember, there is an etnaviv community. Russell: is there any reason to not just push your version for mainline and let Pengutronix submit patches. Regards,
Robert Nelson <robertcnelson@gmail.com> writes: > In which case, it "might" be a good idea to get the current version of > etnaviv in mainline for current imx6's before you guys disappear again > for mx6plus development.. Definitely. This also includes the userspace parts. Bugs can always be squashed, but everything is much easier when the whole environment is already set up.
Am Dienstag, den 08.09.2015, 09:17 -0500 schrieb Robert Nelson: > >> I > >> suspect that the iMX6 is going to be obsolete before we have a decent > >> working video playback story on this hardware. > >> > > MX6Plus is just around the corner and will probably keep us busy for a > > while. ;) > > Lucas, > > In which case, it "might" be a good idea to get the current version of > etnaviv in mainline for current imx6's before you guys disappear again > for mx6plus development.. > This wasn't to signal that we are moving away from MX6 just to say that there might be a lot more life in MX6 than what the above implies. > As you guys are basically repeating what happened with the limadriver: > http://limadriver.org/ > We have no intention to repeat that. > Remember, there is an etnaviv community. > I would love to get review feedback for what is currently in the open from that community. Regards, Lucas
On Tue, Sep 08, 2015 at 09:17:06AM -0500, Robert Nelson wrote: > >> I > >> suspect that the iMX6 is going to be obsolete before we have a decent > >> working video playback story on this hardware. > >> > > MX6Plus is just around the corner and will probably keep us busy for a > > while. ;) > > Lucas, > > In which case, it "might" be a good idea to get the current version of > etnaviv in mainline for current imx6's before you guys disappear again > for mx6plus development.. > > As you guys are basically repeating what happened with the limadriver: > http://limadriver.org/ > > Remember, there is an etnaviv community. > > Russell: > is there any reason to not just push your version for mainline and let > Pengutronix submit patches. The basic problem is getting the kernel<->user API stable before it goes into mainline, which is an absolute must. We can't drop it into mainline and then break the user API. We also want to avoid putting it into the staging tree and have it sit around there for years.
On Tue, Sep 8, 2015 at 5:55 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Tue, Sep 08, 2015 at 09:17:06AM -0500, Robert Nelson wrote: >> >> I >> >> suspect that the iMX6 is going to be obsolete before we have a decent >> >> working video playback story on this hardware. >> >> >> > MX6Plus is just around the corner and will probably keep us busy for a >> > while. ;) >> >> Lucas, >> >> In which case, it "might" be a good idea to get the current version of >> etnaviv in mainline for current imx6's before you guys disappear again >> for mx6plus development.. >> >> As you guys are basically repeating what happened with the limadriver: >> http://limadriver.org/ >> >> Remember, there is an etnaviv community. >> >> Russell: >> is there any reason to not just push your version for mainline and let >> Pengutronix submit patches. > > The basic problem is getting the kernel<->user API stable before it > goes into mainline, which is an absolute must. We can't drop it into > mainline and then break the user API. > > We also want to avoid putting it into the staging tree and have it > sit around there for years. > If you don't have much time to work on it then lets get it pushed to the github community repos where we can have everyone else submit patches. We have #etnaviv where we can coordinate efforts. Even if something is on a todo list lets get it out where we someone else can work on it. I think our community is strong enough that we can all make progress without stepping on each others feet.
--- a/arch/arm/boot/dts/imx6q-gw54xx.dts +++ b/arch/arm/boot/dts/imx6q-gw54xx.dts @@ -21,3 +21,11 @@ &sata { status = "okay"; }; + +&clks { + assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>, + <&clks IMX6QDL_CLK_LDB_DI1_SEL>; + assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>, + <&clks IMX6QDL_CLK_PLL3_USB_OTG>; +}; + also had to apply: --- a/drivers/staging/etnaviv/Makefile +++ b/drivers/staging/etnaviv/Makefile @@ -11,7 +11,6 @@ etnaviv-y := \ etnaviv_gem_submit.o \ etnaviv_gpu.o \ etnaviv_iommu.o \ - etnaviv_iommu_v2.o \ etnaviv_mmu.o \ etnaviv_buffer.o
Trying to make some progress... I was missing the etnaviv DRM kernel driver. Now I have both IMX and etnaviv drivers, Linux v4.0-stable: git://git.pengutronix.de/git/lst/linux.git (etnaviv DRM driver) PLL5 DTS patch (enables HDMI with LVDS driver loaded): X.org etc.: git://github.com/laanwj/etna_viv.git git://ftp.arm.linux.org.uk/~rmk/libdrm-armada.git/ git://ftp.arm.linux.org.uk/~rmk/xf86-video-armada.git unstable-devel (I can't use master branch of xf86-video-armada.git because it doesn't support etnaviv - does it?) X log (relevant(?) stuff only): [ 18919.848] (II) armada(0): hardware: imx-drm [ 18919.923] (--) armada(0): Vivante GC320 GPU revision 5007 (etnaviv) 2d PE2.0 [ 18919.925] (II) armada(0): [DRI2] Setup complete [ 18919.925] (II) armada(0): [DRI2] DRI driver: etnadrm [ 18919.925] (II) armada(0): direct rendering: DRI2 enabled [ 18919.925] (II) armada(0): RandR 1.2 enabled, ignore the following RandR disabled message. [ 18919.927] (==) armada(0): DPMS enabled [ 18919.927] (==) armada(0): hotplug detection enabled [ 18919.928] (II) armada(0): etnaviv: Xv: using YUY2 tiled format intermediate YUV target [ 18919.971] (EE) AIGLX error: dlopen of /lib/dri/etnadrm_dri.so failed (I don't have this yet) [ 18920.072] (II) armada(0): etnaviv: A8 target not supported If I try to use pengutronix/etnaviv-4.1-wip branch (etnaviv DRM - for v4.2), dmesg contains a lot of: [drm:etnaviv_ioctl_gem_submit [etnaviv]] *ERROR* cmdstream bo has flag ETNA_BO_CMDSTREAM not set and it doesn't work. I assume I shouldn't use it yet? Changing to pengutronix/etnaviv-for-upstream, it works - sort of. I now have two Xvideo adapters: Adaptor: 0 Name: Marvell Armada Overlay Video Port: 88 (which unfortunately doesn't work, the window is black, the XV attributes are set to minimums and I can't set them). Is it expected? Adaptor: 1 Name: Etnaviv Textured Video Port(s): 89 - 104 Name: XV_SYNC_TO_VBLANK Flags: XvGettable XvSettable Min value: 0 Max value: 1 Current value: 1 Name: XV_PIPE Flags: XvGettable XvSettable Min value: -1 Max value: 3 Current value: -1 Name: XV_ENCODING Flags: XvGettable XvSettable Min value: 0 Max value: 0 Current value: 0 This adapter works, though there are some image distortions (horizontal lines apparently caused by changes in color between frames). Any input?