public-mirrors/linux
1
0
Fork 0
mirror of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2025-08-05 16:54:27 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
linux/include/soc/qcom/tcs.h

80 lines
2.5 KiB
C
Raw Permalink Normal View History

drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs Add controller driver for QCOM SoCs that have hardware based shared resource management. The hardware IP known as RSC (Resource State Coordinator) houses multiple Direct Resource Voter (DRV) for different execution levels. A DRV is a unique voter on the state of a shared resource. A Trigger Control Set (TCS) is a bunch of slots that can house multiple resource state requests, that when triggered will issue those requests through an internal bus to the Resource Power Manager Hardened (RPMH) blocks. These hardware blocks are capable of adjusting clocks, voltages, etc. The resource state request from a DRV are aggregated along with state requests from other processors in the SoC and the aggregate value is applied on the resource. Some important aspects of the RPMH communication - - Requests are <addr, value> with some header information - Multiple requests (upto 16) may be sent through a TCS, at a time - Requests in a TCS are sent in sequence - Requests may be fire-n-forget or completion (response expected) - Multiple TCS from the same DRV may be triggered simultaneously - Cannot send a request if another request for the same addr is in progress from the same DRV - When all the requests from a TCS are complete, an IRQ is raised - The IRQ handler needs to clear the TCS before it is available for reuse - TCS configuration is specific to a DRV - Platform drivers may use DRV from different RSCs to make requests Resource state requests made when CPUs are active are called 'active' state requests. Requests made when all the CPUs are powered down (idle state) are called 'sleep' state requests. They are matched by a corresponding 'wake' state requests which puts the resources back in to previously requested active state before resuming any CPU. TCSes are dedicated for each type of requests. Active mode TCSes (AMC) are used to send requests immediately to the resource, while control TCS are used to provide specific information to the controller. Sleep and Wake TCS send sleep and wake requests, after and before the system halt respectively. Signed-off-by: Lina Iyer <ilina@codeaurora.org> Signed-off-by: Raju P.L.S.S.S.N <rplsssn@codeaurora.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-06-20 18:56:58 +05:30
/* SPDX-License-Identifier: GPL-2.0 */
/*
drivers: qcom: Add BCM vote macro to header The macro to generate a Bus Controller Manager (BCM) TCS command is used by the interconnect driver but might also be interesting to other drivers that need to construct TCS commands for sub processors so move it out of the sdm845 specific file and into the header. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Acked-by: Stephen Boyd <sboyd@kernel.org> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
2019-08-05 14:33:46 -06:00
* Copyright (c) 2016-2019, The Linux Foundation. All rights reserved.
drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs Add controller driver for QCOM SoCs that have hardware based shared resource management. The hardware IP known as RSC (Resource State Coordinator) houses multiple Direct Resource Voter (DRV) for different execution levels. A DRV is a unique voter on the state of a shared resource. A Trigger Control Set (TCS) is a bunch of slots that can house multiple resource state requests, that when triggered will issue those requests through an internal bus to the Resource Power Manager Hardened (RPMH) blocks. These hardware blocks are capable of adjusting clocks, voltages, etc. The resource state request from a DRV are aggregated along with state requests from other processors in the SoC and the aggregate value is applied on the resource. Some important aspects of the RPMH communication - - Requests are <addr, value> with some header information - Multiple requests (upto 16) may be sent through a TCS, at a time - Requests in a TCS are sent in sequence - Requests may be fire-n-forget or completion (response expected) - Multiple TCS from the same DRV may be triggered simultaneously - Cannot send a request if another request for the same addr is in progress from the same DRV - When all the requests from a TCS are complete, an IRQ is raised - The IRQ handler needs to clear the TCS before it is available for reuse - TCS configuration is specific to a DRV - Platform drivers may use DRV from different RSCs to make requests Resource state requests made when CPUs are active are called 'active' state requests. Requests made when all the CPUs are powered down (idle state) are called 'sleep' state requests. They are matched by a corresponding 'wake' state requests which puts the resources back in to previously requested active state before resuming any CPU. TCSes are dedicated for each type of requests. Active mode TCSes (AMC) are used to send requests immediately to the resource, while control TCS are used to provide specific information to the controller. Sleep and Wake TCS send sleep and wake requests, after and before the system halt respectively. Signed-off-by: Lina Iyer <ilina@codeaurora.org> Signed-off-by: Raju P.L.S.S.S.N <rplsssn@codeaurora.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-06-20 18:56:58 +05:30
*/
#ifndef __SOC_QCOM_TCS_H__
#define __SOC_QCOM_TCS_H__
soc: qcom: Rework BCM_TCS_CMD macro Reworked BCM_TCS_CMD macro in order to fix warnings from sparse: drivers/clk/qcom/clk-rpmh.c:270:28: warning: restricted __le32 degrades to integer drivers/clk/qcom/clk-rpmh.c:270:28: warning: restricted __le32 degrades to integer While at it, used u32_encode_bits which made the code easier to follow and removed unnecessary shift definitions. The use of cpu_to_le32 was wrong and thus removed. Signed-off-by: Eugen Hristev <eugen.hristev@linaro.org> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20241129142446.407443-1-eugen.hristev@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-29 16:24:46 +02:00
#include <linux/bitfield.h>
#include <linux/bits.h>
drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs Add controller driver for QCOM SoCs that have hardware based shared resource management. The hardware IP known as RSC (Resource State Coordinator) houses multiple Direct Resource Voter (DRV) for different execution levels. A DRV is a unique voter on the state of a shared resource. A Trigger Control Set (TCS) is a bunch of slots that can house multiple resource state requests, that when triggered will issue those requests through an internal bus to the Resource Power Manager Hardened (RPMH) blocks. These hardware blocks are capable of adjusting clocks, voltages, etc. The resource state request from a DRV are aggregated along with state requests from other processors in the SoC and the aggregate value is applied on the resource. Some important aspects of the RPMH communication - - Requests are <addr, value> with some header information - Multiple requests (upto 16) may be sent through a TCS, at a time - Requests in a TCS are sent in sequence - Requests may be fire-n-forget or completion (response expected) - Multiple TCS from the same DRV may be triggered simultaneously - Cannot send a request if another request for the same addr is in progress from the same DRV - When all the requests from a TCS are complete, an IRQ is raised - The IRQ handler needs to clear the TCS before it is available for reuse - TCS configuration is specific to a DRV - Platform drivers may use DRV from different RSCs to make requests Resource state requests made when CPUs are active are called 'active' state requests. Requests made when all the CPUs are powered down (idle state) are called 'sleep' state requests. They are matched by a corresponding 'wake' state requests which puts the resources back in to previously requested active state before resuming any CPU. TCSes are dedicated for each type of requests. Active mode TCSes (AMC) are used to send requests immediately to the resource, while control TCS are used to provide specific information to the controller. Sleep and Wake TCS send sleep and wake requests, after and before the system halt respectively. Signed-off-by: Lina Iyer <ilina@codeaurora.org> Signed-off-by: Raju P.L.S.S.S.N <rplsssn@codeaurora.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-06-20 18:56:58 +05:30
#define MAX_RPMH_PAYLOAD 16
/**
* rpmh_state: state for the request
*
* RPMH_SLEEP_STATE: State of the resource when the processor subsystem
* is powered down. There is no client using the
* resource actively.
* RPMH_WAKE_ONLY_STATE: Resume resource state to the value previously
* requested before the processor was powered down.
* RPMH_ACTIVE_ONLY_STATE: Active or AMC mode requests. Resource state
* is aggregated immediately.
*/
enum rpmh_state {
RPMH_SLEEP_STATE,
RPMH_WAKE_ONLY_STATE,
RPMH_ACTIVE_ONLY_STATE,
};
/**
* struct tcs_cmd: an individual request to RPMH.
*
* @addr: the address of the resource slv_id:18:16 | offset:0:15
* @data: the resource state request
soc: qcom: rpmh: Remove serialization of TCS commands Requests sent to RPMH can be sent as fire-n-forget or response required, with the latter ensuring the command has been completed by the hardware accelerator. Commands in a request with tcs_cmd::wait set, would ensure that those select commands are sent as response required, even though the actual TCS request may be fire-n-forget. Also, commands with .wait flag were also guaranteed to be complete before the following command in the TCS is sent. This means that the next command of the same request blocked until the current request is completed. This could mean waiting for a voltage to settle or series of NOCs be configured before the next command is sent. But drivers using this feature have never cared about the serialization aspect. By not enforcing the serialization we can allow the hardware to run in parallel improving the performance. Let's clarify the usage of this member in the tcs_cmd structure to mean only completion and not serialization. This should also improve the performance of bus requests where changes could happen in parallel. Also, CPU resume from deep idle may see benefits from certain wake requests. Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Lina Iyer <ilina@codeaurora.org> Signed-off-by: Maulik Shah <mkshah@codeaurora.org> Link: https://lore.kernel.org/r/1610008770-13891-1-git-send-email-mkshah@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-07 14:09:30 +05:30
* @wait: ensure that this command is complete before returning.
* Setting "wait" here only makes sense during rpmh_write_batch() for
* active-only transfers, this is because:
* rpmh_write() - Always waits.
* (DEFINE_RPMH_MSG_ONSTACK will set .wait_for_compl)
* rpmh_write_async() - Never waits.
* (There's no request completion callback)
drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs Add controller driver for QCOM SoCs that have hardware based shared resource management. The hardware IP known as RSC (Resource State Coordinator) houses multiple Direct Resource Voter (DRV) for different execution levels. A DRV is a unique voter on the state of a shared resource. A Trigger Control Set (TCS) is a bunch of slots that can house multiple resource state requests, that when triggered will issue those requests through an internal bus to the Resource Power Manager Hardened (RPMH) blocks. These hardware blocks are capable of adjusting clocks, voltages, etc. The resource state request from a DRV are aggregated along with state requests from other processors in the SoC and the aggregate value is applied on the resource. Some important aspects of the RPMH communication - - Requests are <addr, value> with some header information - Multiple requests (upto 16) may be sent through a TCS, at a time - Requests in a TCS are sent in sequence - Requests may be fire-n-forget or completion (response expected) - Multiple TCS from the same DRV may be triggered simultaneously - Cannot send a request if another request for the same addr is in progress from the same DRV - When all the requests from a TCS are complete, an IRQ is raised - The IRQ handler needs to clear the TCS before it is available for reuse - TCS configuration is specific to a DRV - Platform drivers may use DRV from different RSCs to make requests Resource state requests made when CPUs are active are called 'active' state requests. Requests made when all the CPUs are powered down (idle state) are called 'sleep' state requests. They are matched by a corresponding 'wake' state requests which puts the resources back in to previously requested active state before resuming any CPU. TCSes are dedicated for each type of requests. Active mode TCSes (AMC) are used to send requests immediately to the resource, while control TCS are used to provide specific information to the controller. Sleep and Wake TCS send sleep and wake requests, after and before the system halt respectively. Signed-off-by: Lina Iyer <ilina@codeaurora.org> Signed-off-by: Raju P.L.S.S.S.N <rplsssn@codeaurora.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-06-20 18:56:58 +05:30
*/
struct tcs_cmd {
u32 addr;
u32 data;
u32 wait;
};
/**
* struct tcs_request: A set of tcs_cmds sent together in a TCS
*
* @state: state for the request.
* @wait_for_compl: wait until we get a response from the h/w accelerator
soc: qcom: rpmh: Remove serialization of TCS commands Requests sent to RPMH can be sent as fire-n-forget or response required, with the latter ensuring the command has been completed by the hardware accelerator. Commands in a request with tcs_cmd::wait set, would ensure that those select commands are sent as response required, even though the actual TCS request may be fire-n-forget. Also, commands with .wait flag were also guaranteed to be complete before the following command in the TCS is sent. This means that the next command of the same request blocked until the current request is completed. This could mean waiting for a voltage to settle or series of NOCs be configured before the next command is sent. But drivers using this feature have never cared about the serialization aspect. By not enforcing the serialization we can allow the hardware to run in parallel improving the performance. Let's clarify the usage of this member in the tcs_cmd structure to mean only completion and not serialization. This should also improve the performance of bus requests where changes could happen in parallel. Also, CPU resume from deep idle may see benefits from certain wake requests. Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Lina Iyer <ilina@codeaurora.org> Signed-off-by: Maulik Shah <mkshah@codeaurora.org> Link: https://lore.kernel.org/r/1610008770-13891-1-git-send-email-mkshah@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-01-07 14:09:30 +05:30
* (same as setting cmd->wait for all commands in the request)
drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs Add controller driver for QCOM SoCs that have hardware based shared resource management. The hardware IP known as RSC (Resource State Coordinator) houses multiple Direct Resource Voter (DRV) for different execution levels. A DRV is a unique voter on the state of a shared resource. A Trigger Control Set (TCS) is a bunch of slots that can house multiple resource state requests, that when triggered will issue those requests through an internal bus to the Resource Power Manager Hardened (RPMH) blocks. These hardware blocks are capable of adjusting clocks, voltages, etc. The resource state request from a DRV are aggregated along with state requests from other processors in the SoC and the aggregate value is applied on the resource. Some important aspects of the RPMH communication - - Requests are <addr, value> with some header information - Multiple requests (upto 16) may be sent through a TCS, at a time - Requests in a TCS are sent in sequence - Requests may be fire-n-forget or completion (response expected) - Multiple TCS from the same DRV may be triggered simultaneously - Cannot send a request if another request for the same addr is in progress from the same DRV - When all the requests from a TCS are complete, an IRQ is raised - The IRQ handler needs to clear the TCS before it is available for reuse - TCS configuration is specific to a DRV - Platform drivers may use DRV from different RSCs to make requests Resource state requests made when CPUs are active are called 'active' state requests. Requests made when all the CPUs are powered down (idle state) are called 'sleep' state requests. They are matched by a corresponding 'wake' state requests which puts the resources back in to previously requested active state before resuming any CPU. TCSes are dedicated for each type of requests. Active mode TCSes (AMC) are used to send requests immediately to the resource, while control TCS are used to provide specific information to the controller. Sleep and Wake TCS send sleep and wake requests, after and before the system halt respectively. Signed-off-by: Lina Iyer <ilina@codeaurora.org> Signed-off-by: Raju P.L.S.S.S.N <rplsssn@codeaurora.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-06-20 18:56:58 +05:30
* @num_cmds: the number of @cmds in this request
* @cmds: an array of tcs_cmds
*/
struct tcs_request {
enum rpmh_state state;
u32 wait_for_compl;
u32 num_cmds;
struct tcs_cmd *cmds;
};
soc: qcom: Rework BCM_TCS_CMD macro Reworked BCM_TCS_CMD macro in order to fix warnings from sparse: drivers/clk/qcom/clk-rpmh.c:270:28: warning: restricted __le32 degrades to integer drivers/clk/qcom/clk-rpmh.c:270:28: warning: restricted __le32 degrades to integer While at it, used u32_encode_bits which made the code easier to follow and removed unnecessary shift definitions. The use of cpu_to_le32 was wrong and thus removed. Signed-off-by: Eugen Hristev <eugen.hristev@linaro.org> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20241129142446.407443-1-eugen.hristev@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-29 16:24:46 +02:00
#define BCM_TCS_CMD_COMMIT_MASK BIT(30)
#define BCM_TCS_CMD_VALID_MASK BIT(29)
#define BCM_TCS_CMD_VOTE_MASK GENMASK(13, 0)
#define BCM_TCS_CMD_VOTE_Y_MASK GENMASK(13, 0)
#define BCM_TCS_CMD_VOTE_X_MASK GENMASK(27, 14)
drivers: qcom: Add BCM vote macro to header The macro to generate a Bus Controller Manager (BCM) TCS command is used by the interconnect driver but might also be interesting to other drivers that need to construct TCS commands for sub processors so move it out of the sdm845 specific file and into the header. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Acked-by: Stephen Boyd <sboyd@kernel.org> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
2019-08-05 14:33:46 -06:00
/* Construct a Bus Clock Manager (BCM) specific TCS command */
#define BCM_TCS_CMD(commit, valid, vote_x, vote_y) \
soc: qcom: Rework BCM_TCS_CMD macro Reworked BCM_TCS_CMD macro in order to fix warnings from sparse: drivers/clk/qcom/clk-rpmh.c:270:28: warning: restricted __le32 degrades to integer drivers/clk/qcom/clk-rpmh.c:270:28: warning: restricted __le32 degrades to integer While at it, used u32_encode_bits which made the code easier to follow and removed unnecessary shift definitions. The use of cpu_to_le32 was wrong and thus removed. Signed-off-by: Eugen Hristev <eugen.hristev@linaro.org> Reviewed-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20241129142446.407443-1-eugen.hristev@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-11-29 16:24:46 +02:00
(u32_encode_bits(commit, BCM_TCS_CMD_COMMIT_MASK) | \
u32_encode_bits(valid, BCM_TCS_CMD_VALID_MASK) | \
u32_encode_bits(vote_x, BCM_TCS_CMD_VOTE_X_MASK) | \
u32_encode_bits(vote_y, BCM_TCS_CMD_VOTE_Y_MASK))
drivers: qcom: Add BCM vote macro to header The macro to generate a Bus Controller Manager (BCM) TCS command is used by the interconnect driver but might also be interesting to other drivers that need to construct TCS commands for sub processors so move it out of the sdm845 specific file and into the header. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Acked-by: Stephen Boyd <sboyd@kernel.org> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
2019-08-05 14:33:46 -06:00
drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs Add controller driver for QCOM SoCs that have hardware based shared resource management. The hardware IP known as RSC (Resource State Coordinator) houses multiple Direct Resource Voter (DRV) for different execution levels. A DRV is a unique voter on the state of a shared resource. A Trigger Control Set (TCS) is a bunch of slots that can house multiple resource state requests, that when triggered will issue those requests through an internal bus to the Resource Power Manager Hardened (RPMH) blocks. These hardware blocks are capable of adjusting clocks, voltages, etc. The resource state request from a DRV are aggregated along with state requests from other processors in the SoC and the aggregate value is applied on the resource. Some important aspects of the RPMH communication - - Requests are <addr, value> with some header information - Multiple requests (upto 16) may be sent through a TCS, at a time - Requests in a TCS are sent in sequence - Requests may be fire-n-forget or completion (response expected) - Multiple TCS from the same DRV may be triggered simultaneously - Cannot send a request if another request for the same addr is in progress from the same DRV - When all the requests from a TCS are complete, an IRQ is raised - The IRQ handler needs to clear the TCS before it is available for reuse - TCS configuration is specific to a DRV - Platform drivers may use DRV from different RSCs to make requests Resource state requests made when CPUs are active are called 'active' state requests. Requests made when all the CPUs are powered down (idle state) are called 'sleep' state requests. They are matched by a corresponding 'wake' state requests which puts the resources back in to previously requested active state before resuming any CPU. TCSes are dedicated for each type of requests. Active mode TCSes (AMC) are used to send requests immediately to the resource, while control TCS are used to provide specific information to the controller. Sleep and Wake TCS send sleep and wake requests, after and before the system halt respectively. Signed-off-by: Lina Iyer <ilina@codeaurora.org> Signed-off-by: Raju P.L.S.S.S.N <rplsssn@codeaurora.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-06-20 18:56:58 +05:30
#endif /* __SOC_QCOM_TCS_H__ */
Reference in a new issue Copy permalink