diff mbox series

[1/3] ASoC: dt-bindings: wcd93xx: add bindings for audio switch controlling hp

Message ID 20250319091637.4505-2-srinivas.kandagatla@linaro.org (mailing list archive)
State Superseded
Headers show
Series ASoC: wcd938x: enable t14s audio headset | expand

Commit Message

Srinivas Kandagatla March 19, 2025, 9:16 a.m. UTC
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>

On some platforms to minimise pop and click during switching between
CTIA and OMTP headset an additional HiFi Switch is used. Most common
case is that this switch is switched on by default, but on some
platforms this needs a regulator enable.

This patch adds required bindings to add such regulator.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
 .../devicetree/bindings/sound/qcom,wcd93xx-common.yaml        | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Dmitry Baryshkov March 19, 2025, 10:01 a.m. UTC | #1
On Wed, Mar 19, 2025 at 09:16:35AM +0000, srinivas.kandagatla@linaro.org wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> 
> On some platforms to minimise pop and click during switching between
> CTIA and OMTP headset an additional HiFi Switch is used. Most common
> case is that this switch is switched on by default, but on some
> platforms this needs a regulator enable.

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 patch adds required bindings to add such regulator.
> 
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
>  .../devicetree/bindings/sound/qcom,wcd93xx-common.yaml        | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd93xx-common.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd93xx-common.yaml
> index f78ba148ad25..fa00570caf24 100644
> --- a/Documentation/devicetree/bindings/sound/qcom,wcd93xx-common.yaml
> +++ b/Documentation/devicetree/bindings/sound/qcom,wcd93xx-common.yaml
> @@ -26,6 +26,10 @@ properties:
>    vdd-mic-bias-supply:
>      description: A reference to the 3.8V mic bias supply
>  
> +  vdd-hp-switch-supply:
> +    description: A reference to the audio switch supply
> +      for switching CTIA/OMTP Headset
> +
>    qcom,tx-device:
>      $ref: /schemas/types.yaml#/definitions/phandle-array
>      description: A reference to Soundwire tx device phandle
> -- 
> 2.39.5
>
Srinivas Kandagatla March 19, 2025, 3:59 p.m. UTC | #2
On 19/03/2025 10:01, Dmitry Baryshkov wrote:
> On Wed, Mar 19, 2025 at 09:16:35AM +0000, srinivas.kandagatla@linaro.org wrote:
>> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>
>> On some platforms to minimise pop and click during switching between
>> CTIA and OMTP headset an additional HiFi Switch is used. Most common
>> case is that this switch is switched on by default, but on some
>> platforms this needs a regulator enable.
> 
> 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.

--srini
> 
>> This patch adds required bindings to add such regulator.
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> ---
>>   .../devicetree/bindings/sound/qcom,wcd93xx-common.yaml        | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd93xx-common.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd93xx-common.yaml
>> index f78ba148ad25..fa00570caf24 100644
>> --- a/Documentation/devicetree/bindings/sound/qcom,wcd93xx-common.yaml
>> +++ b/Documentation/devicetree/bindings/sound/qcom,wcd93xx-common.yaml
>> @@ -26,6 +26,10 @@ properties:
>>     vdd-mic-bias-supply:
>>       description: A reference to the 3.8V mic bias supply
>>   
>> +  vdd-hp-switch-supply:
>> +    description: A reference to the audio switch supply
>> +      for switching CTIA/OMTP Headset
>> +
>>     qcom,tx-device:
>>       $ref: /schemas/types.yaml#/definitions/phandle-array
>>       description: A reference to Soundwire tx device phandle
>> -- 
>> 2.39.5
>>
>
Mark Brown March 19, 2025, 4:03 p.m. UTC | #3
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.
Srinivas Kandagatla March 19, 2025, 6 p.m. UTC | #4
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
Krzysztof Kozlowski March 20, 2025, 9:31 a.m. UTC | #5
On Wed, Mar 19, 2025 at 06:00:51PM +0000, Srinivas Kandagatla wrote:
> 
> 
> 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.

Looking at schematics this is clearly not a supply of a codec, but as
Dmitry said, separate switch. Actually two switches.

Best regards,
Krzysztof
Srinivas Kandagatla March 20, 2025, 10:51 a.m. UTC | #6
On 20/03/2025 09:31, Krzysztof Kozlowski wrote:
> On Wed, Mar 19, 2025 at 06:00:51PM +0000, Srinivas Kandagatla wrote:
>>
>>
>> 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.
> 
> Looking at schematics this is clearly not a supply of a codec, but as
> Dmitry said, separate switch. Actually two switches.

AFAIU, Adding single mux for both seems to be the best option.
Eventhough physically they are two muxes but they can not be driven 
independently, and logically/functionally they are doing only one thing 
of handing us/euro headset.


But if we represent these two muxes as two different nodes then the 
driver is messed up, as all the resources (gpios. pinctrls, regultors) 
will be shared and we can not control them independently.



thanks,
Srini
> 
> Best regards,
> Krzysztof
>
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd93xx-common.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd93xx-common.yaml
index f78ba148ad25..fa00570caf24 100644
--- a/Documentation/devicetree/bindings/sound/qcom,wcd93xx-common.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,wcd93xx-common.yaml
@@ -26,6 +26,10 @@  properties:
   vdd-mic-bias-supply:
     description: A reference to the 3.8V mic bias supply
 
+  vdd-hp-switch-supply:
+    description: A reference to the audio switch supply
+      for switching CTIA/OMTP Headset
+
   qcom,tx-device:
     $ref: /schemas/types.yaml#/definitions/phandle-array
     description: A reference to Soundwire tx device phandle