Hi Rob, On Wednesday 19 December 2012 09:26:40 Rob Clark wrote: > On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula wrote: > > On Tue, 18 Dec 2012, Laurent Pinchart wrote: > >> On Monday 17 December 2012 18:53:37 Jani Nikula wrote: > >>> I can see the need for a framework for DSI panels and such (in fact Tomi > >>> and I have talked about it like 2-3 years ago already!) but what is the > >>> story for HDMI and DP? In particular, what's the relationship between > >>> DRM and CDF here? Is there a world domination plan to switch the DRM > >>> drivers to use this framework too? ;) Do you have some rough plans how > >>> DRM and CDF should work together in general? > >> > >> There's always a world domination plan, isn't there ? :-) > >> > >> I certainly want CDF to be used by DRM (or more accurately KMS). That's > >> what the C stands for, common refers to sharing panel and other display > >> entity drivers between FBDEV, KMS and V4L2. > >> > >> I currently have no plan to expose CDF internals to userspace through the > >> KMS API. We might have to do so later if the hardware complexity grows > >> in such a way that finer control than what KMS provides needs to be > >> exposed to userspace, but I don't think we're there yet. The CDF API > >> will thus only be used internally in the kernel by display controller > >> drivers. The KMS core might get functions to handle common display > >> entity operations, but the bulk of the work will be in the display > >> controller drivers to start with. We will then see what can be > >> abstracted in KMS helper functions. > >> > >> Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the > >> CDF API. That's just a thought for now, I haven't tried to implement > >> them, but it would be nice to handle HDMI screens and DPI/DBI/DSI panels > >> in a generic way. > >> > >> Do you have thoughts to share on this topic ? > > > > 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! > > fwiw, I think there are at least a couple cases where multiple SoC's > have the same HDMI IP block. > > And, there are also external HDMI encoders (for example connected over > i2c) that can also be shared between boards. So I think there will be > a number of cases where CDF is appropriate for HDMI drivers. Although > trying to keep this all independent of DRM (as opposed to just > something similar to what drivers/gpu/i2c is today) seems a bit > overkill for me. Being able to use the helpers in drm and avoiding an > extra layer of translation seems like the better option to me. So my > vote would be drivers/gpu/cdf. I don't think there will be any need for translation (except perhaps between the DRM mode structures and the common video mode structure that is being discussed). Add a drm_ prefix to the existing CDF functions and structures, and there you go :-) The reason why I'd like to keep CDF separate from DRM (or at least not requiring a drm_device) is that HDMI/DP encoders can be used by pure V4L2 drivers. > > 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. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
