Hi, On 1/18/21 6:44 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Jan 18, 2021 at 03:49:58PM +0000, Peter Robinson wrote: >> On Mon, Jan 18, 2021 at 3:20 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote: >>> >>> https://fedoraproject.org/wiki/Changes/SofDefaultForIntelLpe >>> >>> >>> == Summary == >>> 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. >>> >>> == Owner == >>> * Name: [[User:jwrdegoede| Hans de Goede]] >>> * Email: hdegoede@xxxxxxxxxx >>> >>> >>> == Detailed Description == >>> >>> 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. >>> >>> >>> == 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". >>> >>> == Scope == >>> * 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". >>> >>> == Upgrade/compatibility impact == >>> The switch will automatically be made when booting a Fedora 34 kernel. >>> >>> == How To Test == >>> 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 below 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 >> >> Does this cover newer generations like Apollo Lake? The LPE audio block really stems from Intel's efforts to get into tablets, so 1-2W Scenario Design Power, Apollo Lake does not scale that low and has normal HDA audio. There are some special Haswell SKus which have a LPE like block, but those use yet another firmware/driver combo. So this is really only about Bay- and Cherry-Trail based devices. > Also: is there some easy command (something bar grep something) that > users could execute to test if they have the affected hardware? > Please put it in the Change page. You can check if you have a device which will be affected by this change by doing: 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. I have also added this to the Testing section of the Changes page. Regards, Hans > >>> Each of these will be tested according to 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. >808622A8:>> >>> Users who want to test this and who have the affected hardware can >>> also use this test-plan to test. >>> >>> == User Experience == >>> 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. >>> >>> == Dependencies == >>> N/A (not a System Wide Change) >>> >>> == Contingency Plan == >>> 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 >>> >>> == Documentation == >>> N/A (not a System Wide Change) >>> >>> == Release Notes == >>> FIXME: TODO > > Zbyszek > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
