[02/13] arm64: dts: qcom: msm8916/39: Add QDSP6
Commit Message
MSM8916 and MSM8939 do not have a dedicated ADSP. Instead, the audio
services via APR are also implemented by the modem DSP. Audio can be
either routed via the modem DSP (necessary for voice call audio etc)
or directly sent to the LPASS hardware (currently used by DB410c).
Bypassing QDSP6 audio is only possible with special firmware
(on DB410c) or when the modem DSP is completely disabled.
Add the typical nodes for QDSP6 audio to msm8916.dtsi and msm8939.dtsi.
The apr node is disabled by default to avoid changing behavior for
devices like DB410c that use the bypassed audio path.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 49 +++++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/qcom/msm8939.dtsi | 49 +++++++++++++++++++++++++++++++++++
2 files changed, 98 insertions(+)
Comments
On Tue, Sep 26, 2023 at 08:46:36PM +0200, Konrad Dybcio wrote:
> On 26.09.2023 18:51, Stephan Gerhold wrote:
> > MSM8916 and MSM8939 do not have a dedicated ADSP. Instead, the audio
> > services via APR are also implemented by the modem DSP. Audio can be
> > either routed via the modem DSP (necessary for voice call audio etc)
> > or directly sent to the LPASS hardware (currently used by DB410c).
> > Bypassing QDSP6 audio is only possible with special firmware
> > (on DB410c) or when the modem DSP is completely disabled.
> >
> > Add the typical nodes for QDSP6 audio to msm8916.dtsi and msm8939.dtsi.
> > The apr node is disabled by default to avoid changing behavior for
> > devices like DB410c that use the bypassed audio path.
> >
> > Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
> > ---
> I'm generally grumpy with regards to multi-soc changes that
> have no need to be multi-soc..
>
Well it's 100% the same diff so reviewing it separately doesn't really
make sense IMHO. When I do "msm8916/39" patches these are generally the
changes where strictly speaking there is no need to duplicate at all.
It could go into a common include between both. We just haven't found
a good solution/agreement yet how sharing SoC components could work.
Thanks,
Stephan
On 26.09.2023 20:54, Stephan Gerhold wrote:
> On Tue, Sep 26, 2023 at 08:46:36PM +0200, Konrad Dybcio wrote:
>> On 26.09.2023 18:51, Stephan Gerhold wrote:
>>> MSM8916 and MSM8939 do not have a dedicated ADSP. Instead, the audio
>>> services via APR are also implemented by the modem DSP. Audio can be
>>> either routed via the modem DSP (necessary for voice call audio etc)
>>> or directly sent to the LPASS hardware (currently used by DB410c).
>>> Bypassing QDSP6 audio is only possible with special firmware
>>> (on DB410c) or when the modem DSP is completely disabled.
>>>
>>> Add the typical nodes for QDSP6 audio to msm8916.dtsi and msm8939.dtsi.
>>> The apr node is disabled by default to avoid changing behavior for
>>> devices like DB410c that use the bypassed audio path.
>>>
>>> Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
>>> ---
>> I'm generally grumpy with regards to multi-soc changes that
>> have no need to be multi-soc..
>>
>
> Well it's 100% the same diff so reviewing it separately doesn't really
> make sense IMHO. When I do "msm8916/39" patches these are generally the
> changes where strictly speaking there is no need to duplicate at all.
> It could go into a common include between both. We just haven't found
> a good solution/agreement yet how sharing SoC components could work.
My bottom line is that, somebody trying to track down an issue on
one may need to unnecessarily resolve 2 merge conflicts when reverting :/
Konrad
On Tue, Sep 26, 2023 at 09:05:24PM +0200, Konrad Dybcio wrote:
> On 26.09.2023 20:54, Stephan Gerhold wrote:
> > On Tue, Sep 26, 2023 at 08:46:36PM +0200, Konrad Dybcio wrote:
> >> On 26.09.2023 18:51, Stephan Gerhold wrote:
> >>> MSM8916 and MSM8939 do not have a dedicated ADSP. Instead, the audio
> >>> services via APR are also implemented by the modem DSP. Audio can be
> >>> either routed via the modem DSP (necessary for voice call audio etc)
> >>> or directly sent to the LPASS hardware (currently used by DB410c).
> >>> Bypassing QDSP6 audio is only possible with special firmware
> >>> (on DB410c) or when the modem DSP is completely disabled.
> >>>
> >>> Add the typical nodes for QDSP6 audio to msm8916.dtsi and msm8939.dtsi.
> >>> The apr node is disabled by default to avoid changing behavior for
> >>> devices like DB410c that use the bypassed audio path.
> >>>
> >>> Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
> >>> ---
> >> I'm generally grumpy with regards to multi-soc changes that
> >> have no need to be multi-soc..
> >>
> >
> > Well it's 100% the same diff so reviewing it separately doesn't really
> > make sense IMHO. When I do "msm8916/39" patches these are generally the
> > changes where strictly speaking there is no need to duplicate at all.
> > It could go into a common include between both. We just haven't found
> > a good solution/agreement yet how sharing SoC components could work.
> My bottom line is that, somebody trying to track down an issue on
> one may need to unnecessarily resolve 2 merge conflicts when reverting :/
>
I mean you could easily discard the changes in the other .dtsi. Probably
a single shell command if one knows enough "Git-fu".
Stephan
@@ -10,6 +10,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/qcom-rpmpd.h>
#include <dt-bindings/reset/qcom,gcc-msm8916.h>
+#include <dt-bindings/soc/qcom,apr.h>
#include <dt-bindings/thermal/thermal.h>
/ {
@@ -1989,6 +1990,54 @@ smd-edge {
label = "hexagon";
+ apr: apr {
+ compatible = "qcom,apr-v2";
+ qcom,smd-channels = "apr_audio_svc";
+ qcom,domain = <APR_DOMAIN_ADSP>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ q6core: service@3 {
+ compatible = "qcom,q6core";
+ reg = <APR_SVC_ADSP_CORE>;
+ };
+
+ q6afe: service@4 {
+ compatible = "qcom,q6afe";
+ reg = <APR_SVC_AFE>;
+
+ q6afedai: dais {
+ compatible = "qcom,q6afe-dais";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #sound-dai-cells = <1>;
+ };
+ };
+
+ q6asm: service@7 {
+ compatible = "qcom,q6asm";
+ reg = <APR_SVC_ASM>;
+
+ q6asmdai: dais {
+ compatible = "qcom,q6asm-dais";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #sound-dai-cells = <1>;
+ };
+ };
+
+ q6adm: service@8 {
+ compatible = "qcom,q6adm";
+ reg = <APR_SVC_ADM>;
+
+ q6routing: routing {
+ compatible = "qcom,q6adm-routing";
+ #sound-dai-cells = <0>;
+ };
+ };
+ };
+
fastrpc {
compatible = "qcom,fastrpc";
qcom,smd-channels = "fastrpcsmd-apps-dsp";
@@ -10,6 +10,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/qcom-rpmpd.h>
#include <dt-bindings/reset/qcom,gcc-msm8939.h>
+#include <dt-bindings/soc/qcom,apr.h>
#include <dt-bindings/thermal/thermal.h>
/ {
@@ -1615,6 +1616,54 @@ smd-edge {
qcom,remote-pid = <1>;
label = "hexagon";
+
+ apr: apr {
+ compatible = "qcom,apr-v2";
+ qcom,smd-channels = "apr_audio_svc";
+ qcom,domain = <APR_DOMAIN_ADSP>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ q6core: service@3 {
+ compatible = "qcom,q6core";
+ reg = <APR_SVC_ADSP_CORE>;
+ };
+
+ q6afe: service@4 {
+ compatible = "qcom,q6afe";
+ reg = <APR_SVC_AFE>;
+
+ q6afedai: dais {
+ compatible = "qcom,q6afe-dais";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #sound-dai-cells = <1>;
+ };
+ };
+
+ q6asm: service@7 {
+ compatible = "qcom,q6asm";
+ reg = <APR_SVC_ASM>;
+
+ q6asmdai: dais {
+ compatible = "qcom,q6asm-dais";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #sound-dai-cells = <1>;
+ };
+ };
+
+ q6adm: service@8 {
+ compatible = "qcom,q6adm";
+ reg = <APR_SVC_ADM>;
+
+ q6routing: routing {
+ compatible = "qcom,q6adm-routing";
+ #sound-dai-cells = <0>;
+ };
+ };
+ };
};
};