From mboxrd@z Thu Jan 1 00:00:00 1970 From: Srinivas Kandagatla Subject: Re: [PATCH 2/6] ASoC: wcd934x: add support to wcd9340/wcd9341 codec Date: Wed, 3 Jul 2019 13:06:25 +0100 Message-ID: <8edd8bc6-4b32-7f7e-2521-d7038a4ffb8d@linaro.org> References: <20190702080920.22623-1-srinivas.kandagatla@linaro.org> <20190702080920.22623-3-srinivas.kandagatla@linaro.org> <20190702144411.GP2793@sirena.org.uk> <2e2a32dd-3dca-5391-1bfa-ab1c1f420e3a@linaro.org> <20190702165753.GQ2793@sirena.org.uk> <0a9a994c-5a88-539f-3af0-76754b9b58d1@linaro.org> <20190703115243.GV2793@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20190703115243.GV2793@sirena.org.uk> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" To: Mark Brown Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, alsa-devel@alsa-project.org, bgoswami@codeaurora.org, lgirdwood@gmail.com, vkoul@kernel.org, robh+dt@kernel.org, srini@kernel.org List-Id: devicetree@vger.kernel.org On 03/07/2019 12:52, Mark Brown wrote: > On Wed, Jul 03, 2019 at 09:49:37AM +0100, Srinivas Kandagatla wrote: >> On 02/07/2019 17:57, Mark Brown wrote: > >>> This is a driver for a single device, you should be able to >>> instantiate things without requiring binding through DT (and >>> hence support non-DT systems such as those using ACPI). > >> My view point atleast from hw side was that Codec is Parent which is >> encompassing these different blocks and bus interface. DT representation >> clearly showed that relationship between the parent and child devices. >> Binding it through DT will make sure that resources are ready before >> they are instantiated. > >> All the child devices also have some machine/board specific properties >> and dependency on resources from parent like regmap, clks, and bus. > >> In ACPI case, am not 100% sure how these will be represented inline with >> hw representation. > >> Are you suggesting to use MFD here? > > I'm saying that you should be using a MFD here like all the other > CODECs with multiple functions and that you shouldn't have > compatible strings in DT for the subfunctions since you already > know they'll be there simply from enumerating the chip as a whole > and how exactly they are divided up is a function of how Linux > currently has subsystems, not of the hardware. > Got it!, thanks for the input, I will change that in v2. --srin