Add poll mode support for improved fastrpc performance #258
Conversation
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
ekanshibu
force-pushed
the
set_option
branch
from
93a9f81 to
b31eda1
Compare
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 <ekansh.gupta@oss.qualcomm.com>
ekanshibu
force-pushed
the
set_option
branch
from
b31eda1 to
09efec3
Compare
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));