On 2012-12-19 17:26, Rob Clark wrote: > On Wed, Dec 19, 2012 at 8:57 AM, Jani Nikula > <jani.nik...@linux.intel.com> wrote: >> >> Hi Laurent - >> >> On Tue, 18 Dec 2012, Laurent Pinchart <laurent.pinch...@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
signature.asc
Description: OpenPGP digital signature
