Repository navigation
[RFC] [Do not merge] ipc: support for sending ipc payload using registers added #1339
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -42,6 +42,7 @@ | |
| #include <sof/audio/component.h> | ||
| #include <sof/dma-trace.h> | ||
| #include <sof/preproc.h> | ||
| #include <uapi/ipc/pm.h> | ||
|
|
||
| struct sof; | ||
| struct dai_config; | ||
|
|
@@ -204,14 +205,24 @@ int ipc_dma_trace_send_position(void); | |
| /* get posn offset by pipeline. */ | ||
| int ipc_get_posn_offset(struct ipc *ipc, struct pipeline *pipe); | ||
|
|
||
| enum ipc_payload_location { | ||
| SOF_IPC_PAYLOAD_MEMORY = 0, | ||
| SOF_IPC_PAYLOAD_REGISTER | ||
| }; | ||
|
|
||
| /* private data for IPC */ | ||
| struct ipc_data { | ||
| /* DMA */ | ||
| struct dma *dmac; | ||
| uint8_t *page_table; | ||
|
|
||
| /* PM */ | ||
| int pm_prepare_D3; /* do we need to prepare for D3 */ | ||
| uint32_t pm_target_state; /* SOF_PM_STATE_D.. */ | ||
|
|
||
| /* register based communication */ | ||
| uint32_t ipc_payload; /* SOF_IPC_PAYLOAD_... */ | ||
| uint32_t reg1; | ||
| uint32_t reg2; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't get why this is needed. I thought we would either In both cases, we'd handle the same structure in the end, so not sure why we would keep this information in a intermediate structure. |
||
| }; | ||
|
|
||
| int ipc_cmd(void); | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -124,6 +124,8 @@ | |
| #define SOF_IPC_PM_CLK_GET SOF_CMD_TYPE(0x005) | ||
| #define SOF_IPC_PM_CLK_REQ SOF_CMD_TYPE(0x006) | ||
| #define SOF_IPC_PM_CORE_ENABLE SOF_CMD_TYPE(0x007) | ||
| #define SOF_IPC_PM_STATE_SET SOF_CMD_TYPE(0x008) | ||
| #define SOF_IPC_PM_STATE_GET SOF_CMD_TYPE(0x009) | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we would want to deprecated CTX_SAVE and use STATE_SET(D3) instead. And likewise CTX_RESTORE would be STATE_SET(D0). It's not clear if we need a _GET if there is a reply to SET? In what case would the kernel need to get a state that it didn't set in the first place? |
||
|
|
||
| /** \name DSP Command: Component runtime config - multiple different types | ||
| * @{ | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -75,4 +75,49 @@ struct sof_ipc_pm_core_config { | |
| uint32_t enable_mask; | ||
| } __attribute__((packed)); | ||
|
|
||
| /* DSP subsystem power states */ | ||
| enum sof_pm_state { | ||
| SOF_PM_STATE_D0 = 0, /* D0 only, also initial state */ | ||
| SOF_PM_STATE_D3, /* D3 DSP subsystem is power gated*/ | ||
| /* internal FW transitions across D0ix substates incl. D0 are allowed */ | ||
| SOF_PM_STATE_D0ix, | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could we instead use a bitmap This would keep the definitions for D0 and D3 and allow for new additions fairly easily. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @plbossart I believe there is a similar concern about using bitmaps vs. "enums", part of the recent memory caps discussion (#1394 (comment)). Bitmap enables invalid combinations, not allowed when using enums (not necessarily coded as C enums if this is part of public inter processor API btw).
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @mmaka1 yes, I meant an explicit bitmap with the bit position defined, not an implicit one with the ':1: notation. In other words you have a uint32_t pm_state and its bits define state information.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @plbossart @mmaka1 is the purpose of using bits to be able to specify supported power states e.g. as (D0 | D3 | D0i1)? In that case, yes, I also think using bits would make sense. However, if there's no plan to use such masks, I'm not sure bits make sense?. Sometimes also both are used like |
||
| }; | ||
|
|
||
| /* Flags to allow FW for applying internally clock gating policies */ | ||
| enum sof_pm_cg { | ||
| SOF_PM_CG_ON = 0, /* Clock gating enabled, */ | ||
| SOF_PM_CG_OFF, /* Clock gating disabled */ | ||
| }; | ||
|
|
||
| /* Flags to allow FW for applying power gating policies */ | ||
| enum sof_pm_pg { | ||
| SOF_PM_PG_ON = 0, /* Power gating enabled, */ | ||
| SOF_PM_PG_OFF, /* Power gating disabled */ | ||
| }; | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. why do we need these two definitions if we have boolean states for 'prevent_power_gating' and 'prevent_clock_gating'. Or just like for power state should we have a bitfield that's extensible for power and clock gating? |
||
|
|
||
| /* PM state - SOF_IPC_PM_STATE_SET */ | ||
| struct sof_ipc_pm_state { | ||
| struct sof_ipc_cmd_hdr hdr; | ||
|
|
||
| uint32_t pm_state; /**< power state SOF_PM_STATE_D.. */ | ||
| /**< flag to disable FW logic for autonomous D0ix<->D0 transitions */ | ||
| uint32_t prevent_power_gating; | ||
| /**< flag to disable FW logic for autonomous clock gating */ | ||
| uint32_t prevent_clock_gating; | ||
| /**< reserved for future use */ | ||
| uint32_t reserved[8]; | ||
| } __attribute__((packed)); | ||
|
|
||
| /* PM params info reply - SOF_IPC_PM_STATE_GET */ | ||
| struct sof_ipc_pm_state_reply { | ||
| struct sof_ipc_reply rhdr; | ||
| uint32_t pm_state; /**< power state SOF_PM_STATE_D.. */ | ||
| /**< flag to disable FW logic for autonomous D0ix<->D0 transitions */ | ||
| uint32_t prevent_power_gating; | ||
| /**< flag to disable FW logic for autonomous clock gating */ | ||
| uint32_t prevent_clock_gating; | ||
| /**< reserved for future use */ | ||
| uint32_t reserved[8]; | ||
| } __attribute__((packed)); | ||
|
|
||
| #endif | ||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We add something globally that may not be widely supported. Shouldn't we just guard it with config for
low power ipcand use it by default when available and fallback to mailbox on platforms that don't have lp ipc?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jajanusz I agree, all those defs are related to how the IPC data is transported on a specific set of platforms (Intel cAVS family). Therefore we should create another "transport" layer first and separate common upper logic, n both endpoints, the FW and the driver. Then, we may start introducing changes to the lower transport for Intel cAVS platform like the one proposed in the patch.