On 12/18/2012 06:04 AM, 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:
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.
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?
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.
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. 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. 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?
/BR
/Marcus
--
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
