ICCMAX implementation for FW boot in ICL

[fredoh9]

While discussing #2290, the flow for ICL is different from TGL.

1. Need to check extended manifest if the FW is configured for LPRO or HPRO, Support extended manifest config data for clock config #2297 is under review. Found minor interface change is required.

2. If FW is configured for HPRO, C3 should keep it ON.

[plbossart]

@fredoh9 I am completely confused on the transition to use the extended manifest, we discussed in the past that this would happen in a distant future when all distros rely on a firmware with the extended manifest. We still have platforms using firmware 1.3, so short term we can't really depend on the extended manifest, can we?
Or we would need to REQUIRE the firmware with the extended manifest on ICL/TGL.

[ranj063]

@fredoh9 I am completely confused on the transition to use the extended manifest, we discussed in the past that this would happen in a distant future when all distros rely on a firmware with the extended manifest. We still have platforms using firmware 1.3, so short term we can't really depend on the extended manifest, can we?
Or we would need to REQUIRE the firmware with the extended manifest on ICL/TGL.

@plbossart we do need the ext_manifest for ICL to enable ICCMAX during FW boot. Should we tie it with a minimum ABI requirement?

[plbossart]

@fredoh9 I am completely confused on the transition to use the extended manifest, we discussed in the past that this would happen in a distant future when all distros rely on a firmware with the extended manifest. We still have platforms using firmware 1.3, so short term we can't really depend on the extended manifest, can we?
Or we would need to REQUIRE the firmware with the extended manifest on ICL/TGL.

@plbossart we do need the ext_manifest for ICL to enable ICCMAX during FW boot. Should we tie it with a minimum ABI requirement?

Oh, because you need to know the information before getting the information from firmware in the SRAM window?
If yes, we are indeed looking at a minimum ABI for ICL and TGL, and we need a 1.6 release that implements this. @lgirdwood FYI

[kv2019i]

@plbossart The end result of last ext-manifest deployment discussion was to do it on a platform basis. I.e. starting with platform N (which is not supported by any old kernels), all SOF FW released for platform N will have ext-manifest enabled. Nothing will break as any kernel that could be used on platform N systems, will also support extended manifest in firmware binary.

However, ICL is problematic as it is supported in multiple major kernel revisions which support ICL but do not support SOF ext-manifest descriptions.

But given the concrete need to have this, yes, we should start at next SOF release (1.6. ) to build the ICL binary with ext-manifest. For Linux distros, this in practise means they cannot update SOF FW unless they update the kernel to 5.8 (or newer, or backport the ext-manifest series).

[plbossart]

@kv2019i given all the firmware panics on HDaudio platforms, everyone will have to jump to firmware 1.6, including distros already on 5.4/5.5. 5.8 isn't going to be used for some time, it's barely out of the oven and the stable branch isn't updated yet.

We have to find a way to solve this. Maybe e.g. work with the stable branch folks so that this series is added - we could say it's a hardware-related requirement that forces folks to take the ext_manifest patches.

[fredoh9]

Duplicated, #2434 has more discussion. We can close this.

[fredoh9]

#2548 merged