On 2012-12-19 17:26, Rob Clark wrote: > On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula > <jani.nikula at linux.intel.com> wrote: >> >> Hi Laurent - >> >> On Tue, 18 Dec 2012, Laurent Pinchart <laurent.pinchart at ideasonboard.com> >> wrote: >>> Hi Jani, >>> >>> On Monday 17 December 2012 18:53:37 Jani Nikula wrote: >>>> I can see the need for a framework for DSI panels and such (in fact Tomi >>>> and I have talked about it like 2-3 years ago already!) but what is the >>>> story for HDMI and DP? In particular, what's the relationship between >>>> DRM and CDF here? Is there a world domination plan to switch the DRM >>>> drivers to use this framework too? ;) Do you have some rough plans how >>>> DRM and CDF should work together in general? >>> >>> There's always a world domination plan, isn't there ? :-) >>> >>> I certainly want CDF to be used by DRM (or more accurately KMS). That's what >>> the C stands for, common refers to sharing panel and other display entity >>> drivers between FBDEV, KMS and V4L2. >>> >>> I currently have no plan to expose CDF internals to userspace through the >>> KMS >>> API. We might have to do so later if the hardware complexity grows in such a >>> way that finer control than what KMS provides needs to be exposed to >>> userspace, but I don't think we're there yet. The CDF API will thus only be >>> used internally in the kernel by display controller drivers. The KMS core >>> might get functions to handle common display entity operations, but the bulk >>> of the work will be in the display controller drivers to start with. We will >>> then see what can be abstracted in KMS helper functions. >>> >>> Regarding HDMI and DP, I imagine HDMI and DP drivers that would use the CDF >>> API. That's just a thought for now, I haven't tried to implement them, but >>> it >>> would be nice to handle HDMI screens and DPI/DBI/DSI panels in a generic >>> way. >>> >>> Do you have thoughts to share on this topic ? >> >> 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! > > fwiw, I think there are at least a couple cases where multiple SoC's > have the same HDMI IP block. > > 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. Tomi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/f9ad56fe/attachment-0001.pgp>
