Hi Rob, (CC'ing Hans Verkuil) On Wednesday 19 December 2012 10:05:27 Rob Clark wrote: > On Wed, Dec 19, 2012 at 9:37 AM, Tomi Valkeinen wrote: > > On 2012-12-19 17:26, 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. > > > > 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. Most of the use cases will be in DRM, we agree on that. However, I don't think that the use case mentioned by Tomi is in any way crazy. TI has DaVinci chips that can process/capture/generate up to 18 (if my memory is correct) video streams, and those are extensively used in video conferencing solutions or set top boxes for instance. A couple of the output video streams are display-based and should be handled by DRM/KMS, but most of them are V4L2 streams. That's something we should discuss with Hans Verkuil, he might be able to provide us with more information. > 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. -- Regards, Laurent Pinchart _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
