[alsa-devel] [PATCH v13 3/3] ASoC: tda998x: add a codec to the HDMI transmitter

[Takashi Iwai]

On Tue, 28 Jul 2015 15:53:58 +0200,
Russell King - ARM Linux wrote:
> 
> On Tue, Jul 28, 2015 at 03:23:29PM +0200, Jean-Francois Moine wrote:
> > The EDID arrives in the DRM connector when video starts. The built ELD
> > may be stored either in the connector itself (default), in the encoder
> > (TDA998x device) or in some DRM/encoder/connector private data.
> 
> The ELD is stored in the DRM connector, and there _should_ be a system
> of locking which ensures that you can get at that information safely.
> 
> The ELD is only updated when the connector's get_modes() method is called,
> and the driver itself calls drm_edid_to_eld().  This all happens under
> the drm_device's struct_mutex.
> 
> So, to safely read the ELD from outside DRM, you need to take the top-level
> drm_device's struct_mutex.  That could be fraught, as that's quite a big
> lock, so an alternative would be to introduce an 'eld' lock to the driver,
> which protects the call to drm_edid_to_eld() and the reading of the ELD.
> 
> However, that doesn't solve the problem of passing the data to an audio
> driver.  What's needed there is a notification system which allows a video
> driver to broadcast HDMI events such as:
> 
> * connected
> * new EDID available
> * new ELD available
> * disconnected
> 
> With such a system, different components driving the facilities of a HDMI
> connector can make decisions on what to do - which not only includes things
> like the audio driver, but also a driver for the CEC interface (which also
> needs to see the EDID to get at its "address".)  This can be done in a safe
> manner as the HDMI video driver would have control over the generation of
> these messages.
> 
> The point that Mark is trying to get you to see is that this problem is
> not specific to TDA998x.  The same problem exists for many other HDMI
> interfaces (except maybe Intel's i9x5/HDA stuff which has a hardware
> mechanism of passing the ELD data from the video driver, through the
> hardware to the audio driver.)

FWIW, we're currently discussing about extending the i915/hda
component binding so that the audio driver gets a notification and
queries the ELD via callbacks instead of the flaky hardware access.

It'd be best if we have a common infrastructure for that, of course.
But currently it's a start, just a bit step forward there.


Takashi