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

["Rojewski, Cezary" <cezary.rojewski@intel.com>]

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