Enable USB audio offloading which allows to play audio via a USB-C
headset with lower power consumption and enabling some other features.
This can be used like the following:
$ amixer -c0 cset name='USB_RX Audio Mixer MultiMedia1' On
$ aplay --device=plughw:0,0 test.wav
Compared to regular playback to the USB sound card no interrupts should
appear on the xhci-hcd interrupts during playback, instead the ADSP will
be handling the playback.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
arch/arm64/boot/dts/qcom/sm6350.dtsi | 3 ++
arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts | 37 +++++++++++++++++++++++
2 files changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi b/arch/arm64/boot/dts/qcom/sm6350.dtsi
index 9a1b9f02282a0cf2e39bf2ade21989dbf4362bc1..ade69296cbc99eab3ee6dc020f2064d102a3b115 100644
--- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
@@ -2956,6 +2956,9 @@ wifi: wifi@18800000 {
};
};
+ sound: sound {
+ };
+
thermal-zones {
aoss0-thermal {
thermal-sensors = <&tsens0 0>;
diff --git a/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts b/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
index 71e87ab929551b339216a5fa583833ed8661a606..0f8e0a988db0d32384f39537731c77344ec50cf2 100644
--- a/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
+++ b/arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts
@@ -19,6 +19,7 @@
#include <dt-bindings/leds/common.h>
#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+#include <dt-bindings/sound/qcom,q6asm.h>
#include <dt-bindings/usb/pd.h>
#include "sm7225.dtsi"
#include "pm6150l.dtsi"
@@ -955,6 +956,12 @@ channel@644 {
};
};
+&q6asmdai {
+ dai@0 {
+ reg = <MSM_FRONTEND_DAI_MULTIMEDIA1>;
+ };
+};
+
&qup_uart1_cts {
/*
* Configure a bias-bus-hold on CTS to lower power
@@ -1023,6 +1030,35 @@ &sdhc_2 {
status = "okay";
};
+&sound {
+ compatible = "fairphone,fp4-sndcard";
+ model = "Fairphone 4";
+
+ mm1-dai-link {
+ link-name = "MultiMedia1";
+
+ cpu {
+ sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA1>;
+ };
+ };
+
+ usb-dai-link {
+ link-name = "USB Playback";
+
+ cpu {
+ sound-dai = <&q6afedai USB_RX>;
+ };
+
+ codec {
+ sound-dai = <&q6usbdai USB_RX>;
+ };
+
+ platform {
+ sound-dai = <&q6routing>;
+ };
+ };
+};
+
&tlmm {
gpio-reserved-ranges = <13 4>, <56 2>;
@@ -1178,6 +1214,7 @@ &usb_1 {
&usb_1_dwc3 {
maximum-speed = "super-speed";
dr_mode = "otg";
+ num-hc-interrupters = /bits/ 16 <3>;
};
&usb_1_dwc3_hs_out {
--
2.49.0On 4/25/25 12:44 PM, Luca Weiss wrote:
> Enable USB audio offloading which allows to play audio via a USB-C
> headset with lower power consumption and enabling some other features.
>
> This can be used like the following:
>
> $ amixer -c0 cset name='USB_RX Audio Mixer MultiMedia1' On
> $ aplay --device=plughw:0,0 test.wav
>
> Compared to regular playback to the USB sound card no interrupts should
> appear on the xhci-hcd interrupts during playback, instead the ADSP will
> be handling the playback.
"should" isn't very optimistic - I assume this works for you? >
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
[...]
> +&sound {
> + compatible = "fairphone,fp4-sndcard";
> + model = "Fairphone 4";
> +
> + mm1-dai-link {
> + link-name = "MultiMedia1";
> +
> + cpu {
> + sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA1>;
> + };
> + };
> +
> + usb-dai-link {
> + link-name = "USB Playback";
> +
> + cpu {
> + sound-dai = <&q6afedai USB_RX>;
> + };
> +
> + codec {
> + sound-dai = <&q6usbdai USB_RX>;
> + };
'co'dec < 'cp'u> +
> + platform {
> + sound-dai = <&q6routing>;
> + };
> + };
> +};
> +
> &tlmm {
> gpio-reserved-ranges = <13 4>, <56 2>;
>
> @@ -1178,6 +1214,7 @@ &usb_1 {
> &usb_1_dwc3 {
> maximum-speed = "super-speed";
> dr_mode = "otg";
> + num-hc-interrupters = /bits/ 16 <3>;
Where does this number come from?
Konrad
On Fri Apr 25, 2025 at 11:06 PM CEST, Konrad Dybcio wrote:
> On 4/25/25 12:44 PM, Luca Weiss wrote:
>> Enable USB audio offloading which allows to play audio via a USB-C
>> headset with lower power consumption and enabling some other features.
>>
>> This can be used like the following:
>>
>> $ amixer -c0 cset name='USB_RX Audio Mixer MultiMedia1' On
>> $ aplay --device=plughw:0,0 test.wav
>>
>> Compared to regular playback to the USB sound card no interrupts should
>> appear on the xhci-hcd interrupts during playback, instead the ADSP will
>> be handling the playback.
>
> "should" isn't very optimistic - I assume this works for you? >
Yes it does!
With 'should' I meant to describe the expected behavior from using this
since most people are probably not familiar with how this works.
>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>> ---
> [...]
>
>> +&sound {
>> + compatible = "fairphone,fp4-sndcard";
>> + model = "Fairphone 4";
>> +
>> + mm1-dai-link {
>> + link-name = "MultiMedia1";
>> +
>> + cpu {
>> + sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA1>;
>> + };
>> + };
>> +
>> + usb-dai-link {
>> + link-name = "USB Playback";
>> +
>> + cpu {
>> + sound-dai = <&q6afedai USB_RX>;
>> + };
>> +
>> + codec {
>> + sound-dai = <&q6usbdai USB_RX>;
>> + };
>
> 'co'dec < 'cp'u> +
Aah, I thought I checked for that already. Will fix.
>> + platform {
>> + sound-dai = <&q6routing>;
>> + };
>> + };
>> +};
>> +
>> &tlmm {
>> gpio-reserved-ranges = <13 4>, <56 2>;
>>
>> @@ -1178,6 +1214,7 @@ &usb_1 {
>> &usb_1_dwc3 {
>> maximum-speed = "super-speed";
>> dr_mode = "otg";
>> + num-hc-interrupters = /bits/ 16 <3>;
> Where does this number come from?
I'm honestly not 100% sure. As far as I understand it, with
'qcom,usb-audio-intr-idx = /bits/ 16 <2>;' in the qcom,q6usb node (which
I've checked against downstream) we declare which "XHCI interrupter
number to use". Without the num-hc-interrupters property we get an error
that not enough interrupters are available (I assume only 1 is then), so
this value practically needs to be higher than the <2> from earlier.
Why it's this value and not a higher value e.g. 4 I'm not really sure.
Downstream code looks somewhat different and "max_interrupters" in
drivers/usb/ doesn't come from a dt property. I'd need to check more in
details what this code does - or maybe Wesley can help.
Regards
Luca
>
> Konrad
On 4/28/25 9:41 AM, Luca Weiss wrote:
> On Fri Apr 25, 2025 at 11:06 PM CEST, Konrad Dybcio wrote:
>> On 4/25/25 12:44 PM, Luca Weiss wrote:
>>> Enable USB audio offloading which allows to play audio via a USB-C
>>> headset with lower power consumption and enabling some other features.
>>>
>>> This can be used like the following:
>>>
>>> $ amixer -c0 cset name='USB_RX Audio Mixer MultiMedia1' On
>>> $ aplay --device=plughw:0,0 test.wav
>>>
>>> Compared to regular playback to the USB sound card no interrupts should
>>> appear on the xhci-hcd interrupts during playback, instead the ADSP will
>>> be handling the playback.
>>
>> "should" isn't very optimistic - I assume this works for you? >
>
> Yes it does!
>
> With 'should' I meant to describe the expected behavior from using this
> since most people are probably not familiar with how this works.
>
>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>> ---
[...]
>>> &usb_1_dwc3 {
>>> maximum-speed = "super-speed";
>>> dr_mode = "otg";
>>> + num-hc-interrupters = /bits/ 16 <3>;
>> Where does this number come from?
>
> I'm honestly not 100% sure. As far as I understand it, with
> 'qcom,usb-audio-intr-idx = /bits/ 16 <2>;' in the qcom,q6usb node (which
> I've checked against downstream) we declare which "XHCI interrupter
> number to use". Without the num-hc-interrupters property we get an error
> that not enough interrupters are available (I assume only 1 is then), so
> this value practically needs to be higher than the <2> from earlier.
>
> Why it's this value and not a higher value e.g. 4 I'm not really sure.
> Downstream code looks somewhat different and "max_interrupters" in
> drivers/usb/ doesn't come from a dt property. I'd need to check more in
> details what this code does - or maybe Wesley can help.
I got word that it's simply hw specific - please move it over to the
soc dt with the value of 3
Konrad
On Mon Apr 28, 2025 at 11:43 PM CEST, Konrad Dybcio wrote:
> On 4/28/25 9:41 AM, Luca Weiss wrote:
>> On Fri Apr 25, 2025 at 11:06 PM CEST, Konrad Dybcio wrote:
>>> On 4/25/25 12:44 PM, Luca Weiss wrote:
>>>> Enable USB audio offloading which allows to play audio via a USB-C
>>>> headset with lower power consumption and enabling some other features.
>>>>
>>>> This can be used like the following:
>>>>
>>>> $ amixer -c0 cset name='USB_RX Audio Mixer MultiMedia1' On
>>>> $ aplay --device=plughw:0,0 test.wav
>>>>
>>>> Compared to regular playback to the USB sound card no interrupts should
>>>> appear on the xhci-hcd interrupts during playback, instead the ADSP will
>>>> be handling the playback.
>>>
>>> "should" isn't very optimistic - I assume this works for you? >
>>
>> Yes it does!
>>
>> With 'should' I meant to describe the expected behavior from using this
>> since most people are probably not familiar with how this works.
>>
>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>>> ---
>
> [...]
>
>>>> &usb_1_dwc3 {
>>>> maximum-speed = "super-speed";
>>>> dr_mode = "otg";
>>>> + num-hc-interrupters = /bits/ 16 <3>;
>>> Where does this number come from?
>>
>> I'm honestly not 100% sure. As far as I understand it, with
>> 'qcom,usb-audio-intr-idx = /bits/ 16 <2>;' in the qcom,q6usb node (which
>> I've checked against downstream) we declare which "XHCI interrupter
>> number to use". Without the num-hc-interrupters property we get an error
>> that not enough interrupters are available (I assume only 1 is then), so
>> this value practically needs to be higher than the <2> from earlier.
>>
>> Why it's this value and not a higher value e.g. 4 I'm not really sure.
>> Downstream code looks somewhat different and "max_interrupters" in
>> drivers/usb/ doesn't come from a dt property. I'd need to check more in
>> details what this code does - or maybe Wesley can help.
>
> I got word that it's simply hw specific - please move it over to the
> soc dt with the value of 3
Will do, thanks for checking!
Would you have a reference how to get the correct value for it based on
downstream or the running kernel on the hw?
Regards
Luca
>
> Konrad
On 4/29/25 10:55 AM, Luca Weiss wrote:
> On Mon Apr 28, 2025 at 11:43 PM CEST, Konrad Dybcio wrote:
>> On 4/28/25 9:41 AM, Luca Weiss wrote:
>>> On Fri Apr 25, 2025 at 11:06 PM CEST, Konrad Dybcio wrote:
>>>> On 4/25/25 12:44 PM, Luca Weiss wrote:
>>>>> Enable USB audio offloading which allows to play audio via a USB-C
>>>>> headset with lower power consumption and enabling some other features.
>>>>>
>>>>> This can be used like the following:
>>>>>
>>>>> $ amixer -c0 cset name='USB_RX Audio Mixer MultiMedia1' On
>>>>> $ aplay --device=plughw:0,0 test.wav
>>>>>
>>>>> Compared to regular playback to the USB sound card no interrupts should
>>>>> appear on the xhci-hcd interrupts during playback, instead the ADSP will
>>>>> be handling the playback.
>>>>
>>>> "should" isn't very optimistic - I assume this works for you? >
>>>
>>> Yes it does!
>>>
>>> With 'should' I meant to describe the expected behavior from using this
>>> since most people are probably not familiar with how this works.
>>>
>>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>>>> ---
>>
>> [...]
>>
>>>>> &usb_1_dwc3 {
>>>>> maximum-speed = "super-speed";
>>>>> dr_mode = "otg";
>>>>> + num-hc-interrupters = /bits/ 16 <3>;
>>>> Where does this number come from?
>>>
>>> I'm honestly not 100% sure. As far as I understand it, with
>>> 'qcom,usb-audio-intr-idx = /bits/ 16 <2>;' in the qcom,q6usb node (which
>>> I've checked against downstream) we declare which "XHCI interrupter
>>> number to use". Without the num-hc-interrupters property we get an error
>>> that not enough interrupters are available (I assume only 1 is then), so
>>> this value practically needs to be higher than the <2> from earlier.
>>>
>>> Why it's this value and not a higher value e.g. 4 I'm not really sure.
>>> Downstream code looks somewhat different and "max_interrupters" in
>>> drivers/usb/ doesn't come from a dt property. I'd need to check more in
>>> details what this code does - or maybe Wesley can help.
>>
>> I got word that it's simply hw specific - please move it over to the
>> soc dt with the value of 3
>
> Will do, thanks for checking!
>
> Would you have a reference how to get the correct value for it based on
> downstream or the running kernel on the hw?
3 should be reasonable for most platforms, but I don't think there's
a clear value defined downstream
Konrad
On 4/28/25 9:41 AM, Luca Weiss wrote: > On Fri Apr 25, 2025 at 11:06 PM CEST, Konrad Dybcio wrote: >> On 4/25/25 12:44 PM, Luca Weiss wrote: >>> Enable USB audio offloading which allows to play audio via a USB-C >>> headset with lower power consumption and enabling some other features. >>> >>> This can be used like the following: >>> >>> $ amixer -c0 cset name='USB_RX Audio Mixer MultiMedia1' On >>> $ aplay --device=plughw:0,0 test.wav >>> >>> Compared to regular playback to the USB sound card no interrupts should >>> appear on the xhci-hcd interrupts during playback, instead the ADSP will >>> be handling the playback. >> >> "should" isn't very optimistic - I assume this works for you? > > > Yes it does! > > With 'should' I meant to describe the expected behavior from using this > since most people are probably not familiar with how this works. ah, ok! Konrad
On Fri, Apr 25, 2025 at 12:44:56PM +0200, Luca Weiss wrote: > Enable USB audio offloading which allows to play audio via a USB-C > headset with lower power consumption and enabling some other features. > > This can be used like the following: > > $ amixer -c0 cset name='USB_RX Audio Mixer MultiMedia1' On > $ aplay --device=plughw:0,0 test.wav > > Compared to regular playback to the USB sound card no interrupts should > appear on the xhci-hcd interrupts during playback, instead the ADSP will > be handling the playback. > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > --- > arch/arm64/boot/dts/qcom/sm6350.dtsi | 3 ++ > arch/arm64/boot/dts/qcom/sm7225-fairphone-fp4.dts | 37 +++++++++++++++++++++++ > 2 files changed, 40 insertions(+) > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> -- With best wishes Dmitry
© 2016 - 2026 Red Hat, Inc.