From: robdclark@gmail.com (Rob Clark) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver Date: Wed, 12 Jun 2013 09:56:22 -0400 [thread overview] Message-ID: <CAF6AEGs4GLkBePQUd_Bh4z_Hwv8kacaEQSMSVSj4rw=ezQA66Q@mail.gmail.com> (raw) In-Reply-To: <20130612134845.GQ18614@n2100.arm.linux.org.uk> On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Tue, Jun 11, 2013 at 09:48:57AM +1000, Dave Airlie wrote: >> On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux >> <linux@arm.linux.org.uk> wrote: >> > On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote: >> >> I'd like to see all the ARM based drivers based on CMA if it can meet >> >> their requirements >> >> and using close to standard GEM/dma-buf interfaces. Otherwise it'll be >> >> come an unmaintainable >> >> nightmare for everyone, but mostly for me. >> > >> > I am *not* using the CMA layer - that layer is just plain broken in >> > DRM. It forces every single gem object to be a CMA allocated object, >> > which means I can't have cacheable pixmaps in X. And that makes X >> > suck. >> > >> > Okay, I'm pulling this and I'm going to keep it in my private cubox >> > tree; I'm not persuing pushing this driver or any other Armada 510 >> > driver into mainline anymore. It's just too much fscking hastle >> > dealing with people who don't like various stuff. >> > >> > I've done my best to clean a lot of the crap up, and the problem is >> > that no matter how much I clean up, it remains unacceptable. Only >> > the 100% perfect solution seems to be acceptable. That is >> > unacceptable given that this stuff has already consumed something >> > like 8 months solid of my time. >> >> Russell, aren't you a kernel maintainer, because for fuck sake get real. >> >> I'm not merging bullshit into my tree that has a completely broken API that >> has to be maintained for ever. You of all people should understand we >> don't break Linux >> userspace APIs, and adding a phys addr one is wrong, wrong, wrong, its not >> cleanups, its just broken, and I'll never merge it. > > And having thought about this driver, DRM some more, I'm now of the > opinion that DRM is not suitable for driving hardware where the GPU is > an entirely separate IP block from the display side. > > DRM is modelled after the PC setup where your "graphics card" does > everything - it has the GPU, display and connectors all integrated > together. This is not the case on embedded SoCs, which can be a > collection of different IPs all integrated together. actually it isn't even the case on desktop/laptop anymore, where you can have one gpu with scanout and a second one without (or just with display controller not hooked up to anything, etc, etc) That is the point of dmabuf and the upcoming fence/reservation stuff. BR, -R > DRM is based on the assumption that you have a single card and everything > is known about that card. Again, this is not the case with embedded SoCs, > which is why Sebastian is having a hard time with the DRM slave encoder > stuff. > > If DRM is going to be usable on SoCs, it needs to become more modular in > nature, allowing the same scanout stuff to be used with different GPUs > and providing _kernel_ side interfaces to allow different GPUs to be > plugged in to a scanout implementation, or vice versa (the reverse is > probably easier because the scanout interface is nicely abstracted). > > Or we go off and write an entirely new subsystem which *does* suit the > needs of modular SoC implementations.
WARNING: multiple messages have this Message-ID (diff)
From: Rob Clark <robdclark@gmail.com> To: Russell King - ARM Linux <linux@arm.linux.org.uk> Cc: linux-arm-kernel@lists.infradead.org, Jason Cooper <jason@lakedaemon.net>, dri-devel@lists.freedesktop.org, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Subject: Re: [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver Date: Wed, 12 Jun 2013 09:56:22 -0400 [thread overview] Message-ID: <CAF6AEGs4GLkBePQUd_Bh4z_Hwv8kacaEQSMSVSj4rw=ezQA66Q@mail.gmail.com> (raw) In-Reply-To: <20130612134845.GQ18614@n2100.arm.linux.org.uk> On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Tue, Jun 11, 2013 at 09:48:57AM +1000, Dave Airlie wrote: >> On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux >> <linux@arm.linux.org.uk> wrote: >> > On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote: >> >> I'd like to see all the ARM based drivers based on CMA if it can meet >> >> their requirements >> >> and using close to standard GEM/dma-buf interfaces. Otherwise it'll be >> >> come an unmaintainable >> >> nightmare for everyone, but mostly for me. >> > >> > I am *not* using the CMA layer - that layer is just plain broken in >> > DRM. It forces every single gem object to be a CMA allocated object, >> > which means I can't have cacheable pixmaps in X. And that makes X >> > suck. >> > >> > Okay, I'm pulling this and I'm going to keep it in my private cubox >> > tree; I'm not persuing pushing this driver or any other Armada 510 >> > driver into mainline anymore. It's just too much fscking hastle >> > dealing with people who don't like various stuff. >> > >> > I've done my best to clean a lot of the crap up, and the problem is >> > that no matter how much I clean up, it remains unacceptable. Only >> > the 100% perfect solution seems to be acceptable. That is >> > unacceptable given that this stuff has already consumed something >> > like 8 months solid of my time. >> >> Russell, aren't you a kernel maintainer, because for fuck sake get real. >> >> I'm not merging bullshit into my tree that has a completely broken API that >> has to be maintained for ever. You of all people should understand we >> don't break Linux >> userspace APIs, and adding a phys addr one is wrong, wrong, wrong, its not >> cleanups, its just broken, and I'll never merge it. > > And having thought about this driver, DRM some more, I'm now of the > opinion that DRM is not suitable for driving hardware where the GPU is > an entirely separate IP block from the display side. > > DRM is modelled after the PC setup where your "graphics card" does > everything - it has the GPU, display and connectors all integrated > together. This is not the case on embedded SoCs, which can be a > collection of different IPs all integrated together. actually it isn't even the case on desktop/laptop anymore, where you can have one gpu with scanout and a second one without (or just with display controller not hooked up to anything, etc, etc) That is the point of dmabuf and the upcoming fence/reservation stuff. BR, -R > DRM is based on the assumption that you have a single card and everything > is known about that card. Again, this is not the case with embedded SoCs, > which is why Sebastian is having a hard time with the DRM slave encoder > stuff. > > If DRM is going to be usable on SoCs, it needs to become more modular in > nature, allowing the same scanout stuff to be used with different GPUs > and providing _kernel_ side interfaces to allow different GPUs to be > plugged in to a scanout implementation, or vice versa (the reverse is > probably easier because the scanout interface is nicely abstracted). > > Or we go off and write an entirely new subsystem which *does* suit the > needs of modular SoC implementations.
next prev parent reply other threads:[~2013-06-12 13:56 UTC|newest] Thread overview: 120+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-06-09 19:06 [RFC v2 0/8] rmk's Dove DRM/TDA19988 Cubox driver Russell King - ARM Linux 2013-06-09 19:06 ` Russell King - ARM Linux 2013-06-09 19:29 ` [PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver Russell King 2013-06-09 19:32 ` Russell King 2013-06-10 11:10 ` Sebastian Hesselbarth 2013-06-10 11:10 ` Sebastian Hesselbarth 2013-06-10 21:48 ` Russell King - ARM Linux 2013-06-10 21:48 ` Russell King - ARM Linux 2013-06-10 21:56 ` Sebastian Hesselbarth 2013-06-10 21:56 ` Sebastian Hesselbarth 2013-06-10 15:57 ` Rob Clark 2013-06-10 15:57 ` Rob Clark 2013-06-10 17:06 ` Russell King - ARM Linux 2013-06-10 17:06 ` Russell King - ARM Linux 2013-06-10 19:59 ` Rob Clark 2013-06-10 19:59 ` Rob Clark 2013-06-10 20:08 ` Russell King - ARM Linux 2013-06-10 20:08 ` Russell King - ARM Linux 2013-06-10 21:01 ` Rob Clark 2013-06-10 21:01 ` Rob Clark 2013-06-10 21:15 ` Russell King - ARM Linux 2013-06-10 21:15 ` Russell King - ARM Linux 2013-06-10 22:49 ` Rob Clark 2013-06-10 22:49 ` Rob Clark 2013-06-10 22:56 ` Russell King - ARM Linux 2013-06-10 22:56 ` Russell King - ARM Linux 2013-06-10 23:17 ` Rob Clark 2013-06-10 23:17 ` Rob Clark 2013-06-10 23:24 ` Dave Airlie 2013-06-10 23:24 ` Dave Airlie 2013-06-10 23:35 ` Rob Clark 2013-06-10 23:35 ` Rob Clark 2013-06-10 23:36 ` Russell King - ARM Linux 2013-06-10 23:36 ` Russell King - ARM Linux 2013-06-10 23:48 ` Dave Airlie 2013-06-10 23:48 ` Dave Airlie 2013-06-10 23:56 ` Russell King - ARM Linux 2013-06-10 23:56 ` Russell King - ARM Linux 2013-06-12 13:48 ` Russell King - ARM Linux 2013-06-12 13:48 ` Russell King - ARM Linux 2013-06-12 13:56 ` Rob Clark [this message] 2013-06-12 13:56 ` Rob Clark 2013-06-12 16:49 ` Russell King - ARM Linux 2013-06-12 16:49 ` Russell King - ARM Linux 2013-06-12 17:05 ` Russell King - ARM Linux 2013-06-12 17:05 ` Russell King - ARM Linux 2013-06-12 19:40 ` Russell King - ARM Linux 2013-06-12 19:40 ` Russell King - ARM Linux 2013-06-12 23:00 ` Russell King - ARM Linux 2013-06-12 23:00 ` Russell King - ARM Linux 2013-06-13 0:17 ` Rob Clark 2013-06-13 0:17 ` Rob Clark 2013-06-13 11:19 ` Russell King - ARM Linux 2013-06-13 11:19 ` Russell King - ARM Linux 2013-06-13 11:50 ` Russell King - ARM Linux 2013-06-13 11:50 ` Russell King - ARM Linux 2013-06-13 13:03 ` Russell King - ARM Linux 2013-06-13 13:03 ` Russell King - ARM Linux 2013-06-14 14:23 ` Daniel Vetter 2013-06-14 14:23 ` Daniel Vetter 2013-06-14 14:42 ` Russell King - ARM Linux 2013-06-14 14:42 ` Russell King - ARM Linux 2013-06-14 19:50 ` Daniel Vetter 2013-06-14 19:50 ` Daniel Vetter 2013-06-14 22:15 ` Russell King - ARM Linux 2013-06-14 22:15 ` Russell King - ARM Linux 2013-06-14 22:36 ` Daniel Vetter 2013-06-14 22:36 ` Daniel Vetter 2013-06-14 13:53 ` Daniel Vetter 2013-06-14 13:53 ` Daniel Vetter 2013-06-14 14:27 ` Russell King - ARM Linux 2013-06-14 14:27 ` Russell King - ARM Linux 2013-06-13 12:52 ` Rob Clark 2013-06-13 12:52 ` Rob Clark 2013-06-13 12:58 ` Daniel Vetter 2013-06-13 12:58 ` Daniel Vetter 2013-06-12 20:04 ` Rob Clark 2013-06-12 20:04 ` Rob Clark 2013-06-10 23:38 ` Russell King - ARM Linux 2013-06-10 23:38 ` Russell King - ARM Linux 2013-06-10 23:49 ` Rob Clark 2013-06-10 23:49 ` Rob Clark 2013-06-10 22:01 ` Daniel Vetter 2013-06-10 22:01 ` Daniel Vetter 2013-06-10 22:32 ` Russell King - ARM Linux 2013-06-10 22:32 ` Russell King - ARM Linux 2013-06-10 23:12 ` Rob Clark 2013-06-10 23:12 ` Rob Clark 2013-06-11 7:33 ` Daniel Vetter 2013-06-11 7:33 ` Daniel Vetter 2013-06-11 8:08 ` Ville Syrjälä 2013-06-11 8:08 ` Ville Syrjälä 2013-06-10 21:38 ` Russell King - ARM Linux 2013-06-10 21:38 ` Russell King - ARM Linux 2013-06-09 19:30 ` [PATCH RFC 3/8] drm/i2c: nxp-tda998x: fix EDID reading on TDA19988 devices Russell King 2013-06-09 19:30 ` Russell King 2013-06-09 19:31 ` [PATCH RFC 4/8] drm/i2c: nxp-tda998x: ensure VIP output mux is properly set Russell King 2013-06-09 19:31 ` Russell King 2013-06-09 19:32 ` [PATCH RFC 5/8] drm/i2c: nxp-tda998x: fix npix/nline programming Russell King 2013-06-09 19:32 ` Russell King 2013-06-09 20:02 ` Sebastian Hesselbarth 2013-06-09 20:02 ` Sebastian Hesselbarth 2013-06-09 19:34 ` [PATCH RFC 6/8] drm/i2c: nxp-tda998x: prepare for video input configuration Russell King 2013-06-09 19:34 ` Russell King 2013-06-09 19:35 ` [PATCH RFC 7/8] drm/i2c: nxp-tda998x: add video and audio " Russell King 2013-06-09 19:35 ` Russell King 2013-06-09 19:36 ` [PATCH RFC 8/8] DRM: Armada: add support for drm tda19988 driver Russell King 2013-06-09 19:36 ` Russell King 2013-06-09 19:43 ` [RFC v2 0/8] rmk's Dove DRM/TDA19988 Cubox driver Russell King - ARM Linux 2013-06-09 19:43 ` Russell King - ARM Linux 2013-06-10 22:47 ` [RFC v3 0/4] " Russell King - ARM Linux 2013-06-10 22:47 ` Russell King - ARM Linux 2013-06-10 22:48 ` [PATCH RFC v3 1/4] DRM: Armada: Add Armada DRM driver Russell King 2013-06-10 22:51 ` Russell King 2013-06-10 22:49 ` [PATCH RFC v3 2/4] DRM: Armada: Add support for hardware cursors Russell King 2013-06-10 22:49 ` Russell King 2013-06-10 22:50 ` [PATCH RFC v3 3/4] DRM: Armada: convert Armada hardware cursor support to RGB+transparency Russell King 2013-06-10 22:50 ` Russell King 2013-06-10 22:51 ` [PATCH RFC v3 4/4] DRM: Armada: convert hardware cursor support to 64x32 or 32x64 ARGB Russell King 2013-06-10 22:51 ` Russell King
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAF6AEGs4GLkBePQUd_Bh4z_Hwv8kacaEQSMSVSj4rw=ezQA66Q@mail.gmail.com' \ --to=robdclark@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.