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