Re: [RFC v2 0/5] Common Display Framework

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

[-- Attachment #1: Type: text/plain, Size: 2660 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]