Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <fea60b71-4623-43f5-d81c-a0250a63c697@linaro.org>
Date:   Thu, 1 Sep 2022 10:28:49 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Subject: Re: [PATCH 2/6] ASoC: codecs: wsa-macro: add support for sm8450 and
 sc8280xp
Content-Language: en-US
To:     Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
        Rob Herring <robh@kernel.org>
Cc:     broonie@kernel.org, krzysztof.kozlowski+dt@linaro.org,
        perex@perex.cz, tiwai@suse.com,
        pierre-louis.bossart@linux.intel.com,
        linux-arm-msm@vger.kernel.org, alsa-devel@alsa-project.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20220818134619.3432-1-srinivas.kandagatla@linaro.org>
 <20220818134619.3432-3-srinivas.kandagatla@linaro.org>
 <20220818171222.GG1978870-robh@kernel.org>
 <9c9226d9-8470-6672-d8ce-3fb1e4df3fda@linaro.org>
 <5da6171a-4949-9cc7-2967-6cc39a7955c8@linaro.org>
 <a4562481-780b-585f-01a5-d447040fbd0a@linaro.org>
From:   Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
In-Reply-To: <a4562481-780b-585f-01a5-d447040fbd0a@linaro.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 31/08/2022 13:37, Srinivas Kandagatla wrote:
> 
> 
> On 31/08/2022 10:19, Krzysztof Kozlowski wrote:
>> On 31/08/2022 12:17, Srinivas Kandagatla wrote:
>>>
>>>
>>> On 18/08/2022 18:12, Rob Herring wrote:
>>>> On Thu, Aug 18, 2022 at 02:46:15PM +0100, Srinivas Kandagatla wrote:
>>>>> Add compatible for sm8450 and sc8280xp.
>>>>>
>>>>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>>>> ---
>>>>>    sound/soc/codecs/lpass-wsa-macro.c | 2 ++
>>>>>    1 file changed, 2 insertions(+)
>>>>>
>>>>> diff --git a/sound/soc/codecs/lpass-wsa-macro.c b/sound/soc/codecs/lpass-wsa-macro.c
>>>>> index 27da6c6c3c5a..f82c297ea3ab 100644
>>>>> --- a/sound/soc/codecs/lpass-wsa-macro.c
>>>>> +++ b/sound/soc/codecs/lpass-wsa-macro.c
>>>>> @@ -2561,6 +2561,8 @@ static const struct dev_pm_ops wsa_macro_pm_ops = {
>>>>>    static const struct of_device_id wsa_macro_dt_match[] = {
>>>>>    	{.compatible = "qcom,sc7280-lpass-wsa-macro"},
>>>>>    	{.compatible = "qcom,sm8250-lpass-wsa-macro"},
>>>>> +	{.compatible = "qcom,sm8450-lpass-wsa-macro"},
>>>>> +	{.compatible = "qcom,sc8280xp-lpass-wsa-macro" },
>>>>
>>>> Looks like these are backwards compatible with the existing versions,
>>>> why not reflect that in the binding?
>>> Backward compatibility is not always true, some of the registers and
>>> there defaults tend to change across SoCs. Having SoC specific
>>> compatible could help us deal with this and also make code more inline
>>> with other codec macros in LPASS IP.
>>
>> I am not saying that there should be no SoC specific compatible. This
>> one is a must, but the question why duplicating the entries and not
>> using fallback?
> 
> You mean using fallback compatible "qcom,sc7280-lpass-wsa-macro" in 
> sc8280xp devicetree and not add new compatibles in the driver?
> 
> The reason for adding this new compatible strings is that macros in this 
> lpass codec that differ form each SoC.
> ex: [PATCH 6/6] ASoC: codecs: tx-macro: add support for sm8450 and 
> sc8280xp and there is a pending patch on va-macro that has soundwire 
> controller frame sync and reset control which is moved from tx-macro to 
> va-macro.
> 
> so DT might endup with mix of compatibles for same LPASS Codec like this:
> 
> "qcom,sc7280-lpass-wsa-macro"
> "qcom,sc8280xp-lpass-va-macro"
> "qcom,sc8280xp-lpass-tx-macro"
> "qcom,sc8280xp-lpass-rx-macro"
> 
> AFAIU, the fallback thing will work for things that are identical but in 
> this case they differ across SoCs, and having SoC specific compatibles 
> in now would help handle this.

Ahh, I see now. The true problem is that driver encodes compatibles in
several places. That's very confusing design - variants should be rather
customized via driver data, not via multiple of_device_is_compatible()
inside the code.

Best regards,
Krzysztof