On Mon, Dec 17, 2012 at 10:21 PM, Rob Clark <rob.clark@xxxxxxxxxx> wrote: > On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
