From: "Stéphane Marchesin" <stephane.marchesin@gmail.com> To: Rob Clark <rob.clark@linaro.org> Cc: Dave Airlie <airlied@gmail.com>, Thomas Petazzoni <thomas.petazzoni@free-electrons.com>, Linux Fbdev development list <linux-fbdev@vger.kernel.org>, Benjamin Gaignard <benjamin.gaignard@linaro.org>, Tom Gall <tom.gall@linaro.org>, Kyungmin Park <kyungmin.park@samsung.com>, "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, Ragesh Radhakrishnan <ragesh.r@linaro.org>, Tomi Valkeinen <tomi.valkeinen@ti.com>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Philipp Zabel <p.zabel@pengutronix.de>, Bryan Wu <bryan.wu@canonical.com>, Maxime Ripard <maxime.ripard@free-electrons.com>, Vikas Sajjan <vikas.sajjan@linaro.org>, Sumit Semwal <sumit.semwal@linaro.org>, Sebastien Guiriec <s-guiriec@ti.com>, "linux-media@vger.kernel.org" <linux-media@vger.kernel.org> Subject: Re: [RFC v2 0/5] Common Display Framework Date: Wed, 19 Dec 2012 12:05:04 -0800 [thread overview] Message-ID: <CACP_E+JSjwsaUnbuB7wazKZkQKt-pOU_aNKhPNyfW6j610WyjA@mail.gmail.com> (raw) In-Reply-To: <CAF6AEGsLdLasS4=j1PsX_P8miG8NcTXMUP9VYj+4gdU8Qhm2YQ@mail.gmail.com> On Mon, Dec 17, 2012 at 10:21 PM, Rob Clark <rob.clark@linaro.org> wrote: > On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote: >>> >>> Many developers showed interest in the first RFC, and I've had the opportunity >>> to discuss it with most of them. I would like to thank (in no particular >>> order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus >>> Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for >>> inviting me to Connect and providing a venue to discuss this topic. >>> >> >> So this might be a bit off topic but this whole CDF triggered me >> looking at stuff I generally avoid: >> >> The biggest problem I'm having currently with the whole ARM graphics >> and output world is the proliferation of platform drivers for every >> little thing. The whole ordering of operations with respect to things >> like suspend/resume or dynamic power management is going to be a real >> nightmare if there are dependencies between the drivers. How do you >> enforce ordering of s/r operations between all the various components? > > I tend to think that sub-devices are useful just to have a way to > probe hw which may or may not be there, since on ARM we often don't > have any alternative.. You can probe the device tree from a normal DRM driver. For example in nouveau for PPC we probe the OF device tree looking for connectors. I don't see how sub-devices or extra platform drivers help with that, as long as the device tree is populated upfront somehow... Stéphane > but beyond that, suspend/resume, and other > life-cycle aspects, they should really be treated as all one device. > Especially to avoid undefined suspend/resume ordering. > > CDF or some sort of mechanism to share panel drivers between drivers > is useful. Keeping it within drm, is probably a good idea, if nothing > else to simplify re-use of helper fxns (like avi-infoframe stuff, for > example) and avoid dealing with merging changes across multiple trees. > Treating them more like shared libraries and less like sub-devices > which can be dynamically loaded/unloaded (ie. they should be not built > as separate modules or suspend/resumed or probed/removed independently > of the master driver) is a really good idea to avoid uncovering nasty > synchronization issues later (remove vs modeset or pageflip) or > surprising userspace in bad ways. > >> The other thing I'd like you guys to do is kill the idea of fbdev and >> v4l drivers that are "shared" with the drm codebase, really just >> implement fbdev and v4l on top of the drm layer, some people might >> think this is some sort of maintainer thing, but really nothing else >> makes sense, and having these shared display frameworks just to avoid >> having using drm/kms drivers seems totally pointless. Fix the drm >> fbdev emulation if an fbdev interface is needed. But creating a fourth >> framework because our previous 3 frameworks didn't work out doesn't >> seem like a situation I want to get behind too much. > > yeah, let's not have multiple frameworks to do the same thing.. For > fbdev, it is pretty clear that it is a dead end. For v4l2 > (subdev+mcf), it is perhaps bit more flexible when it comes to random > arbitrary hw pipelines than kms. But to take advantage of that, your > userspace isn't going to be portable anyways, so you might as well use > driver specific properties/ioctls. But I tend to think that is more > useful for cameras. And from userspace perspective, kms planes are > less painful to use for output than v4l2, so lets stick to drm/kms for > output (and not try to add camera/capture support to kms).. k, thx > > BR, > -R > >> Dave. >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: "Stéphane Marchesin" <stephane.marchesin@gmail.com> To: Rob Clark <rob.clark@linaro.org> Cc: Dave Airlie <airlied@gmail.com>, Thomas Petazzoni <thomas.petazzoni@free-electrons.com>, Linux Fbdev development list <linux-fbdev@vger.kernel.org>, Benjamin Gaignard <benjamin.gaignard@linaro.org>, Tom Gall <tom.gall@linaro.org>, Kyungmin Park <kyungmin.park@samsung.com>, "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>, Ragesh Radhakrishnan <ragesh.r@linaro.org>, Tomi Valkeinen <tomi.valkeinen@ti.com>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Philipp Zabel <p.zabel@pengutronix.de>, Bryan Wu <bryan.wu@canonical.com>, Maxime Ripard <maxime.ripard@free-electrons.com>, Vikas Sajjan <vikas.sajjan@linaro.org>, Sumit Semwal <sumit.semwal@linaro.org>, Sebastien Guiriec <s-guiriec@ti.com>, "linux-media@vger.kernel.org" <linux-media@vger.kernel.org> Subject: Re: [RFC v2 0/5] Common Display Framework Date: Wed, 19 Dec 2012 20:05:04 +0000 [thread overview] Message-ID: <CACP_E+JSjwsaUnbuB7wazKZkQKt-pOU_aNKhPNyfW6j610WyjA@mail.gmail.com> (raw) In-Reply-To: <CAF6AEGsLdLasS4=j1PsX_P8miG8NcTXMUP9VYj+4gdU8Qhm2YQ@mail.gmail.com> On Mon, Dec 17, 2012 at 10:21 PM, Rob Clark <rob.clark@linaro.org> wrote: > On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote: >>> >>> Many developers showed interest in the first RFC, and I've had the opportunity >>> to discuss it with most of them. I would like to thank (in no particular >>> order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus >>> Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for >>> inviting me to Connect and providing a venue to discuss this topic. >>> >> >> So this might be a bit off topic but this whole CDF triggered me >> looking at stuff I generally avoid: >> >> The biggest problem I'm having currently with the whole ARM graphics >> and output world is the proliferation of platform drivers for every >> little thing. The whole ordering of operations with respect to things >> like suspend/resume or dynamic power management is going to be a real >> nightmare if there are dependencies between the drivers. How do you >> enforce ordering of s/r operations between all the various components? > > I tend to think that sub-devices are useful just to have a way to > probe hw which may or may not be there, since on ARM we often don't > have any alternative.. You can probe the device tree from a normal DRM driver. For example in nouveau for PPC we probe the OF device tree looking for connectors. I don't see how sub-devices or extra platform drivers help with that, as long as the device tree is populated upfront somehow... Stéphane > but beyond that, suspend/resume, and other > life-cycle aspects, they should really be treated as all one device. > Especially to avoid undefined suspend/resume ordering. > > CDF or some sort of mechanism to share panel drivers between drivers > is useful. Keeping it within drm, is probably a good idea, if nothing > else to simplify re-use of helper fxns (like avi-infoframe stuff, for > example) and avoid dealing with merging changes across multiple trees. > Treating them more like shared libraries and less like sub-devices > which can be dynamically loaded/unloaded (ie. they should be not built > as separate modules or suspend/resumed or probed/removed independently > of the master driver) is a really good idea to avoid uncovering nasty > synchronization issues later (remove vs modeset or pageflip) or > surprising userspace in bad ways. > >> The other thing I'd like you guys to do is kill the idea of fbdev and >> v4l drivers that are "shared" with the drm codebase, really just >> implement fbdev and v4l on top of the drm layer, some people might >> think this is some sort of maintainer thing, but really nothing else >> makes sense, and having these shared display frameworks just to avoid >> having using drm/kms drivers seems totally pointless. Fix the drm >> fbdev emulation if an fbdev interface is needed. But creating a fourth >> framework because our previous 3 frameworks didn't work out doesn't >> seem like a situation I want to get behind too much. > > yeah, let's not have multiple frameworks to do the same thing.. For > fbdev, it is pretty clear that it is a dead end. For v4l2 > (subdev+mcf), it is perhaps bit more flexible when it comes to random > arbitrary hw pipelines than kms. But to take advantage of that, your > userspace isn't going to be portable anyways, so you might as well use > driver specific properties/ioctls. But I tend to think that is more > useful for cameras. And from userspace perspective, kms planes are > less painful to use for output than v4l2, so lets stick to drm/kms for > output (and not try to add camera/capture support to kms).. k, thx > > BR, > -R > >> Dave. >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2012-12-19 20:13 UTC|newest] Thread overview: 174+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-11-22 21:45 [RFC v2 0/5] Common Display Framework Laurent Pinchart 2012-11-22 21:45 ` Laurent Pinchart 2012-11-22 21:45 ` [RFC v2 1/5] video: Add generic display entity core Laurent Pinchart 2012-11-22 21:45 ` Laurent Pinchart 2012-11-27 13:07 ` Tomi Valkeinen 2012-11-27 13:07 ` Tomi Valkeinen 2012-11-27 13:07 ` Tomi Valkeinen 2012-11-22 21:45 ` [RFC v2 2/5] video: panel: Add DPI panel support Laurent Pinchart 2012-11-22 21:45 ` Laurent Pinchart 2012-11-27 13:02 ` Tomi Valkeinen 2012-11-27 13:02 ` Tomi Valkeinen 2012-11-27 13:02 ` Tomi Valkeinen 2012-11-30 9:26 ` Philipp Zabel 2012-11-30 9:26 ` Philipp Zabel 2012-11-22 21:45 ` [RFC v2 3/5] video: display: Add MIPI DBI bus support Laurent Pinchart 2012-11-22 21:45 ` Laurent Pinchart 2012-11-30 12:02 ` Tomi Valkeinen 2012-11-30 12:02 ` Tomi Valkeinen 2012-11-30 12:02 ` Tomi Valkeinen 2012-11-22 21:45 ` [RFC v2 4/5] video: panel: Add R61505 panel support Laurent Pinchart 2012-11-22 21:45 ` Laurent Pinchart 2012-11-22 21:45 ` [RFC v2 5/5] video: panel: Add R61517 " Laurent Pinchart 2012-11-22 21:45 ` Laurent Pinchart 2012-11-23 14:51 ` [RFC v2 0/5] Common Display Framework Tomi Valkeinen 2012-11-23 14:51 ` Tomi Valkeinen 2012-11-23 14:51 ` Tomi Valkeinen 2012-12-17 14:36 ` Laurent Pinchart 2012-12-17 14:36 ` Laurent Pinchart 2012-12-17 15:29 ` Tomi Valkeinen 2012-12-17 15:29 ` Tomi Valkeinen 2012-12-17 15:29 ` Tomi Valkeinen 2012-12-17 23:18 ` Laurent Pinchart 2012-12-17 23:18 ` Laurent Pinchart 2012-12-17 16:53 ` Jani Nikula 2012-12-17 16:53 ` Jani Nikula 2012-12-17 22:19 ` Laurent Pinchart 2012-12-17 22:19 ` Laurent Pinchart 2012-12-19 14:57 ` Jani Nikula 2012-12-19 14:57 ` Jani Nikula 2012-12-19 15:07 ` Tomi Valkeinen 2012-12-19 15:07 ` Tomi Valkeinen 2012-12-19 15:07 ` Tomi Valkeinen 2012-12-24 17:31 ` Laurent Pinchart 2012-12-24 17:31 ` Laurent Pinchart 2012-12-19 15:26 ` Rob Clark 2012-12-19 15:26 ` Rob Clark 2012-12-19 15:37 ` Tomi Valkeinen 2012-12-19 15:37 ` Tomi Valkeinen 2012-12-19 16:05 ` Rob Clark 2012-12-19 16:05 ` Rob Clark 2012-12-19 16:05 ` Rob Clark 2012-12-24 17:40 ` Laurent Pinchart 2012-12-24 17:40 ` Laurent Pinchart 2012-12-24 17:35 ` Laurent Pinchart 2012-12-24 17:35 ` Laurent Pinchart 2012-12-27 16:10 ` Rob Clark 2012-12-27 16:10 ` Rob Clark 2012-12-24 17:27 ` Laurent Pinchart 2012-12-24 17:27 ` Laurent Pinchart 2012-12-27 16:04 ` Rob Clark 2012-12-27 16:04 ` Rob Clark 2012-12-27 19:19 ` Sascha Hauer 2012-12-27 19:19 ` Sascha Hauer 2012-11-23 19:56 ` Thierry Reding 2012-11-23 19:56 ` Thierry Reding 2012-11-24 7:15 ` Tomi Valkeinen 2012-11-24 7:15 ` Tomi Valkeinen 2012-11-24 7:15 ` Tomi Valkeinen 2012-11-26 14:47 ` Alan Cox 2012-12-17 15:15 ` Laurent Pinchart 2012-12-17 15:15 ` Laurent Pinchart 2012-11-26 7:53 ` Philipp Zabel 2012-11-26 7:53 ` Philipp Zabel 2012-12-17 14:58 ` Laurent Pinchart 2012-12-17 14:58 ` Laurent Pinchart 2012-11-23 21:41 ` Sascha Hauer 2012-11-23 21:41 ` Sascha Hauer 2012-12-17 15:02 ` Laurent Pinchart 2012-12-17 15:02 ` Laurent Pinchart [not found] ` <CAD025yS5rGMbiRBdDxv=YLP6_fsQndAkr+3t29_mNhcvow_SwA@mail.gmail.com> [not found] ` <3133576.BkqAl7V01U@avalon> 2012-12-18 3:01 ` Vikas Sajjan 2012-12-18 6:13 ` Vikas Sajjan 2012-12-18 6:25 ` Vikas Sajjan 2012-12-21 10:00 ` Tomasz Figa 2012-12-21 10:00 ` Tomasz Figa 2012-12-24 14:12 ` Laurent Pinchart 2012-12-24 14:12 ` Laurent Pinchart 2012-12-27 14:43 ` Tomasz Figa 2012-12-27 14:43 ` Tomasz Figa 2012-12-27 14:43 ` Tomasz Figa 2012-12-28 3:26 ` Vikas Sajjan 2012-12-28 3:38 ` Vikas Sajjan 2013-01-08 8:18 ` Laurent Pinchart 2013-01-08 8:18 ` Laurent Pinchart 2013-01-08 10:12 ` Marcus Lorentzon 2013-01-08 10:12 ` Marcus Lorentzon 2013-01-08 16:36 ` Tomasz Figa 2013-01-08 16:36 ` Tomasz Figa 2013-01-08 17:08 ` Marcus Lorentzon 2013-01-08 17:08 ` Marcus Lorentzon 2013-02-01 23:35 ` Laurent Pinchart 2013-02-01 23:35 ` Laurent Pinchart 2013-02-04 10:05 ` Marcus Lorentzon 2013-02-04 10:05 ` Marcus Lorentzon 2013-02-06 9:52 ` Archit Taneja 2013-02-06 9:52 ` Archit Taneja 2013-02-08 10:51 ` Tomi Valkeinen 2013-02-08 10:51 ` Tomi Valkeinen 2013-02-08 12:43 ` Marcus Lorentzon 2013-02-08 12:43 ` Marcus Lorentzon 2013-02-01 23:37 ` Laurent Pinchart 2013-02-01 23:37 ` Laurent Pinchart 2012-12-24 12:59 ` Laurent Pinchart 2012-12-24 13:00 ` Laurent Pinchart 2012-12-18 5:04 ` Dave Airlie 2012-12-18 5:04 ` Dave Airlie 2012-12-18 5:04 ` Dave Airlie 2012-12-18 6:21 ` Rob Clark 2012-12-18 6:21 ` Rob Clark 2012-12-18 8:30 ` Daniel Vetter 2012-12-18 8:30 ` Daniel Vetter 2012-12-18 9:38 ` Inki Dae 2012-12-19 20:13 ` Stéphane Marchesin 2012-12-19 20:13 ` Stéphane Marchesin 2012-12-24 14:08 ` Laurent Pinchart 2012-12-24 14:08 ` Laurent Pinchart 2012-12-24 13:39 ` Laurent Pinchart 2012-12-24 13:39 ` Laurent Pinchart 2012-12-18 10:59 ` Sylwester Nawrocki 2012-12-18 10:59 ` Sylwester Nawrocki 2012-12-24 17:19 ` Laurent Pinchart 2012-12-24 17:19 ` Laurent Pinchart 2012-12-19 20:05 ` Stéphane Marchesin [this message] 2012-12-19 20:05 ` Stéphane Marchesin 2012-12-24 13:37 ` Laurent Pinchart 2012-12-24 13:37 ` Laurent Pinchart 2012-12-27 15:54 ` Rob Clark 2012-12-27 15:54 ` Rob Clark 2012-12-27 19:18 ` Sascha Hauer 2012-12-27 19:18 ` Sascha Hauer 2012-12-27 19:57 ` Rob Clark 2012-12-27 19:57 ` Rob Clark 2012-12-28 0:04 ` Sascha Hauer 2012-12-28 0:04 ` Sascha Hauer 2013-01-08 8:33 ` Laurent Pinchart 2013-01-08 8:33 ` Laurent Pinchart 2013-01-08 8:25 ` Laurent Pinchart 2013-01-08 8:25 ` Laurent Pinchart 2013-01-08 16:13 ` Rob Clark 2013-01-08 16:13 ` Rob Clark 2013-01-09 8:23 ` Rahul Sharma 2013-01-09 8:35 ` Rahul Sharma 2013-01-09 8:23 ` Rahul Sharma 2013-02-01 23:42 ` Laurent Pinchart 2013-02-01 23:42 ` Laurent Pinchart 2013-02-02 10:08 ` Rob Clark 2013-02-02 10:08 ` Rob Clark 2012-12-18 10:39 ` Marcus Lorentzon 2012-12-18 10:39 ` Marcus Lorentzon 2012-12-18 10:39 ` Marcus Lorentzon 2012-12-24 17:09 ` Laurent Pinchart 2012-12-24 17:09 ` Laurent Pinchart 2012-12-24 17:09 ` Laurent Pinchart 2012-12-27 15:57 ` Rob Clark 2012-12-27 15:57 ` Rob Clark 2012-12-27 15:57 ` Rob Clark 2013-01-06 17:46 ` Daniel Vetter 2013-01-06 17:46 ` Daniel Vetter 2013-01-06 17:46 ` Daniel Vetter 2013-01-08 8:41 ` Laurent Pinchart 2013-01-08 8:41 ` Laurent Pinchart 2012-12-24 13:24 ` Laurent Pinchart 2012-12-24 13:24 ` Laurent Pinchart 2012-12-14 4:57 Vikas Sajjan 2012-12-17 22:00 ` Laurent Pinchart
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=CACP_E+JSjwsaUnbuB7wazKZkQKt-pOU_aNKhPNyfW6j610WyjA@mail.gmail.com \ --to=stephane.marchesin@gmail.com \ --cc=airlied@gmail.com \ --cc=benjamin.gaignard@linaro.org \ --cc=bryan.wu@canonical.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=kyungmin.park@samsung.com \ --cc=laurent.pinchart@ideasonboard.com \ --cc=linux-fbdev@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=maxime.ripard@free-electrons.com \ --cc=p.zabel@pengutronix.de \ --cc=ragesh.r@linaro.org \ --cc=rob.clark@linaro.org \ --cc=s-guiriec@ti.com \ --cc=sumit.semwal@linaro.org \ --cc=thomas.petazzoni@free-electrons.com \ --cc=tom.gall@linaro.org \ --cc=tomi.valkeinen@ti.com \ --cc=vikas.sajjan@linaro.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.