Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755518AbbESLQ3 (ORCPT ); Tue, 19 May 2015 07:16:29 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:47024 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754521AbbESLQW (ORCPT ); Tue, 19 May 2015 07:16:22 -0400 Date: Tue, 19 May 2015 12:16:02 +0100 From: Mark Brown To: Lars-Peter Clausen Cc: Dylan Reid , "alsa-devel@alsa-project.org" , Heiko =?iso-8859-1?Q?St=FCbner?= , zhengxing , Takashi Iwai , "linux-kernel@vger.kernel.org" , Douglas Anderson , Xing Zheng , Liam Girdwood , linux-rockchip@lists.infradead.org, Sonny Rao , "linux-arm-kernel@lists.infradead.org" Message-ID: <20150519111602.GG2761@sirena.org.uk> References: <1431422797-31903-1-git-send-email-zhengxing@rock-chips.com> <1431422797-31903-2-git-send-email-zhengxing@rock-chips.com> <20150512192215.GZ3066@sirena.org.uk> <55535035.5070608@rock-chips.com> <20150513164250.GB2761@sirena.org.uk> <555659DB.9010204@metafoo.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vjcY9ywptAIx3JpL" Content-Disposition: inline In-Reply-To: <555659DB.9010204@metafoo.de> X-Cookie: 13. ... r-q1 User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 94.175.94.161 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [alsa-devel] [PATCH 1/4] ASoC: rockchip: add rockchip machine driver X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2259 Lines: 52 --vjcY9ywptAIx3JpL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, May 15, 2015 at 10:40:59PM +0200, Lars-Peter Clausen wrote: > I think the proper way to support this is come up with the concept of jack > detection providers and consumers. A component can register a jack detection > provider just like it can register a DAI. And then in the board driver you'd > just link the jack detection logic to the jack using the usual approach, > which is also used for DAIs (e.g. of node or device name). The core would > then take care of calling a enable callback or whatever is required to setup > the jack detection logic in the driver. Yes, nobody has really cared about it since we started pushing things out of the card init into the device level. We would also need to add a way to force microphone biases on for devices where that's not a part of the jack detection IP. > This would also nicely solve the issue with the GPIO jack detectors, where > we currently can't really handle -EPROBE_DEFER. The GPIO would be requested > by a jack detection provider which can request them before the card is > registered rather than having to do the requesting in the card's init > callback. Cards should be able to do their requesting in their probe function prior to registering with the core even without anything else, though that needs a bit or refactoring too. --vjcY9ywptAIx3JpL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVWxtxAAoJECTWi3JdVIfQkLIH/2cJwvtJ0Xppc1u7IP1bJWLL xjNk6s+qb4Ewcsq1bLsCgx+mUpXoONjBfbNZ2mYpRMr40L14565sEBHwk44uYesw oM3cfpXROKcGIznnnodqdYvG/6AxATEUBBAHidNKCk+HgCfPTdiaYb1Nn/vul7fA 0p5wJfSaMdDk6wQjm7oUIN1+woOQ+29b1tTZ1whSZV3My2b+up50/dDlxl8yuVzJ S2ytgHVD/APOCiEmxYvIDQ5kV0Gk5rmX6XSFYp36TPc9IIGGYE61tb4dGLSWLy6U VZ9rAj18WyJGAK2Wy2E1xq9R84gSLuegzGlG+ZwVvoYG1EiFyXptmB9cuJpHa7E= =t67s -----END PGP SIGNATURE----- --vjcY9ywptAIx3JpL-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/