Note this was tested on rpl-001 but the diff between RPL-001 and main appears to be unrelated to the code flow for this issue.

Note this regression is likely caused by the fact that #4466 (also on adl-004-drop-stable) managed to completely skip landing on main.

We can pick that up instead if preferred, but I figured an exit delay is more deterministic since we know the registers signal availability before the bank is actually ready.

Drive by zephyrization comment: AFAICT the equivalent driver[1] in a zephyr build does seem to have (what I think is!) the equivalent delay: https://github.com/zephyrproject-rtos/zephyr/blob/main/soc/xtensa/intel_adsp/cavs/sram.c#L44

Might be a good idea to audit to be sure. Are there known rules we could enforce more simply? Maybe something like "Must wait 3us after a write to the LDOCTL register"? Might be easier than sprinkling delay calls everywhere, and PM isn't likely to be a microsecond-scale performance path.

[1] For the rather different Zephyr PM framework, but the low level code looks more or less directly translated.

Drive by zephyrization comment: AFAICT the equivalent driver[1] in a zephyr build does seem to have (what I think is!) the equivalent delay: https://github.com/zephyrproject-rtos/zephyr/blob/main/soc/xtensa/intel_adsp/cavs/sram.c#L44

Might be a good idea to audit to be sure. Are there known rules we could enforce more simply? Maybe something like "Must wait 3us after a write to the LDOCTL register"? Might be easier than sprinkling delay calls everywhere, and PM isn't likely to be a microsecond-scale performance path.

[1] For the rather different Zephyr PM framework, but the low level code looks more or less directly translated.

Actually I think its missing unfortunately. This new delay is the last step so it would be after this line

Note this regression is likely caused by the fact that #4466 (also on adl-004-drop-stable) managed to completely skip landing on main.

It looks like the PR was left hanging and eventually closed when @slawblauciak left the SOF team.

We can pick that up instead if preferred, but I figured an exit delay is more deterministic since we know the registers signal availability before the bank is actually ready.

@pblaszko did some research and it looks like this behavior might be related to a known issue. If we confirm that then the recommended fix will be to read EBB status twice and if different values is received then read again.

We can pick that up instead if preferred, but I figured an exit delay is more deterministic since we know the registers signal availability before the bank is actually ready.

@pblaszko did some research and it looks like this behavior might be related to a known issue. If we confirm that then the recommended fix will be to read EBB status twice and if different values is received then read again.

Please make this a priority, we currently have devices in the hands of dogfooders that are unstable and are running out of time on our release calendar

I have already created PR with recommended change
#7065