On 6/2/2022 6:43 AM, Stephen Boyd wrote:
Quoting Srinivasa Rao Mandadapu (2022-06-01 03:30:14)
Add compatible string to support adsp enabled sc7280 platforms.
Signed-off-by: Srinivasa Rao Mandadapu quic_srivasam@quicinc.com Co-developed-by: Venkata Prasad Potturu quic_potturu@quicinc.com Signed-off-by: Venkata Prasad Potturu quic_potturu@quicinc.com Acked-by: Rob Herring robh@kernel.org
.../devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml index d32ee32..53c2c59 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml @@ -17,7 +17,9 @@ description: |
properties: compatible:
- const: qcom,sc7280-lpass-lpi-pinctrl
- enum:
- qcom,sc7280-lpass-lpi-pinctrl- qcom,sc7280-lpass-adsp-lpi-pinctrlCan you confirm that this is the same hardware (i.e. same reg property) but just a different compatible string used to convey that the device is using "adsp" mode or not? If so, this looks to be a common pattern for the audio hardware here, where we have two "views" of the hardware, one for adsp mode and one for not adsp mode. I guess the not adsp mode is called "adsp bypass"?
Yes Your understanding is correct. The same hardware in scenario not using ADSP,
and in another enabling DSP.
Is that right? Why are we conveying this information via the compatible string?
Could you please suggest better way!. As pin control driver is the first one to probe, I am not getting better approach.
While up-streaming these drivers, concluded to use this approach.