Hi Tomi, On Wednesday 19 December 2012 17:07:50 Tomi Valkeinen wrote: > On 2012-12-19 16:57, Jani Nikula wrote: > > It just seems to me that, at least from a DRM/KMS perspective, adding > > another layer (=CDF) for HDMI or DP (or legacy outputs) would be > > overengineering it. They are pretty well standardized, and I don't see > > there would be a need to write multiple display drivers for them. Each > > display controller has one, and can easily handle any chip specific > > requirements right there. It's my gut feeling that an additional > > framework would just get in the way. Perhaps there could be more common > > HDMI/DP helper style code in DRM to reduce overlap across KMS drivers, > > but that's another thing. > > > > So is the HDMI/DP drivers using CDF a more interesting idea from a > > non-DRM perspective? Or, put another way, is it more of an alternative > > to using DRM? Please enlighten me if there's some real benefit here that > > I fail to see! > > The use of CDF is an option, not something that has to be done. A DRM > driver developer may use it if it gives benefit for him for that > particular driver. > > I don't know much about desktop display hardware, but I guess that using > CDF would not really give much there. In some cases it could, if the IPs > used on the graphics card are something that are used elsewhere also > (sounds quite unlikely, though). In that case there could be separate > drivers for the IPs. > > And note that CDF is not really about the dispc side, i.e. the part that > creates the video stream from pixels in the memory. It's more about the > components after that, and how to connect those components. > > > For DSI panels (or DSI-to-whatever bridges) it's of course another > > story. You typically need a panel specific driver. And here I see the > > main point of the whole CDF: decoupling display controllers and the > > panel drivers, and sharing panel (and converter chip) specific drivers > > across display controllers. Making it easy to write new drivers, as > > there would be a model to follow. I'm definitely in favour of coming up > > with some framework that would tackle that. > > Right. But if you implement drivers for DSI panels with CDF for, say, > OMAP, I think it's simpler to use CDF also for HDMI/DP on OMAP. > Otherwise it'll be a mishmash with two different models.
I second your point here, using CDF for encoders should be simpler, but it will not be enforced. A display controller driver developer who wants to control the on-SoC encoder without conforming to the CDF model will be totally free to do so and won't be blamed. -- Regards, Laurent Pinchart
signature.asc
Description: This is a digitally signed message part.
