Re: [PATCH 2/2] arm64: dts: qcom: sm8750-mtp: Add sound (speakers, headset codec, dmics)

[neil.armstrong@linaro.org]

On 30/04/2025 12:48, Konrad Dybcio wrote:
> On 4/30/25 8:19 AM, Krzysztof Kozlowski wrote:
>> On 29/04/2025 21:11, Konrad Dybcio wrote:
>>> On 4/28/25 4:41 PM, Krzysztof Kozlowski wrote:
>>>> On 25/04/2025 11:30, Konrad Dybcio wrote:
>>>>> On 4/24/25 11:40 AM, Krzysztof Kozlowski wrote:
>>>>>> Add device nodes for most of the sound support - WSA883x smart speakers,
>>>>>> WCD9395 audio codec (headset) and sound card - which allows sound
>>>>>> playback via speakers and recording via DMIC microphones.  Changes bring
>>>>>> necessary foundation for headset playback/recording via USB, but that
>>>>>> part is not yet ready.
>>>>>>
>>>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>>>> ---
>>>>>
>>>>> [...]
>>>>>
>>>>>> +	sound {
>>>>>> +		compatible = "qcom,sm8750-sndcard", "qcom,sm8450-sndcard";
>>>>>> +		model = "SM8750-MTP";
>>>>>> +		audio-routing = "SpkrLeft IN", "WSA_SPK1 OUT",
>>>>>> +				"SpkrRight IN", "WSA_SPK2 OUT",
>>>>>> +				"IN1_HPHL", "HPHL_OUT",
>>>>>> +				"IN2_HPHR", "HPHR_OUT",
>>>>>> +				"AMIC2", "MIC BIAS2",
>>>>>> +				"VA DMIC0", "MIC BIAS3", /* MIC4 on schematics */
>>>>>> +				"VA DMIC1", "MIC BIAS3", /* MIC1 on schematics */
>>>>>
>>>>> Is this a mistake in what the codec driver exposes, or just a fumble
>>>>> in numbering $somewhere?
>>>>
>>>> Which mistake? MIC4? Schematics call name things differently. They
>>>> always were, so to make it clear for people without schematics I wrote
>>>> which MIC it actually is.
>>>
>>> I'm not sure how to parse your response
>>>
>>> are you saying that there are MIC[0..4] that are/may be connected
>>> to different codec ports, and that the MIC4/1 lines are plumbed to
>>> VA DMIC0/1 respectively?
>>
>> Yes, as always. Nothing weird here.
>>
>>>
>>> I think I got confused about the MIC BIAS3 going to both and none
>>
>> What is both and none?
> 
> missing Oxford comma I suppose.. MIC BIAS3 goes to both MIC4 and MIC1
> and neither of them has a '3' in the name. I was wondering whether
> that's intentional.
> 
>>
>>> matching the index, but perhaps that's just because it comes from
>>> the WCD (which is the third piece of hw involved beyond VA and the
>>> mic itself)
>>
>> Again, what is the mistake you are pointing here?
> 
> I'm not necessarily saying this is a mistake, just thinking out loud
> how I understand the non-obvious plumbing
> 
> [...]
> 
>>>>>> +		/*
>>>>>> +		 * WCD9395 RX Port 1 (HPH_L/R)      <=> SWR1 Port 1 (HPH_L/R)
>>>>>> +		 * WCD9395 RX Port 2 (CLSH)         <=> SWR1 Port 2 (CLSH)
>>>>>> +		 * WCD9395 RX Port 3 (COMP_L/R)     <=> SWR1 Port 3 (COMP_L/R)
>>>>>> +		 * WCD9395 RX Port 4 (LO)           <=> SWR1 Port 4 (LO)
>>>>>> +		 * WCD9395 RX Port 5 (DSD_L/R)      <=> SWR1 Port 5 (DSD_L/R)
>>>>>> +		 * WCD9395 RX Port 6 (HIFI_PCM_L/R) <=> SWR1 Port 9 (HIFI_PCM_L/R)
>>>>>> +		 */
>>>>>> +		qcom,rx-port-mapping = <1 2 3 4 5 9>;
>>>>>
>>>>> Does this deserve some dt-bindings constants?
>>>>
>>>> No, because these are hardware details/constants. Drivers do not use them.
>>>
>>> I'd argue it makes sense here - it makes more sense to pass meaningfully
>>> named constants to the driver, rather than blobs with a comment
>>
>> Sense of what? You want to make it a binding then answer what does it
>> bind, what part of ABI for driver is here a binding (answer none:
>> because driver does not use it)?
> 
> Sense of the magic numbers that otherwise require a comment.

There's no magic numbers, index of qcom,rx-port-mapping is the RX port,
value is the SWR1 port index. As the property name says, it maps RX ports.

The comment is here to understand why we map as-is, and what the ports are
used for, but for the soundwire perspective only the numbers matters.

> 
> dt-bindings don't exclusively contain enums-turned-defines that are
> indices of C arrays - some contain various forms of hardware ABI, be
> it register addresses, or names for magic values
> 
> Konrad
>