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