Revert all patches affecting CML

[plbossart]

It makes no sense to continue if we have two problems impacting the same platform.

[plbossart]

@ranj063 @lgirdwood See CI results, all green without having to go through hoops...

[lyakh]

@plbossart could you have a look at my comments in #4560 ?

[plbossart]

@plbossart could you have a look at my comments in #4560 ?

I did look and I see nothing specific for Helios speakers. There's a straightforward path PCM-BUF-PGA-BUF-SSP.
That's why I recommend a revert, I really don't see how we might solve this in the short-term.

[lyakh]

@plbossart could you have a look at my comments in #4560 ?

I did look and I see nothing specific for Helios speakers. There's a straightforward path PCM-BUF-PGA-BUF-SSP.
That's why I recommend a revert, I really don't see how we might solve this in the short-term.

@plbossart I don't necessarily object reverting. I agree that fixing this properly will take some time. But no, it isn't about the path, it isn't the whole pipeline that takes that long. It's just the time that dai_trigger() takes on Helios. And I compared that time to UP2 (it's also I2S, right?) and it's ~100us there - a factor of 100 faster. I hoped that someone could tell me what exactly takes that much time there (polling for some initialisation or whatever), but if noone knows that off the top of their head, we'll just have to profile that.

[plbossart]

@lyakh we can use the UpExtreme in nocodec mode to see if the problem is really on the SOC side. The SSP usage looks the same as everywhere else.

I checked with @ranj063 and she has no objection to the revert, let's merge this, run a bunch of stress test this week-end and see next week how to handle these two trace and xrun issues.