Hi Marcus, On Tuesday 18 December 2012 11:39:11 Marcus Lorentzon wrote: > 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. On the topic of discussions, would anyone be interested in a BoF/brainstorming/whatever session during the FOSDEM ? > > 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. > > > 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 -- 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
