[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