On 1/27/2020 4:30 PM, Pierre-Louis Bossart wrote:
As it was agreed with you Pierre the Skylake driver will be kept under maintenance and the proposed changes are about to keep hda-dsp configuration functional for anyone who would like to use it. Linus laptop issue is actually one of the good reasons why we would like to keep hda-dsp configuration functional
We have to agree on what 'maintained' means then.
I don't mind leaving the Skylake driver in the kernel and letting people who have access to Intel support use it. Cezary is listed as the maintainer as I suggested it, and this patch provides an necessary fix.
But does this mean this Hdaudio option is usable by distributions and Linux users who don't have access to Intel support?
I will assert that it's not, based on my own experience only 2 weeks ago. I tried to make audio work on a KBL NUC and had to comment stuff out due to an obsolete topology. see https://github.com/thesofproject/linux/pull/1667#issuecomment-572312157
That is exactly the reason why we would like to update the Skylake driver upstream code and it configuration files so that it will be usable by the community and not only keep it functional internally. As it was clarified by Cezary, we would like to make a minimum number of changes that are required.
Is there Pierre any non-technical reason why we should not fix the Skylake driver code on the upstream?
My comment was only regarding support of HDaudio codecs w/ the Skylake driver. I personally gave up trying to support this option after 1.5 yrs of recurring issues. It will take a lot more than minimal patches I am afraid if you want this option to work across all known commercial devices, you will have to address race conditions such as the probe failing when DRM is built as a module, or on specific SKL/APL devices.
If you are signing-up to do this work I have no objections, and if in addition you add support for DMICs you'd solve existing issues with KBL/AmberLake for which users are left without a solution.
Just be aware of what you are signing up for, it's not a 'minimal' effort.
The proposed patch-set is to restore the Skylake driver functionality for Skylake base targets. I called it ‘minimal’ because last time when we have tried to upstream the wide range of patch-sets with code refactors it was rejected because of ‘maintenance’ mark on the driver.
As we discussed on the call we will take a closer look on the HW boards that continue to reproduce the race condition issue. However the fix on that specific problem will be addressed as a separate patch-set. Additionally we will work on providing reference topology configuration files that support DMICs.
I can’t commit any timeframe but as long as we will be maintainers and the changes will be welcome on the upstream we will work on improving the functionality of the Skylake driver.