Re: [RFC v2 0/5] Common Display Framework
From: Sascha Hauer <s.hauer@pengutronix.de>
Date: 2012-12-27 19:19:17
Also in:
dri-devel, linux-media
On Thu, Dec 27, 2012 at 10:04:22AM -0600, Rob Clark wrote:
On Mon, Dec 24, 2012 at 11:27 AM, Laurent Pinchart [off-list ref] wrote:quoted
On Wednesday 19 December 2012 16:57:56 Jani Nikula wrote:quoted
It just seems to me that, at least from a DRM/KMS perspective, adding another layer (ÍF) 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.
The problem with this code is that it only works when the i2c device is registered by a master driver. Once the i2c device comes from the devicetree there is no possibility to find it. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |