[RFC v2 0/5] Common Display Framework

[Laurent Pinchart]

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