Re: [RFC v2 0/5] Common Display Framework

Hi Marcus,

On Tuesday 18 December 2012 11:39:11 Marcus Lorentzon wrote:

On 12/18/2012 06:04 AM, Dave Airlie wrote:

quoted

quoted

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:

I like the effort, right now it seems like x86 and arm display sub systems
are quite different in terms of DRM driver (and HW) design. I think this is
partly due to little information shared about these different architectures
and ideas behind the choices made. I hope some discussion will light up both
sides. And an early discussion will hopefully give you less pain when CDF
drivers starts to get pushed your way.

On the topic of discussions, would anyone be interested in a 
BoF/brainstorming/whatever session during the FOSDEM ?

quoted

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?

Could you give an example? Personally I don't think it is that many. I
might not have counted the plat devs in all arm drivers. But the STE one
have one per HW IP block in the HW (1 DSS + 3 DSI encoder/formatters).
Then of course there are all these panel devices. But I hope that when
CDF is "finished" we will have DSI devices on the DSI bus and DBI
devices on the DBI bus. I think most vendors have used platform devices
for these since they normally can't be probed in a generic way. But as
they are off SoC I feel this is not the best choice. And then many of
the panels are I2C devices (control bus) and that I guess is similar to
"x86" encoders/connectors?

Tomi Valkeinen proposed dropping the DSI and DBI busses in favor of the 
platform bus. Although I still believe that DSI and DBI busses would make 
sense, I agree that they don't provide much in terms of probing and power 
management. You can read the discussion at http://www.spinics.net/lists/linux-
fbdev/msg09250.html.

Another part of the difference I feel is that in x86 a DRM device is
most likely a PCI device, and as such has one huge driver for all IPs on
that board. The closest thing we get to that in ARM is probably the DSS
(collection of IPs on SoC, like 3D, 2D, display output, encoders). But
it doesn't fell right to create a single driver for all these. And as
you know often 3D is even from a separate vendor. All these lead up to a
slight increase in the number of devices and drivers. Right way, I feel
so, but you are welcome to show a better way.

quoted

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 have no intention to use CDF outside KMS connector/encoder and I have
not heard Laurent talk about this either.

I don't either. CDF will mostly target KMS connectors, and can also be used 
for KMS encoders. I have no plan to touch the CRTC.

Personally I see CDF as "helpers" to create and reuse connector/encoder
drivers between SoCs instead of each SoC do their own panel drivers (which
would be about a hundred, times the number of supported SoCs). We probably
need to discuss the connector/encoder mappings to CDF/panels.

That's a topic I was planning to discuss at some point. One of the issues is 
that the KMS model can only have 3 entities in the pipeline, while hardware 
pipelines (especially in the embedded world) could be made of 4 or more 
entities (such as CRTC -> DSI encoder -> DSI to HDMI converter -> HDMI 
connector). We might not have to expose all details to userspace, but we need 
mapping rules.

But I think we need to flush out the higher level details like control bus
vs. data bus vs. display entities. While I like the generic way of the
display entities, I also like the pure bus/device/driver model without too
many generalizations.
Do you have any support in x86 world that could be compared to mobile
phone DSI/DBI/DPI panels? That is, different encoder/lcd-driver chips
between the on chip/cpu/SoC CRTC and the external LCD depending on
product (mobile/netbook/...) or is it all HDMI/DP/LVDS etc on x86?
And if you do, how do you model/setup/share all those in DRM driver? Or
it is manageable (< 10) and not up in the hundreds of different
encoders/lcd-drivers?

-- 
Regards,

Laurent Pinchart