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

On Mon, Dec 24, 2012 at 11:35 AM, Laurent Pinchart
[off-list ref] wrote:

On Wednesday 19 December 2012 09:26:40 Rob Clark wrote:

quoted

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.

quoted

quoted

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html