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
