#
7dcdad6f |
|
23-May-2023 |
Johan Hovold <johan+linaro@kernel.org> |
interconnect: drop unused icc_get() interface The icc_get() interface can be used to lookup an interconnect path based on global node ids. There has never been any users of this interface and all lookups are currently done from the devicetree. Remove the unused icc_get() interface. Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230523095248.25211-1-johan+linaro@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
|
#
2fcfa72f |
|
03-Jul-2022 |
Peng Fan <peng.fan@nxp.com> |
interconnect: add device managed bulk API Add device managed bulk API to simplify driver. Signed-off-by: Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/20220703091132.1412063-4-peng.fan@oss.nxp.com Signed-off-by: Georgi Djakov <djakov@kernel.org>
|
#
e45f1c1d |
|
01-Mar-2022 |
Georgi Djakov <djakov@kernel.org> |
interconnect: Add stubs for the bulk API Add stub functions for the bulk API to allow compile testing. Reviewed-by: Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20220301090735.26599-1-djakov@kernel.org Signed-off-by: Georgi Djakov <djakov@kernel.org>
|
#
b41b0ce5 |
|
29-Jul-2020 |
Georgi Djakov <georgi.djakov@linaro.org> |
interconnect: Add bulk API helpers There are drivers which just need to get multiple interconnect paths, request some predefined amounts of bandwidth and then just toggle the paths between enabled/disabled state. The aim of this patch is simplify the above and to allow drivers to put all the path names and bandwidth data into a single static icc_bulk_data table and call the icc_bulk_* functions on that table in order to scale all the interconnect paths in parallel. Suggested-by: Evan Green <evgreen@chromium.org> Suggested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200729123439.9961-1-georgi.djakov@linaro.org Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
|
#
0430b1d5 |
|
18-May-2020 |
Viresh Kumar <viresh.kumar@linaro.org> |
opp: Expose bandwidth information via debugfs Expose the bandwidth information as well via debugfs. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
|
#
1597d453 |
|
12-May-2020 |
Georgi Djakov <georgi.djakov@linaro.org> |
interconnect: Add of_icc_get_by_index() helper function This is the same as the traditional of_icc_get() function, but the difference is that it takes index as an argument, instead of name. Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20200512125327.1868-4-georgi.djakov@linaro.org Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
|
#
7d374b20 |
|
10-May-2020 |
Georgi Djakov <georgi.djakov@linaro.org> |
interconnect: Add helpers for enabling/disabling a path There is a repeated pattern in multiple drivers where they want to switch the bandwidth between zero and some other value. This is happening often in the suspend/resume callbacks. Let's add helper functions to enable and disable the path, so that callers don't have to take care of remembering the bandwidth values and handle this in the framework instead. With this patch the users can call icc_disable() and icc_enable() to lower their bandwidth request to zero and then restore it back to it's previous value. Suggested-by: Evan Green <evgreen@chromium.org> Suggested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Link: https://lore.kernel.org/r/20200507120846.8354-1-georgi.djakov@linaro.org Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
|
#
e145d9a1 |
|
15-Apr-2020 |
Akash Asthana <akashast@codeaurora.org> |
interconnect: Add devm_of_icc_get() as exported API for users Users can use devm version of of_icc_get() to benefit from automatic resource release. Signed-off-by: Akash Asthana <akashast@codeaurora.org> Reviewed by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/1586946198-13912-2-git-send-email-akashast@codeaurora.org Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
|
#
127ab2cc |
|
09-Aug-2019 |
Georgi Djakov <georgi.djakov@linaro.org> |
interconnect: Add support for path tags Consumers may have use cases with different bandwidth requirements based on the system or driver state. The consumer driver can append a specific tag to the path and pass this information to the interconnect platform driver to do the aggregation based on this state. Introduce icc_set_tag() function that will allow the consumers to append an optional tag to each path. The aggregation of these tagged paths is platform specific. Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
|
#
87e3031b |
|
16-Jan-2019 |
Georgi Djakov <georgi.djakov@linaro.org> |
interconnect: Allow endpoints translation via DT Currently we support only platform data for specifying the interconnect endpoints. As now the endpoints are hard-coded into the consumer driver this may lead to complications when a single driver is used by multiple SoCs, which may have different interconnect topology. To avoid cluttering the consumer drivers, introduce a translation function to help us get the board specific interconnect data from device-tree. Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
11f1ceca |
|
16-Jan-2019 |
Georgi Djakov <georgi.djakov@linaro.org> |
interconnect: Add generic on-chip interconnect API This patch introduces a new API to get requirements and configure the interconnect buses across the entire chipset to fit with the current demand. The API is using a consumer/provider-based model, where the providers are the interconnect buses and the consumers could be various drivers. The consumers request interconnect resources (path) between endpoints and set the desired constraints on this data flow path. The providers receive requests from consumers and aggregate these requests for all master-slave pairs on that path. Then the providers configure each node along the path to support a bandwidth that satisfies all bandwidth requests that cross through that node. The topology could be complicated and multi-tiered and is SoC specific. Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|