summaryrefslogtreecommitdiff
path: root/include/soc/qcom
AgeCommit message (Collapse)Author
2018-11-14soc: qcom: cmd-db: Stop memcpy()ing in cmd_db_read_aux_data()Stephen Boyd
Let's change the function signature to return the pointer to memory or an error pointer on failure, and take an argument that lets us return the size of the aux data read. This way we can remove the cmd_db_read_aux_data_len() API entirely and also get rid of the memcpy operation from cmd_db to the caller. Updating the only user of this code shows that making this change allows us to remove a function and put the lookup where the user is. Cc: Mahesh Sivasubramanian <msivasub@codeaurora.org> Cc: Lina Iyer <ilina@codeaurora.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Evan Green <evgreen@chromium.org> Cc: Jordan Crouse <jcrouse@codeaurora.org> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-07-21drivers: qcom: rpmh: add support for batch RPMH requestLina Iyer
Platform drivers need make a lot of resource state requests at the same time, say, at the start or end of an usecase. It can be quite inefficient to send each request separately. Instead they can give the RPMH library a batch of requests to be sent and wait on the whole transaction to be complete. rpmh_write_batch() is a blocking call that can be used to send multiple RPMH command sets. Each RPMH command set is set asynchronously and the API blocks until all the command sets are complete and receive their tx_done callbacks. Signed-off-by: Lina Iyer <ilina@codeaurora.org> Signed-off-by: Raju P.L.S.S.S.N <rplsssn@codeaurora.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-07-21drivers: qcom: rpmh: allow requests to be sent asynchronouslyLina Iyer
Platform drivers that want to send a request but do not want to block until the RPMH request completes have now a new API - rpmh_write_async(). The API allocates memory and send the requests and returns the control back to the platform driver. The tx_done callback from the controller is handled in the context of the controller's thread and frees the allocated memory. This API allows RPMH requests from atomic contexts as well. 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-07-21drivers: qcom: rpmh: cache sleep/wake state requestsLina Iyer
Active state requests are sent immediately to the RSC controller, while sleep and wake state requests are cached in this driver to avoid taxing the RSC controller repeatedly. The cached values will be sent to the controller when the rpmh_flush() is called. Generally, flushing is a system PM activity and may be called from the system PM drivers when the system is entering suspend or deeper sleep modes during cpuidle. Also allow invalidating the cached requests, so they may be re-populated again. Signed-off-by: Lina Iyer <ilina@codeaurora.org> [rplsssn: remove unneeded semicolon, address line over 80chars error] Signed-off-by: Raju P.L.S.S.S.N <rplsssn@codeaurora.org> Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-07-21drivers: qcom: rpmh: add RPMH helper functionsLina Iyer
Sending RPMH requests and waiting for response from the controller through a callback is common functionality across all platform drivers. To simplify drivers, add a library functions to create RPMH client and send resource state requests. rpmh_write() is a synchronous blocking call that can be used to send active state requests. 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-07-21drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCsLina Iyer
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-05-25drivers: qcom: add command DB driverMahesh Sivasubramanian
Command DB is a simple database in the shared memory of QCOM SoCs, that provides information regarding shared resources. Some shared resources in the SoC have properties that are probed dynamically at boot by the remote processor. The information pertaining to the SoC and the platform are made available in the shared memory. Drivers can query this information using predefined strings. Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org> Signed-off-by: Lina Iyer <ilina@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>