Received: by 10.223.185.111 with SMTP id b44csp262784wrg; Fri, 9 Mar 2018 04:41:37 -0800 (PST) X-Google-Smtp-Source: AG47ELuM9wTIyb9BviC8FsR9zPm9F1s90bCtXasFaDQ59+awQp4LyoQ+TBwW1vEwTPZpySMRE5YP X-Received: by 10.101.70.10 with SMTP id v10mr24283488pgq.327.1520599297645; Fri, 09 Mar 2018 04:41:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520599297; cv=none; d=google.com; s=arc-20160816; b=J4RJhxoYWr6jiMEK2z2WI2JU84Wm9E9aGks0GERfgUeqO9NHyO/5nXH27HhWqHj1oA fieyEhgrxTrdYdjEiATmMtJPEmnVnjzo25jYR8wjCbImOPyKtvMyUMl30buVDpgWLLp6 kg63t0NwGHXvaPgfH9SJX9tdOS7DnZAql9sTy7ch5h9b1B89atT3D65eI0DShpYjy6nr 4Cij3lhLjvUSct5XrLUJw2TSsOvFy4zZLiS4iiQ9zuDgzIsImiWz75cJsEtD/K9DDJt8 Gm3ecOjKDPOgndCNSg5cW+fQW0cERpyj3dhjtMWJcLS0xTZwdz+PjkKmqe7z6z6WK4dK YwvA== 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:dkim-signature:arc-authentication-results; bh=TMbebB1OvQy2yLiQsnfxZNb8n9KPX1lG/VJ/IGSUHGM=; b=KjViEdinkFGUa5RlyEg2paOM5CdcL5MJj4H1WQNFiEpJfNdjFRvxoviTXxNGHHAp/4 J1g0zBB23cn77otQ0J8RHXZ0os6t/fHgInPT8XYEwEnQSM4wWQcvumwjUNNCXCF5ViN0 p5dwyyfLti2ht8xbwnlcRxJQ3MmNJ3mSyAbpa3hNpXk4wvNsYvC1GVgAexKIM3fhryxw LTHdPrrwn9iPcpgl1G8lhzaSwOMPfggw2xyh8VMfuvjZU6nTcpEnupIfvKUh2VLTTXGQ xBbX900dU9WWu9/2H/qbUpK2lz10BAxrom9kYSi/1vgVI6UzxezDcSclzlYbDoaM+cLS bAQg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=bgwo74Yu; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x21-v6si811728pln.416.2018.03.09.04.41.23; Fri, 09 Mar 2018 04:41:37 -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; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=bgwo74Yu; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751235AbeCIMke (ORCPT + 99 others); Fri, 9 Mar 2018 07:40:34 -0500 Received: from heliosphere.sirena.org.uk ([172.104.155.198]:60808 "EHLO heliosphere.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751106AbeCIMkc (ORCPT ); Fri, 9 Mar 2018 07:40:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sirena.org.uk; s=20170815-heliosphere; h=In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TMbebB1OvQy2yLiQsnfxZNb8n9KPX1lG/VJ/IGSUHGM=; b=bgwo74Yuxe6jgb1+cPiWEtP+R S1un5MMksNhWVn2HhsmLLpovHbCR5kISPBFQoTkc5VZHpz2swXZgNy42ZXjGvVyLgRcvFMsYXdaQy Ipt7jT4AHc6ysiJYvN8pP+8bpTh+ktM6LhhiqRuKiAaKSqnaabjeuUXMo6FN9vA3acFYM=; Received: from debutante.sirena.org.uk ([2001:470:1f1d:6b5::3] helo=debutante) by heliosphere.sirena.org.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1euHJq-0006Tl-7j; Fri, 09 Mar 2018 12:40:18 +0000 Received: from broonie by debutante with local (Exim 4.90_1) (envelope-from ) id 1euHJp-0006Ph-Fc; Fri, 09 Mar 2018 12:40:17 +0000 Date: Fri, 9 Mar 2018 12:40:17 +0000 From: Mark Brown To: Lee Jones Cc: Sebastian Reichel , 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: <20180309124017.GB5252@sirena.org.uk> 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="7ZAtKRhVyVSsbBD2" Content-Disposition: inline In-Reply-To: <20180309083414.s57eq3kw325magwz@dell> X-Cookie: Beam me up, Scotty! User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --7ZAtKRhVyVSsbBD2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Mar 09, 2018 at 08:34:14AM +0000, Lee Jones wrote: > On Thu, 08 Mar 2018, Mark Brown wrote: > > 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. > 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)? I'm not convinced that this is a particularly good idea for the other functions but anyway... the big thing here is that in these devices the CODEC is generally not the level that the IP is created at, it's a collection of interlinked IPs which usually includes not only audio stuff but also some clocking stuff. The repeatable blocks that could get reused independently are generally a level down from the CODEC level, for example if you look at something like wm8994 there's a couple of identical FLL IPs which could make sense to enumerate individually in the DT. The top level generally doesn't get reused and is purely an encoding of what Linux is currently doing. Regulators have a bit of this going on as well - you can see it in the wm831x series of drivers where the devices have a bunch of consistently defined regulators that are laid out in various configurations so we have one platform device per physical regulator (not sure if that ever got converted to DT). Most of the other things you list are more at the level of the FLL where it's a single thing doing a single task that is likely to be repeated somewhere else as a block so there's more sense, though how often that actually happens can be questionable. > 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. It never used to be that complicated to define MFD functions? It was a data table and then a function call to register the table en masse. Certainly not anything it's worth defining an ABI to avoid. --7ZAtKRhVyVSsbBD2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlqigLAACgkQJNaLcl1U h9DJuAf+NhAk75SkmSnRIolTBoRHF2VIQd9lA7wM+lO6eOm3jWi8r3tCL01tF6Gq kr9LEsRjVv2P5KeG2gT0n+JX/PFI8pdJ0RS1zvRclp0QcHNGc80LhRrH1togHwPz 2y1bIFOsOnerMVdzEcO0z2tmDzRV1EJ6H9w30ib2ITCmZv4M9/EW2C7U/mEkjh97 HbeOBLPNYxIfXZezy8D+WCzqHW0ThZ/tN6nMTtGahoQGoYH5pCF4f7o4geagw0zB SFhZOXoS58z2WU06hWTOPq6mlG097zm8KIm23ex7mhdiKBYk8aqT17jn3Cbzate8 EW3CO/jYZdzf+pACbY/NcLmXkJLfeg== =62I+ -----END PGP SIGNATURE----- --7ZAtKRhVyVSsbBD2--