[PATCH 00/14] ASoC: Intel/SOF: extend run-time driver selection to ACPI devices

[Takashi Iwai]

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