On Tue, 24 Nov 2020 17:07:19 +0100, Rojewski, Cezary wrote:
On 2020-11-24 3:15 PM, Takashi Iwai wrote:
On Tue, 24 Nov 2020 15:01:19 +0100, Mark Brown wrote:
On Tue, Nov 24, 2020 at 11:56:36AM +0000, Rojewski, Cezary wrote:
What the patchset presents catpt vs SOF. /sof/ runs through SOF firmware so it cannot be account as old-implementation. It's a mix of not recommended fw + incorrect sw flow. As old /haswell/ is no more, there is no worrying about catpt deployment - it's your only option. As there is no userspace involved (lack of topology files), base firmware binary remains the same and amixer kcontrols behave 1:1 when compared to its predecessor, compatibility is left intact.
That's exactly why we should be explicit in driver selection. Pretty sure hsw/bdw case is still mistakenly addressed to as if it was atom-based platform.
It's not just the userspace interface that worries people, it's also any board specific quirks that might turn up. A good chunk of the work with x86 sound support is quirking around platform specifics - look at all the patches Hans sends for example. In an ideal world this would just be people worrying too much but the general history with getting generic code working well on a wide range of x86 hardware it's hard to blame anyone for being conservative about substantial changes in the software stack.
Mark, there is not a single word I don't agree with in your statement.
In regard to quirks - I was surprised how much detail Hans found out regarding atom platforms. That's a lot of good input. And that's probably one of the key reasons why atom is properly supported in linux.
My point has more "basic" nature.
I guess Cezary's point is that CATPT is the only driver for Haswell, hence the intel-dsp-config is useless for it.
This! and..
But I thought CATPT also covers Broadwell, and Broadwell can be supported by both CATPT and SOF? If so, the dynamic switching makes sense.
..more. Dynamic selection made sense if you're in transition period as it is the case for atoms. There is no transition period for hsw/bdw. BDW as "supported" by SOF would be a strong claim. There is no commitment and Intel does not recommend using it for hsw/bdw for any scenario. And as such, selection-subject does not apply here.
Believe removal of /sof/intel/bdw.c is in order?
This requires the agreement rather in Intel side at first.
The upstream will follow that decision, and eventually drop the dynamic selection for HSW/BDW, too.
Takashi