On Mon, Dec 24, 2012 at 11:27 AM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote: >> 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! > > As Rob pointed out, you can have external HDMI/DP encoders, and even internal > HDMI/DP encoder IPs can be shared between SoCs and SoC vendors. CDF aims at > sharing a single driver between SoCs and boards for a given HDMI/DP encoder. just fwiw, drm already has something a bit like this.. the i2c encoder-slave. With support for a couple external i2c encoders which could in theory be shared between devices. BR, -R -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html