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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
