Add poll mode support for improved fastrpc performance#258
Open
ekanshibu wants to merge 1 commit intoqualcomm:developmentfrom
Open
Add poll mode support for improved fastrpc performance#258ekanshibu wants to merge 1 commit intoqualcomm:developmentfrom
ekanshibu wants to merge 1 commit intoqualcomm:developmentfrom
Conversation
ekanshibu
force-pushed
the
set_option
branch
2 times, most recently
from
b31eda1 to
09efec3
Compare
|
This pull request has been marked as stale due to 60 days of inactivity. |
For any remote call to DSP, after sending an invocation message,
fastRPC driver waits for glink response and during this time the
CPU can go into low power modes. With polling mode support fastRPC
driver can poll continuously on a memory after sending a message
to remote subsystem which will eliminate CPU wakeup and scheduling
latencies and reduce fastRPC overhead. With this change, DSP always
sends a glink response which will get ignored if polling mode didn't
time out.
Steps to enable polling mode:
** Remote control structure **:
typedef enum remote_rpc_latency_flags {
RPC_DISABLE_QOS = 0,
RPC_PM_QOS,
RPC_ADAPTIVE_QOS,
RPC_POLL_QOS,
} remote_rpc_control_latency_t;
struct remote_rpc_control_latency {
remote_rpc_control_latency_t enable;
uint32_t latency;
};
** Application code **:
struct remote_rpc_control_latency data;
data.enable = RPC_POLL_QOS;
err = remote_handle64_control(h, DSPRPC_CONTROL_LATENCY, (void*)&data, sizeof(data));
Signed-off-by: Ekansh Gupta <[email protected]>
ekanshibu
force-pushed
the
set_option
branch
from
09efec3 to
a55c39e
Compare
|
qualcomm/fastrpc.triage This pull request has been marked as stale due to 30 days of inactivity. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For any remote call to DSP, after sending an invocation message, fastRPC driver waits for glink response and during this time the CPU can go into low power modes. With polling mode support fastRPC driver can poll continuously on a memory after sending a message to remote subsystem which will eliminate CPU wakeup and scheduling latencies and reduce fastRPC overhead. With this change, DSP always sends a glink response which will get ignored if polling mode didn't time out.
Steps to enable polling mode:
** Remote control structure **:
typedef enum remote_rpc_latency_flags {
RPC_DISABLE_QOS = 0,
RPC_PM_QOS,
RPC_ADAPTIVE_QOS,
RPC_POLL_QOS,
} remote_rpc_control_latency_t;
struct remote_rpc_control_latency {
remote_rpc_control_latency_t enable;
uint32_t latency;
};
** Application code **:
struct remote_rpc_control_latency data;
data.enable = RPC_POLL_QOS;
err = remote_handle64_control(h, DSPRPC_CONTROL_LATENCY, (void*)&data, sizeof(data));