[RFC v2 0/5] Common Display Framework

Rob Clark rob.clark at linaro.org
Thu Dec 27 08:10:11 PST 2012


On Mon, Dec 24, 2012 at 11:35 AM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> wrote:
> On Wednesday 19 December 2012 09:26:40 Rob Clark wrote:
>> 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 :-)

well, and translation for any properties that we'd want to expose to
userspace, etc, etc.. I see there being a big potential for a lot of
needless glue

BR,
-R

> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


More information about the dri-devel mailing list