Skip to content

Conversation

@aborisovich
Copy link
Contributor

@aborisovich aborisovich commented Mar 24, 2023

This PR enables Zephyr IPC driver to enter/leave D3 power state using Zephyr Power Manager.

Commit 98f8cf214844700585fa277fc66245f212e20a27 adds pm notifiers that are triggered every time power state is changed.
Commit 8e4eeab67ebb8baf9e3ceb5db01f5301e889a34d adds IPC4 driver resume/suspend capability.
Commit a6e531b81d0b0ecea7881941e046dc8969bd3d1d enables IMR context save/restore.
Commit e17fd43847da9f61836406b85990ef4d97c8f3c1 provides error handling mechanism for IPC response to Host when errors during IPC power transition are encountered.

Dependecies:

Signed-off-by: Andrey Borisovich andrey.borisovich@intel.com

@aborisovich aborisovich force-pushed the ipc-device-wakes-from-d3 branch 3 times, most recently from 412cf15 to d12d27a Compare March 27, 2023 23:11
@gkbldcig
Copy link
Collaborator

Can one of the admins verify this patch?

@aborisovich aborisovich marked this pull request as ready for review March 28, 2023 08:04
@aborisovich aborisovich force-pushed the ipc-device-wakes-from-d3 branch 4 times, most recently from 1f23080 to 744c2b0 Compare March 28, 2023 10:58
Copy link
Collaborator

@kv2019i kv2019i left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few minor nits (see comments inline), but nothing major.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit funky to have Zephyr store state into address that is allocated elsewhere. But I guess as long as the L3 heap is implemented on SOF side, we have to do it like this.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not related to this patch, but realized this interface is not really well named, this should be used for all SOF platforms, not just Intel DSPs, so "intel_adsp_" prefix is not good here. But alas this is not added by this PR. FYI to @juimonen

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, so this needs to be generically named.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess these are no-ops on platforms where RAM context is not maintained in D3? I.e. it's ok to still set them.

@aborisovich aborisovich force-pushed the ipc-device-wakes-from-d3 branch from 744c2b0 to 3e6d01a Compare March 29, 2023 18:25
@aborisovich aborisovich changed the title MTL enters D3 power state using Zephyr Power Manager [DNM] MTL enters D3 power state using Zephyr Power Manager Mar 30, 2023
Copy link
Member

@lgirdwood lgirdwood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, I think we need to revisist some API naming to be more generic as a subsequent PR and synchronise the west ID after dependencues are merged..

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, so this needs to be generically named.

@aborisovich aborisovich force-pushed the ipc-device-wakes-from-d3 branch from 3e6d01a to 07e066c Compare April 5, 2023 11:55
@aborisovich aborisovich force-pushed the ipc-device-wakes-from-d3 branch from 07e066c to 6c98bb3 Compare April 6, 2023 09:23
@lgirdwood
Copy link
Member

@aborisovich do the host drivers need to do anything different to enable IMR context save ?

@aborisovich
Copy link
Contributor Author

@aborisovich do the host drivers need to do anything different to enable IMR context save ?

No, as far as I know they don't.
Please confirm @marcinszkudlinski .

@aborisovich aborisovich force-pushed the ipc-device-wakes-from-d3 branch 2 times, most recently from f945d10 to 76d0380 Compare June 27, 2023 09:25
@aborisovich
Copy link
Contributor Author

I do not know how to address this checkpatch issue: image When this is not split across the lines, checkpatch complains that I've exceeded the 100 characters in width... Moreover, I've seen similar usages of tr_err in code done in the similar way.

long strings in log prints are tolerated and preferred over split strings. The reasoning is that split strings are difficult to grep for after seeing them in a log. But would be good to at least take that string on the next line - splitting after &ipc_tr,

Resolved issue with the too long log by removing function name prefix. Turned out Zephyr logging provides this name prefix by default so it is not needed, thanks @tmleman .

@aborisovich
Copy link
Contributor Author

aborisovich commented Jun 27, 2023

I wonder what was author thinking when was creating this rule...

Enjoy the 2013 discussion: https://lore.kernel.org/lkml/1365563834.27174.12.camel@joe-AO722/#r

It had been proved over and over again on many technical and non-technical subjects, that Linux Kernel project leadership is not an entity listening to anyone's reasoning so, no thank you. I will restrain myself from providing references with links because it can be easily found in the internet.
The question is why SOF project follows Linux Kernel. I do not think this is a requirement but the choice we made. And now the project undergoes convergence with Windows and Chrome OS.

@aborisovich aborisovich requested a review from softwarecki June 27, 2023 09:47
Copy link
Collaborator

@kv2019i kv2019i left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some comments but nothing major, so I'll put my approval on here. Let's see how the tests look like.

