[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <938cb09f-3fb1-4daf-802d-2d95222f30db@linaro.org>
Date: Wed, 19 Mar 2025 18:00:51 +0000
From: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To: Mark Brown <broonie@...nel.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
andersson@...nel.org, lgirdwood@...il.com, robh@...nel.org,
krzk+dt@...nel.org, conor+dt@...nel.org, konradybcio@...nel.org,
perex@...ex.cz, tiwai@...e.com, dmitry.baryshkov@...aro.org,
linux-sound@...r.kernel.org, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
johan+linaro@...nel.org
Subject: Re: [PATCH 1/3] ASoC: dt-bindings: wcd93xx: add bindings for audio
switch controlling hp
On 19/03/2025 16:03, Mark Brown wrote:
> On Wed, Mar 19, 2025 at 03:59:23PM +0000, Srinivas Kandagatla wrote:
>> On 19/03/2025 10:01, Dmitry Baryshkov wrote:
>
>>> Is this regulator supplying the codec or some external component? In the
>>> latter case it's likely that it should not be a part of WCD bindings.
>
>> This is regulator powering a mux that is driven by gpio which is part of
>> codec binding. So I would assume this will fall into the codec.
>
>> Where would we fit this if not part of codec?
>
>> Unless we mark this regulator as always on.
>
> I would expect that the mux would appear in the DT and consume both the
> GPIO and the regulator.
Yes, its doable, so we would endup with a mux driver consuming regulator
and gpio and move the gpio handling in codec to move to use mux control.
Let met try that and see how it looks like.
--srini
Powered by blists - more mailing lists