[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <60c9ba5d-a2b8-43cd-8b8d-2c709b8e5d04@linaro.org>
Date: Tue, 28 Nov 2023 10:04:51 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: neil.armstrong@...aro.org,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
Banajit Goswami <bgoswami@...cinc.com>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>
Cc: linux-arm-msm@...r.kernel.org, alsa-devel@...a-project.org,
linux-sound@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/5] ASoC: dt-bindings: document WCD939x Audio Codec
On 28/11/2023 09:59, Neil Armstrong wrote:
> On 24/11/2023 09:33, Krzysztof Kozlowski wrote:
>> On 23/11/2023 15:49, Neil Armstrong wrote:
>>
>>> + Qualcomm WCD9390/WCD9395 Codec is a standalone Hi-Fi audio codec IC.
>>> + It has RX and TX Soundwire slave devices.
>>> + The WCD9390/WCD9395 IC has a functionally separate USB-C Mux subsystem
>>> + accessible over an I2C interface.
>>> + The Audio Headphone and Microphone data path between the Codec and the USB-C Mux
>>> + subsystems are external to the IC, thus requiring DT port-endpoint graph description
>>> + to handle USB-C altmode & orientation switching for Audio Accessory Mode.
>>> +
>>> +allOf:
>>> + - $ref: dai-common.yaml#
>>> + - $ref: qcom,wcd93xx-common.yaml#
>>> +
>>> +properties:
>>> + compatible:
>>> + enum:
>>> + - qcom,wcd9390-codec
>>> + - qcom,wcd9395-codec
>>
>> 9395 should be compatible with 9390, so please express it with a list
>> using fallback. I know that earlier wcd93xx do not follow that concept,
>> but maybe we will fix them some point as well.
>
> I don't get why this would be needed, yes their are compatible but still
> two separate ICs with different internal capabilities.
>
> It the first time I get such request for new documentation
Maybe it is first time for you, but I ask about this all the time. What
is important is whether the programming model or how the OS uses the
device is the same.
Here the device exposes its version in registers, so you can easily rely
on the compatibility. That's also the case multiple times talked on the
mailing lists.
Best regards,
Krzysztof
Powered by blists - more mailing lists