Changes in tcs.h

2705bce5 - soc: qcom: Rework BCM_TCS_CMD macro

Fri, 29 Nov 2024 14:24:46 +0000

soc: qcom: Rework BCM_TCS_CMD macroReworked BCM_TCS_CMD macro in order to fix warnings from sparse:drivers/clk/qcom/clk-rpmh.c:270:28: warning: restricted __le32 degrades to integerdrivers/clk/qcom/clk-rpmh.c:270:28: warning: restricted __le32 degrades to integerWhile at it, used u32_encode_bits which made the code easier tofollow and removed unnecessary shift definitions.The use of cpu_to_le32 was wrong and thus removed.Signed-off-by: Eugen Hristev Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20241129142446.407443-1-eugen.hristev@linaro.orgSigned-off-by: Bjorn Andersson List of files: /linux-6.15/include/soc/qcom/tcs.h

fef419c4 - soc: qcom: rpmh: Remove serialization of TCS commands

Thu, 07 Jan 2021 08:39:30 +0000

soc: qcom: rpmh: Remove serialization of TCS commandsRequests sent to RPMH can be sent as fire-n-forget or response required,with the latter ensuring the command has been completed by the hardwareaccelerator. Commands in a request with tcs_cmd::wait set, would ensurethat those select commands are sent as response required, even thoughthe actual TCS request may be fire-n-forget.Also, commands with .wait flag were also guaranteed to be completebefore the following command in the TCS is sent. This means that thenext command of the same request blocked until the current request iscompleted. This could mean waiting for a voltage to settle or series ofNOCs be configured before the next command is sent. But drivers usingthis feature have never cared about the serialization aspect. By notenforcing the serialization we can allow the hardware to run in parallelimproving the performance.Let's clarify the usage of this member in the tcs_cmd structure to meanonly completion and not serialization. This should also improve theperformance of bus requests where changes could happen in parallel.Also, CPU resume from deep idle may see benefits from certain wakerequests.Reviewed-by: Douglas Anderson Signed-off-by: Lina Iyer Signed-off-by: Maulik Shah Link: https://lore.kernel.org/r/1610008770-13891-1-git-send-email-mkshah@codeaurora.orgSigned-off-by: Bjorn Andersson List of files: /linux-6.15/include/soc/qcom/tcs.h

6311b652 - drivers: qcom: Add BCM vote macro to header

Mon, 05 Aug 2019 20:33:46 +0000

drivers: qcom: Add BCM vote macro to headerThe macro to generate a Bus Controller Manager (BCM) TCS command is usedby the interconnect driver but might also be interesting to otherdrivers that need to construct TCS commands for sub processors so moveit out of the sdm845 specific file and into the header.Signed-off-by: Jordan Crouse Acked-by: Stephen Boyd Acked-by: Bjorn Andersson Signed-off-by: Georgi Djakov List of files: /linux-6.15/include/soc/qcom/tcs.h

658628e7 - drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs

Wed, 20 Jun 2018 13:26:58 +0000

drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCsAdd controller driver for QCOM SoCs that have hardware based sharedresource management. The hardware IP known as RSC (Resource StateCoordinator) houses multiple Direct Resource Voter (DRV) for differentexecution levels. A DRV is a unique voter on the state of a sharedresource. A Trigger Control Set (TCS) is a bunch of slots that can housemultiple resource state requests, that when triggered will issue thoserequests 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 aggregatedalong with state requests from other processors in the SoC and theaggregate value is applied on the resource.Some important aspects of the RPMH communication -- Requests are 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 requestsResource state requests made when CPUs are active are called 'active'state requests. Requests made when all the CPUs are powered down (idlestate) are called 'sleep' state requests. They are matched by acorresponding 'wake' state requests which puts the resources back in topreviously requested active state before resuming any CPU. TCSes arededicated for each type of requests. Active mode TCSes (AMC) are used tosend requests immediately to the resource, while control TCS are used toprovide specific information to the controller. Sleep and Wake TCS sendsleep and wake requests, after and before the system halt respectively.Signed-off-by: Lina Iyer Signed-off-by: Raju P.L.S.S.S.N Signed-off-by: Andy Gross List of files: /linux-6.15/include/soc/qcom/tcs.h