Received: by 10.223.185.111 with SMTP id b44csp184970wrg; Fri, 9 Mar 2018 03:21:24 -0800 (PST) X-Google-Smtp-Source: AG47ELtbeGEFm9FejNn/OS3mp1fvUffKedg5F/SvooE0JOI7k5xNp+OFIQWsf+O6SXOwEOI4Gpiu X-Received: by 10.99.60.8 with SMTP id j8mr24064422pga.209.1520594484554; Fri, 09 Mar 2018 03:21:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520594484; cv=none; d=google.com; s=arc-20160816; b=XhOeDoCR38amxIN8b1RlsTa+RA7gZfNogP1qMBm/6Pw/pxIhPO9PybSkVTMXE5423N WeMCsMWisl1eKt486xCRvvkq3ImwpTB+khzmOBU8dfyGd3PtHp9zGleKd/wCUWgIx3Fq efwlhcbIqhRqP5BNla2zgMcZEW0tTaolULwVwISPyadDp/o8goPgd7hULvzttPBKy5MO wL0NEaZgIiWnjKGfOPoGf2wTF+zNGOPxFoS0hCWNLH7gOeAuNkLmsVzHaS2eD4TVRfSJ Ep2te2iMCZkASjWHr7Lq+AZRgwINn2PIaz39N3+7Zw3btMWggAVjw4zwC6w+FF/1DmPn xVpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=yZ5k5L7YkTcNbkYxk7kzMc3nfga7c21hnqfZGrdYPC4=; b=WVVIEkKsltoVUnyoeDNMgkohzm10m+hvKnX0mJVN3RBqtTUukdCh3P2N29oIr5nIw6 L1iI8wqHoXxxwBV0bMAQWhiLv/G48WUIZjVSWm0m5MBW8RuAUhHRYSMzSKYVhu1n3fPJ PwN8NLhkJET/rlfuRnittrIAO7S0Mn83pJ8cuX0JvwmzzvEnVv/q/C4eKkmpu0kQ8Rn+ 971fB3/j3hE7dIfPzJwsVr/vzfgsniqFn9j191WKWkxZl5fqGegrvv6Z2sGL/P5H1PIW gXaGV2zzRlNuXCDnDOT/lOX52VAySnLjRHim7TMGujUSK2OdpW4eTq1W4gAnE+ARN/LX m4eQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.co.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w71si591035pgd.435.2018.03.09.03.21.09; Fri, 09 Mar 2018 03:21:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.co.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751137AbeCILTo (ORCPT + 99 others); Fri, 9 Mar 2018 06:19:44 -0500 Received: from bhuna.collabora.co.uk ([46.235.227.227]:38854 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750926AbeCILTm (ORCPT ); Fri, 9 Mar 2018 06:19:42 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: sre) with ESMTPSA id 3CEFE270207 Date: Fri, 9 Mar 2018 12:19:38 +0100 From: Sebastian Reichel To: Lee Jones Cc: Mark Brown , Liam Girdwood , Rob Herring , Tony Lindgren , Jaroslav Kysela , Takashi Iwai , alsa-devel@alsa-project.org, linux-omap@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, kernel@collabora.com Subject: Re: [PATCHv5 3/5] mfd: motorola-cpcap: Add audio-codec support Message-ID: <20180309111938.irzwypdehuckx35s@earth.universe> References: <20180223200254.25685-1-sebastian.reichel@collabora.co.uk> <20180223200254.25685-4-sebastian.reichel@collabora.co.uk> <20180307163211.rytfli5tb47yhtug@dell> <20180308094652.qg4atjw5c3hayaz3@earth.universe> <20180308095315.mpcmx2ob6yhsnrm6@dell> <20180308102757.jyi7uo566n6nuct5@earth.universe> <20180308104831.fflq2arj5dxgntia@dell> <20180308112528.GC6019@sirena.org.uk> <20180309083414.s57eq3kw325magwz@dell> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ivv5fbufhe273ms5" Content-Disposition: inline In-Reply-To: <20180309083414.s57eq3kw325magwz@dell> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --ivv5fbufhe273ms5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 09, 2018 at 08:34:14AM +0000, Lee Jones wrote: > On Thu, 08 Mar 2018, Mark Brown wrote: >=20 > > On Thu, Mar 08, 2018 at 10:48:31AM +0000, Lee Jones wrote: > > > On Thu, 08 Mar 2018, Sebastian Reichel wrote: > >=20 > > > > I had it in PATCHv1-PATCHv4. It was removed, since Mark didn't want > > > > to have it in the DT ABI. > >=20 > > > Right, but why? Is it not a hardware device? I think converting from > > > devm_of_platform_populate() for one sub-device is a bit drastic. > >=20 > > It's not a separate physical device or IP and doesn't exist outside of > > the MFD, it's just how Linux is currently choosing to divide up the chip > > right now but that's totally open to change even in future versions of > > Linux. Clocks are a big issue with audio stuff, right now sections of > > the clock tree get handled in the CODEC driver but we're going to want > > to push them out to a clock driver so we're not reimplementing handling > > for clocks. >=20 > How is the CODEC controlled? Does it have its own registers? I guess > by "it's not a separate device or IP" you mean that it doesn't. But > that begs the question, how does this then device differ from all the > other devices (adc, battery, charger, regulator, rtc, pwrbutton, > usb-phy and led)? The audio codec goes from register 0x0800 - 0x0844, with the next register being defined @ 0x0a00. So it definetly has its own register range. I should note though, that 0x0800 is the audio regulator control. In Linux we handle this one in the regulator driver instead of in the audio driver. But this is mostly hidden in DT (the voltage ranges for VAUDIO are described in the regulator node now). > I'm asking, not to be awkward, but to avoid 50 lines of potentially > unnecessary static code. If this is a real (sub-)device, even if it's > part of a larger, single device (MFD) then there is no reason why it > can't be represented as a single, albeit empty node. We still have the node, so that it can be used with the ASoC graph binding. It just has no compatible value. Instead it is identified by the node's name. -- Sebastian --ivv5fbufhe273ms5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE72YNB0Y/i3JqeVQT2O7X88g7+poFAlqibcIACgkQ2O7X88g7 +poGPQ//dQYd94GdQfmyfdDyXAC/omHEGe7FldYHVAVPT6AzxYAOKg4ngjLd7JC1 07m/jJTSzutPBNkwFvqn5FoTscZOeWobnEQThZpSaCfsyKu+rj6p1NgUUMSXhjCd kwQVvMmnqBWSOLVaRYsYsGpCC5wAUTzZR7eSDy0IQ8QJ0yQ/3PVOgclQYkPtgOiY PcoKiFKNFXE1jz265Vi5UkHw87iMMJT5i6cbd2jrZX/TZ99cSjRXUXA4op3PRFaa 3S2UNbcanZfA+hWEdrkM+6v1lPViUSo5paH7zV9Z8Jk8xlc+djfMiBSRyFUfJy/R yIgxzrBSzlXio/hnqb0zP2xOkq991keIttFmu6wPDXjqTl9HaeGkliJI0TbV0h44 9e84idVdlHuxF3kbdws7j99TFiTYzc3C9bC1ma/OFpDUbfV9fRrGTnj4NurRmkCh 4fcBR7DkGaw1DDtHvLpoCfZlyDymG9sm72iRM8YDZSsWHdU2uXMMrcBEOS1z7qiV 5gQhF0/VjyA/3nWs4Vxt+f2OeYYzo4AJaHum9il0qu1raxgWSMhpu6yiARH5Kf64 wpYbF7I278l1Yz/yIXDV5iNSRUVyvlRq8Qmq7OSoDcNWhduqGfeRyzMSnLXiI4Pm yjN5jVBQzJ/NJvOAjqFs8OzxVMeyYtYvD4gV/Sy9wBeMCGTXGnU= =nLMT -----END PGP SIGNATURE----- --ivv5fbufhe273ms5--