[PATCH v2 00/13] ASoC: Intel: Remove obsolete solutions and components

Hans de Goede hdegoede at redhat.com
Mon Oct 12 13:53:54 CEST 2020


Hi,

On 10/12/20 1:36 PM, Mark Brown wrote:
> On Mon, Oct 12, 2020 at 11:09:04AM +0200, Takashi Iwai wrote:
>> Hans de Goede wrote:
> 
>>> replacement and dropping the old code ?  I'm not sure if that is such
>>> a great idea, what is the fallback plan if testing does find significant
>>> issues with the new catpt code ?
> 
>> I find the action a bit too rushing, too.  OTOH, the old code wasn't
>> well maintained, honestly speaking.  So, from another perspective,
>> switching to a new code can be seen as a better chance to fix any
>> bugs.
> 
> That was my take as well - the old code seemed to be very fragile for
> structural reasons which are hopefully addressed here and Intel seem
> willing to actively work on supporting this version.  I have to confess
> I had assumed Hans had seen all this stuff going past, the new driver
> got quite a few rounds of review.

My ASoC interest is 99% Intel Bay Trail / Cherry Trail support, so
I'm not on alsa-devel list since that gets a lot more then just that.

IOW I'm relying on being Cc-ed, which might not be the best tactic
I guess.

Anyways, the Bay Trail / Cherry Trail changes here are 100% ok with me.
I pointed out the Haswell / Broadwell bits since I was taking a look
anyways, I don't really have a strong opinion on those, I've never seen
a  Haswell / Broadwell machine actually using the SST/ASoC code,
all those which I have seen use the HDA driver.

And from the sounds of it for those rare Haswell / Broadwell machines
which do use the SST code the new catpt code should be an improvement.
So from my pov everything is good.

Regards,

Hans



More information about the Alsa-devel mailing list