- 1 SOF as default audio driver for Intel LPE hardware
SOF as default audio driver for Intel LPE hardware
Intel LPE audio hardware has 2 drivers in the mainline kernel the SST driver and the SOF driver, switch the default driver from SST to SOF.
- Name: Hans de Goede
- Email: firstname.lastname@example.org
- Targeted release: Fedora 34
- Last updated: 2021-02-02
- FESCo issue: #2565
- Tracker bug: #1924101
- Release notes tracker: #651
Intel x86 hardware based on the Bay Trail-T and Cherry Trails SoCs does not come with the standard Intel HDA audio hardware. Instead it has an audio block called the Low Power Engine or LPE. The LPE block needs to have firmware loaded into it to function. There are 2 firmwares available the old proprietary SST firmware and recently the open source SOF firmware has been released for the LPE engine.
There are also 2 kernel drivers for the LPE block, one for each firmware, so we have a SST driver and a SOF driver. The upstream Intel developers of these drivers, who are also part of the SOF team want to deprecate and eventually remove the old SST driver in favor of the SOF driver. Starting with the 5.11 kernel it is possible to build both drivers into a single kernel and select which one will actually bind to the LPE block using a kernel commandline parameter.
ATM the upstream default is the old SST driver, to avoid regressions. This Fedora change will entail carrying a downstream patch which flips the default to the SOF driver. This is being done in conclave with the upstream devs who would like to see more testing of the SOF driver. The upstream devs believe that the SOF driver is ready to replace the SST driver, but they would appreciate this being tested by Fedora first, before they flip the default for everyone.
No feedback received (yet).
Benefit to Fedora
By consciously making the switch now, with extensive testing and monitoring the situation we can safely make the switch without regressions hitting users of the Fedora stable releases. Whereas if we just wait for upstream to flip the default, then this may very well land in the middle of a stable release when we rebase the kernel.
This helps strengthen our relationship with the upstream developers and falls under the "First" part of the "Four Foundations".
This stops us from depending in the proprietary SST firmware-blobs, replacing them with the Open Source SOF firmware, matching the "Freedom" part of the "Four Foundations".
- Proposal owners: This will require a small downstream kernel patch to change the default driver when both are built (or an upstream patch to make the default configurable). That's it, no other changes are required.
- Other developers: N/A (not a System Wide Change)
- Release engineering: N/A (not a System Wide Change)
- Policies and guidelines: N/A (not a System Wide Change)
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives: This falls under the "First" part of the "Four Foundations".
The switch will automatically be made when booting a Fedora 34 kernel.
How To Test
First of all to test you will need to be running Fedora on hardware which is affected by this change. You can check for this by running the following 2 commands from a terminal:
- cat /sys/bus/acpi/devices/80860F28:*/status 2> /dev/null
- cat /sys/bus/acpi/devices/808622A8:*/status 2> /dev/null
If either of these commands outputs "15" then you have a device which will be switched to the SOF driver as part of this change.
After booting a Fedora 34 kernel you should now be using the SOF driver, you can check for this by running: "dmesg | grep sof" this should show several lines related to the SOF driver as output. If you want to help testing, please run the following test-plan:
- Test speakers.
- Test internal mic.
- Plugin headset, test headphones.
- Test headset-mic
- Stop all audio, suspend + resume, test speakers.
- suspend + resume while playing audio, audio should resume playing after resume.
I (Hans de Goede) have an extensive collection of affected hardware. The audio setup on these devices consists of the LPE block itself combined with an external audio-codec. There are a number of audio-codecs used / supported on these boards. The LPE block has 2 audio-links (called SSP0 and SSP2) and some of the codecs have 2 audio-links (called AIF1 and AIF2) not each board uses the same audio-link on each side.
I plan to run the above test-plan on devices with the following SoC / codec / link combinations:
- Bay Trail (CR) / RT5640 / SSP0<->AIF1
- Bay Trail (CR) / RT5640 / SSP0<->AIF2
- Bay Trail / RT5640 / SSP2<->AIF1
- Cherry Trail / RT5640 / SSP2<->AIF1
- Cherry Trail / RT5645 / SSP2
- Bay Trail (CR) / RT5651 / SSP0<->AIF1
- Cherry Trail / RT5651 / SSP2<->AIF1
- Bay Trail / RT5672 / SSP2
- Bay Trail (CR) / ESS8316 / SSP0
- Cherry Trail / ESS8316 / SSP2
- Cherry Trail / NAU8824 / SSP2
The SST driver has some suspend/resume problems around suspending with audio playing. The SOF driver resolves these. Other then that the user-experience should be unchanged.
N/A (not a System Wide Change)
We can simply drop the patch flipping the default to get back to the F33 state of things.
- Contingency mechanism: Revert the change
- Contingency deadline: Beta release
- Blocks release? No
N/A (not a System Wide Change)