On 11/11/2022 17:35, Srinivas Kandagatla wrote: > > > On 11/11/2022 11:35, Krzysztof Kozlowski wrote: >> The APR/GPR nodes are organized like: >> >> 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 > > I have not seen these grow or change alteast in the past 9 years. You added GPR to services in 2021, so it grew past 9 years. Then it grew in 2022 when I started adding missing pieces - missing compatibles and properties. > > Old APR (Elite f/w) and new GPR (AudioReach) interface provides access > to static services on the DSP. > >> considerably and is still quite not specific. It allows several >> incorrect combinations, like adding a clock-controller to a APM device. > > This should be fixed for sure for validation. This cannot be fixed without making schema over-complicated. It includes six different compatibles. Except few of them - these compatibles represent different devices. > > We had dedicated bindings per service before. Where? > > As the service has changed as part of new AudioReach Firmware, we could > have added new bindings for these services again. But as we are dealing > with the same audio hardware and clock resources a new bindings per > service did not make sense. Since then we moved all the lpass audio > ports and clocks related bindings to qcom,q6dsp-lpass-clocks.yaml and > qcom,q6dsp-lpass-ports.yaml. These are not bindings for services but bindings for their devices. Best regards, Krzysztof
