Hi Dave, On Tuesday 18 December 2012 15:04:02 Dave Airlie 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. We share the same concern, although my analysis of the problem is somewhat different. The power management ordering issues isn't only caused by the software architecture, but also comes from complex hardware requirements. The root cause, in my opinion, is the split control and data busses: as soon as a device sits on multiple busses and has power management ordering requirements related to those busses the Linux power management model breaks. Note that the problem isn't restricted to the display, we have run into the exact same issues years ago on the video capture side. > How do you enforce ordering of s/r operations between all the various > components? The way we have handled this problem on the camera side is to use early suspend and late resume operations to handle the data (video) busses suspend and resume operations, and let the kernel handle the rest using the control bus based device tree model. The camera controller stops the video pipeline in its early suspend operation (and resumes it in the late resume operation) by calling operations provided by the entities (through function pointers of course, we don't want direct dependencies between the drivers). The control suspend/resume (such as sending a standby command through I2C to put the chip in low-power mode, or turning its power supply or clock off) is then handled by the PM core. > 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. I think there's a misunderstanding here. I'm definitely not trying to create a framework to expose the FBDEV/KMS/V4L2 APIs through different drivers on top of the same hardware device. That's an idea I really dislike, and I fully agree that the FBDEV API should be provided on top of KMS using the DRM FBDEV emulation layer. V4L2 on top of KMS doesn't make too much sense to me, as V4L2 isn't really a display and graphics API anyway. My goal here is to share code for chips that are used by different "devices" (in the sense of an agregate device, such as a camera or a graphics card) supported by different subsystems. For instance, the same I2C-controlled HDMI transmitter can be used by a display device when connected to a display controller on an SoC, but can also be used by a video output device when connected to a video output (some complex TI SoCs have pass-through video pipelines with no associated frame buffer, making the V4L2 API better suited than DRM/KMS). As the first device would be supported by a DRM/KMS driver and the second device by a pure V4L2 driver, we need a common framework to share code between both. If the same framework can be used to share panel drivers between DRM/KMS and pure FBDEV drivers (we have a bunch of those, not all of them will be ported to DRM/KMS, at least not in the very near future) that's also a bonus. To summarize my point, CDF aims at creating a self-contained framework that can be used by FBDEV, DRM/KMS and V4L2 drivers to interface with various display-related devices. It does not provide any userspace API, and does not offer any way to share devices between the three subsystems at runtime. In a way you can think of CDF as a DRM panel framework, but without the drm_ prefix. I hope this clarifies my goals. If not, or if there's still concerns and/or disagreements, let's discuss them. -- Regards, Laurent Pinchart -- 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
