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
