| Message ID | 20250425-fp4-usb-audio-offload-v1-6-f90f571636e4@fairphone.com |
|---|---|
| State | New |
| Headers | show |
| Series | Enable USB audio offloading on Fairphone 4 smartphone | expand |
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. ah, ok! 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
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 {
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(+)