On 2020-11-20 7:06 PM, Mark Brown wrote: > On Fri, Nov 20, 2020 at 05:10:30PM +0000, Rojewski, Cezary wrote: >> On 2020-11-20 5:48 PM, Mark Brown wrote: > >>> People care about any code that's in the kernel, especially people doing >>> anything treewide. The fewer configurations people need to build to get >>> code coverage the better. > >> Sure, but in this particular case there really shouldn't be "another >> option". If catpt is the sole option, why add intel-dsp-config >> dependency? The alternative shouldn't even exist in the kernel and be >> instead removed just like /haswell/ and /baytrail/ were. > > If all the alternatives actually get removed then there'd be no need for > it, while they're there it is reasonable to have it - it does make it > easier for people like distros to try converting, it means they can > deploy the recommended setup without needing to ship new binaries to > people who run into trouble. Besides TBH while there's several DSP > implementations in the tree having the code there makes it obvious that > this case works the same way as all the others to anyone looking at the > code. I can understand that in atom's case. That's why I'm fine with the section mechanism being applied there. At the beginning I'd thought SOF is already prepared to take over /atom/. As that's not the case, to ease the transition, dynamic switch could prove useful. There are no circumstances under which Intel recommends distros to try to convert out of catpt though. Don't believe aligning all the drivers to some general idea just for the sake of aligning is a good move. That's why drivers have their own specifics in the first place - their complexity and performance could have been negatively impacted otherwise. Czarek
