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

On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen [off-list ref] wrote:

On 2012-12-19 17:26, 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.

Well, we need to think about that. I would like to keep CDF independent
of DRM. I don't like tying different components/frameworks together if
there's no real need for that.

Also, something that Laurent mentioned in our face-to-face discussions:
Some IPs/chips can be used for other purposes than with DRM.

He had an example of a board, that (if I understood right) gets video
signal from somewhere outside the board, processes the signal with some
IPs/chips, and then outputs the signal. So there's no framebuffer, and
the image is not stored anywhere. I think the framework used in these
cases is always v4l2.

The IPs/chips in the above model may be the exact same IPs/chips that
are used with "normal" display. If the CDF was tied to DRM, using the
same drivers for normal and these streaming cases would probably not be
possible.

Well, maybe there is a way, but it really seems to be
over-complicating things unnecessarily to keep CDF independent of
DRM..  there will be a lot more traditional uses of CDF compared to
one crazy use-case.  So I don't really fancy making it more difficult
than in needs to be for everyone.

Probably the thing to do is take a step back and reconsider that one
crazy use-case.  For example, KMS doesn't enforce that the buffer
handled passed when you create a drm framebuffer object to scan out is
a GEM buffer.  So on that one crazy platform, maybe it makes sense to
have a DRM/KMS display driver that takes a handle to identify which
video stream coming from the capture end of the pipeline.  Anyways,
that is just an off-the-top-of-my-head idea, probably there are other
options too.

BR,
-R

 Tomi