On 14/11/2022 07:48, Krzysztof Kozlowski wrote:
On 11/11/2022 17:15, Srinivas Kandagatla wrote:
On 11/11/2022 11:35, Krzysztof Kozlowski wrote:
Adding sound support for Qualcomm SM8450 SoC (and later for SC8280XP) brought
some changes to APR/GPR services bindings. These bindings are part of
qcom,apr.yaml:
apr-or-gpr-device-node <- qcom,apr.yaml
apr-gpr-service@[0-9] <- qcom,apr.yaml
service-specific-components <- /schemas/sound/qcom,q6*.yaml
The schema for services (apr-gpr-service@[0-9]) already grows considerably and
is still quite not specific. It allows several incorrect combinations, like
adding a clock-controller to a APM device. Restricting it would complicate the
schema even more. Bringing new support for sound on Qualcomm SM8450 and
SC8280XP SoC would grow it as well.
Why would this grow? All the dsp services are static and they will not
change per SoC unless there is a total firmware change in DSP.
They grow now with SM8450 which requires changes there. Otherwise DTS
does not pass with current bindings. The bindings before my fixing in
2022 were really incomplete. Now they are complete, but:
1. Not for SM8450 - this will bring new things,
2. Very unspecific as they allow multiple invalid configurations.
Okay, I looked at all the patches, they are fine as it is, the confusion
part is the subject and comments which are misleading and trying to say
that these are specific to SM8450 or SC8280XP. Infact this is not true,
none of these changes are specific to any SoC, they are part of AudioReach.
--srini
Refactor the bindings before extending them for Qualcomm SM8450 SoC.
I dont understand this bit, what is SoC audio support to do with DSP
bindings. DSP bindings should be totally independent of this.
APR/GPR bindings are for SoC audio, so while adding SoC audio the first
are affected. If you went through the commits here, you would notice the
changes.
Best regards,
Krzysztof
