On Tue, Jul 28, 2015 at 04:39:12PM +0200, Jean-Francois Moine wrote:
On Tue, 28 Jul 2015 14:53:58 +0100 Russell King - ARM Linux linux@arm.linux.org.uk wrote:
In the case of the TDA998x, there is a 1:1 fixed relationship between the connector and the encoder. The connector part can't be used with any other encoder, and the encoder part can't be used with any other connector. The same is true of many other HDMI implementations (such as the Synopsis Designware HDMI interface found on iMX6 and Rockchip.)
But there is no direct link (pointer) between the encoder and the connector.
There's no direct link from an encoder to a connector because the DRM model allows a single encoder to be associated with multiple connectors. Adding a link from the encoder to a connector breaks that ability (an encoder would then need an array of connectors.)
If we kill the old drm_slave_encoder support in TDA998x, then this would solve the problem - we can then get at the TDA998x's drm_connector easily as it then becomes part of TDA998x's private data.
However, this doesn't matter. All that we need from the DRM side of the TDA998x is to know is the EDID or ELD. That can be broadcast via a notification (using something like the code I illustrated in a follow up email) to any listeners, whether they be an audio driver or a CEC bus driver. The audio driver may not care about HDMI connect/disconnect events, but that's no reason not to include them. Some consumers of these events need to know (CEC certainly needs to know.)