summaryrefslogtreecommitdiff
path: root/drivers/interconnect/core.c
AgeCommit message (Collapse)Author
2020-03-03interconnect: Handle memory allocation errorsGeorgi Djakov
When we allocate memory, kasprintf() can fail and we must check its return value. Fixes: 05309830e1f8 ("interconnect: Add a name to struct icc_path") Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Link: https://lore.kernel.org/r/20200226110420.5357-2-georgi.djakov@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-07interconnect: Check for valid path in icc_set_bw()Georgi Djakov
Use IS_ERR() to ensure that the path passed to icc_set_bw() is valid. Reviewed-by: Evan Green <evgreen@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
2020-01-06interconnect: Print the tag in the debugfs summaryGeorgi Djakov
Now we can have a tag associated with the path. Add this information to the interconnect_summary file, as the current information in debugfs is incomplete. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
2019-12-16interconnect: Add interconnect_graph file to debugfsLeonard Crestez
The interconnect graphs can be difficult to understand and the current "interconnect_summary" file doesn't even display links in any way. Add a new "interconnect_graph" file to debugfs in the graphviz "dot" format which describes interconnect providers, nodes and links. The file is human-readable and can be visualized by piping through graphviz. Example: ssh $TARGET cat /sys/kernel/debug/interconnect/interconnect_graph \ | dot -Tsvg > interconnect_graph.svg Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
2019-12-16interconnect: Add a common standard aggregate functionGeorgi Djakov
Currently there is one very standard aggregation method that is used by several drivers. Let's add this as a common function, so that drivers could just point to it, instead of copy/pasting code. Suggested-by: Evan Green <evgreen@chromium.org> Reviewed-by: Brian Masney <masneyb@onstation.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
2019-12-16interconnect: Add basic tracepointsGeorgi Djakov
The tracepoints can help with understanding the system behavior of a given interconnect path when the consumer drivers change their bandwidth demands. This might be interesting when we want to monitor the requested interconnect bandwidth for each client driver. The paths may share the same nodes and this will help to understand "who and when is requesting what". All this is useful for subsystem drivers developers and may also provide hints when optimizing the power and performance profile of the system. Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
2019-12-16interconnect: Add a name to struct icc_pathGeorgi Djakov
When debugging interconnect things, it turned out that saving the path name and including it in the traces is quite useful, especially for devices with multiple paths. For the path name we use the one specified in DT, or if we use platform data, the name is based on the source and destination node names. Suggested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
2019-12-16interconnect: Move internal structs into a separate fileGeorgi Djakov
Move the interconnect framework internal structs into a separate file, so that it can be included and used by ftrace code. This will allow us to expose some more useful information in the traces. Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
2019-12-16interconnect: Add a common helper for removing all nodesGeorgi Djakov
The removal of all nodes from a provider seem to be a common functionality for all existing users and it would make sense to factor out this into a a common helper function. Suggested-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
2019-10-20interconnect: Add locking in icc_set_tag()Georgi Djakov
We must ensure that the tag is not changed while we aggregate the requests. Currently the icc_set_tag() is not using any locks and this may cause the values to be aggregated incorrectly. Fix this by acquiring the icc_lock while we set the tag. Link: https://lore.kernel.org/lkml/20191018141750.17032-1-georgi.djakov@linaro.org/ Fixes: 127ab2cc5f19 ("interconnect: Add support for path tags") Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
2019-08-13interconnect: Add pre_aggregate() callbackGeorgi Djakov
Introduce an optional callback in interconnect provider drivers. It can be used for implementing actions, that need to be executed before the actual aggregation of the bandwidth requests has started. The benefit of this for now is that it will significantly simplify the code in provider drivers. Suggested-by: Evan Green <evgreen@chromium.org> Reviewed-by: Evan Green <evgreen@chromium.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
2019-08-13interconnect: Add support for path tagsGeorgi Djakov
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>
2019-04-06interconnect: convert to DEFINE_SHOW_ATTRIBUTEYangtao Li
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
2019-01-22interconnect: Revert to previous config if any request failsGeorgi Djakov
When consumers report their bandwidth needs with icc_set_bw(), it's possible that the requested amount of bandwidth is not available or just the new configuration fails to apply on some path. In this case revert to the previous configuration and propagate the error back to the consumers to let them know that bandwidth is not available, hardware is busy or whatever error is returned by the interconnect platform driver. Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-22interconnect: Add debugfs supportGeorgi Djakov
Add a functionality to provide information about the current constraints per each node and provider. 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>
2019-01-22interconnect: Allow endpoints translation via DTGeorgi Djakov
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>
2019-01-22interconnect: Add generic on-chip interconnect APIGeorgi Djakov
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>