zephyr/lib/cpu.c Outdated
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor: it's not so obvious this is coming from Zephyr adsp_memory.h . Might be more readable to just directly use "DT_REG_SIZE(DT_NODELABEL(sram1)" as this a Zephyr-only file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I would leave this matter to the author @marcinszkudlinski since it is his commit.
He is currently on vacation. Can we address this later? I will let him know.

@plbossart
Copy link
Member

I wonder what was author thinking when was creating this rule...

Enjoy the 2013 discussion: https://lore.kernel.org/lkml/1365563834.27174.12.camel@joe-AO722/#r

It had been proved over and over again on many technical and non-technical subjects, that Linux Kernel project leadership is not an entity listening to anyone's reasoning so, no thank you. I will restrain myself from providing references with links because it can be easily found in the internet. The question is why SOF project follows Linux Kernel. I do not think this is a requirement but the choice we made. And now the project undergoes convergence with Windows and Chrome OS.

The Linux kernel has been a rather successful project and likely the most successful open-source project. Please keep your rants to yourself, it's not helpful really.

@aborisovich aborisovich force-pushed the ipc-device-wakes-from-d3 branch from 76d0380 to 4b86668 Compare June 27, 2023 10:57
@aborisovich
Copy link
Contributor Author

Push update:

  • addressed @kv2019i review - fixed whitespaces, typos and changed global_imr_ram_storage pointer to be allocated from the SYS_RUNTIME memory pool.

@aborisovich
Copy link
Contributor Author

I wonder what was author thinking when was creating this rule...

Enjoy the 2013 discussion: https://lore.kernel.org/lkml/1365563834.27174.12.camel@joe-AO722/#r

It had been proved over and over again on many technical and non-technical subjects, that Linux Kernel project leadership is not an entity listening to anyone's reasoning so, no thank you. I will restrain myself from providing references with links because it can be easily found in the internet. The question is why SOF project follows Linux Kernel. I do not think this is a requirement but the choice we made. And now the project undergoes convergence with Windows and Chrome OS.

The Linux kernel has been a rather successful project and likely the most successful open-source project. Please keep your rants to yourself, it's not helpful really.

My rants are my rants. My argumentation is my argumentation. The former is not needed, the latter is valid.

marcinszkudlinski and others added 5 commits June 27, 2023 13:12
During PowerOff (D3) transition Zephyr Power Manager must have
a pointer in IMR to save the LP/HPSRAM memory before
powering off.

As zephyr has no access to IMR heap, the memory must
be allocated by SOF

Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
…SIVE

Zephyr turns on by default CONFIG_PM_DEVICE_RUNTIME_EXCLUSIVE option
what causes Devices using Zephyr Device System Power Manager to
be ignored during SoC power transition. Disabled this option so we
can use default Zephyr kernel behavior to shut down Devices.

Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
Added IPC4 callbacks 'suspend_handler' and 'resume_handler'
to control Zephyr IPC driver.

Co-developed-by: Tomasz Leman <tomasz.m.leman@intel.com>
Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>
Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
Enabled CONFIG_ADSP_IMR_CONTEXT_SAVE option in Kconfig
in the board configuration.

Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
During IPC Device power transition errors may be encountered related to
invalid system state or IPC messages waiting to be send.
In this case we are going to send an IPC response to Host bypassing
schedulers. IPC Device will not change power state when errors occur
preventing whole system from the suspend.

Signed-off-by: Andrey Borisovich <andrey.borisovich@intel.com>
@aborisovich aborisovich force-pushed the ipc-device-wakes-from-d3 branch from 4b86668 to d1aee88 Compare June 27, 2023 11:12
@aborisovich
Copy link
Contributor Author

Is the test failure check-suspend-resume-with-capture-5.sh on MTL nocodec topology known issue?

@kv2019i
Copy link
Collaborator

kv2019i commented Jun 27, 2023

@aborisovich wrote:

Is the test failure check-suspend-resume-with-capture-5.sh on MTL nocodec topology known issue?

Yes, it's a known sporadic fail we see. So https://sof-ci.01.org/sofpr/PR7325/build10138/devicetest/index.html looks good. Of course given your PR changes the D3 flow, we'd ideally have a reliable pass as the baseline to compare against, but alas we don't have that here. Let's see the "System/merge/build" results.

@kv2019i kv2019i dismissed marcinszkudlinski’s stale review June 28, 2023 12:30

Marcin's comments have been addressed and he is not available for re-review this week

@kv2019i
Copy link
Collaborator

kv2019i commented Jun 28, 2023

Known fail in https://sof-ci.01.org/sofpr/PR7325/build10139/devicetest/index.html . https://sof-ci.01.org/sofpr/PR7325/build10138/devicetest/index.html actually looks better than other PRs today (no hits of #7482 ), so this might actually improve the situation. Proceeding with merge.

@marc-hb
Copy link
Collaborator

marc-hb commented Jul 20, 2023

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.