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

[Jean-Francois Moine]

On Tue, 28 Jul 2015 14:53:58 +0100
Russell King - ARM Linux <linux at arm.linux.org.uk> 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.

I think that my solution should work:
- the CODEC uses a pointer in the driver private data to the ELD.
- when get_modes() is called, this pointer is reset to NULL.
  (no audio streaming is permitted).
- this function reads the EDID and this asks for hardware exchanges
  with the HDMI device.
- the EDID is then translated to ELD and the ELD pointer is set
  (audio streaming is permitted again).

Then, if audio streaming is started before get_modes() is called, the
memory treatment of the ELD may be safely done during the harware
exchanges.

> 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

My patch just wants to offer basic audio to the TDA998x.
Especially, the display device state is of no importance: audio
streaming may continue while there is no connected device.

> 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.)

I know that, but I don't know enough about all the DRM and ASoC drivers
to propose a global mechanism.

> It needs solving in a driver-agnostic way, and the normal way that happens
> is when someone comes along, wanting to add support in that area, they get
> to do the hard work to propose that infrastructure.

OK. I'll stop here.

> > You may note that, in DRM, there is no relation between the encoder and
> > the connector except at video startup time, and no relation between the
> > DRM connector and the audio CODEC (no CODEC information is returned on
> > CODEC creation and the CODEC has no private data).
> 
> 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.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/