From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH v13 3/3] ASoC: tda998x: add a codec to the HDMI transmitter Date: Tue, 28 Jul 2015 15:59:45 +0200 Message-ID: References: <20150720180606.GL11162@sirena.org.uk> <20150728121945.560f82a5@armhf> <20150728102410.GD11162@sirena.org.uk> <20150728152329.02668865@armhf> <20150728135358.GK7557@n2100.arm.linux.org.uk> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 52B0B265450 for ; Tue, 28 Jul 2015 15:59:46 +0200 (CEST) In-Reply-To: <20150728135358.GK7557@n2100.arm.linux.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Russell King - ARM Linux Cc: Jean-Francois Moine , alsa-devel@alsa-project.org, devicetree@vger.kernel.org, Andrew Jackson , Jyri Sarha , Mark Brown , Dave Airlie List-Id: alsa-devel@alsa-project.org 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