On 2020-10-12 1:53 PM, Hans de Goede wrote:
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.
Thanks for your encouraging words, Takashi and Mark.
My faith is with accuracy of our CI, not the fingers crossing though : )
Happy to receive any feedback. Andy pushed me to dig several low-level issues e.g. DMA engine configuration and PCI description which were hidden since 2014 behind other errors, what I'm thankful for. v1 addressed the latter, further series the former.
Indeed, given the resources that have been put into assembling active HSW/BDW CI - which happily joined the SKL-TGL family in racks -, commitment to support the catpt solution is assured.
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.
Hans,
I understand that actual DSP-hw is quite old (2011 dev, 2014 release) so besides what is already available, I won't be adding many things. Those are: firmware logs (debug feature), module support (WAVES). Nothing more, nothing less. Immediately afterward catpt enters hard-maintenance stage where only fixes are allowed.
Stress tests are still ongoing as my goal is to remove basically any-hsw specific code (~50 lines) as hsw is here only from maintenance point of view as explained in catpt's series cover-letter.
The more eyes looking at the code, the merrier : ) Thanks for your input.
Regards, Czarek