[RFC v2 0/5] Common Display Framework

[Laurent Pinchart]

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