aboutsummaryrefslogtreecommitdiff
path: root/drivers/interconnect/core.c
AgeCommit message (Collapse)AuthorFilesLines
2020-10-15interconnect: Aggregate before setting initial bandwidthGeorgi Djakov1-0/+3
When setting the initial bandwidth, make sure to call the aggregate() function (if such is implemented for the current provider), to handle cases when data needs to be aggregated first. Fixes: b1d681d8d324 ("interconnect: Add sync state support") Acked-by: Saravana Kannan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2020-09-18interconnect: core: Simplify with dev_err_probe()Krzysztof Kozlowski1-6/+2
Common pattern of handling deferred probe can be simplified with dev_err_probe(). Less code and the error value gets printed. Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2020-09-18Merge branch 'icc-syncstate' into icc-nextGeorgi Djakov1-0/+67
* icc-syncstate: interconnect: Add get_bw() callback interconnect: Add sync state support interconnect: qcom: Use icc_sync_state Signed-off-by: Georgi Djakov <[email protected]>
2020-09-18interconnect: Add sync state supportGeorgi Djakov1-0/+67
The bootloaders often do some initial configuration of the interconnects in the system and we want to keep this configuration until all consumers have probed and expressed their bandwidth needs. This is because we don't want to change the configuration by starting to disable unused paths until every user had a chance to request the amount of bandwidth it needs. To accomplish this we will implement an interconnect specific sync_state callback which will synchronize (aggregate and set) the current bandwidth settings when all consumers have been probed. Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Saravana Kannan <[email protected]> Signed-off-by: Georgi Djakov <[email protected]>
2020-09-08interconnect: Introduce xlate_extended() callbackGeorgi Djakov1-23/+50
Currently there is the xlate() callback, which is used by providers for mapping the nodes from phandle arguments. That's fine for simple mappings, but the phandle arguments could contain an additional data, such as tag information. Let's create another callback xlate_extended() for the cases where providers want also populate the path tag data. Tested-by: Sibi Sankar <[email protected]> Reviewed-by: Sibi Sankar <[email protected]> Reviewed-by: Matthias Kaehlcke <[email protected]> Tested-by: Matthias Kaehlcke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2020-09-03interconnect: Show bandwidth for disabled paths as zero in debugfsMatthias Kaehlcke1-2/+8
For disabled paths the 'interconnect_summary' in debugfs currently shows the orginally requested bandwidths. This is confusing, since the bandwidth requests aren't active. Instead show the bandwidths for disabled paths/requests as zero. Signed-off-by: Matthias Kaehlcke <[email protected]> Reviewed-by: Evan Green <[email protected]> Link: https://lore.kernel.org/r/20200729104933.1.If8e80e4c0c7ddf99056f6e726e59505ed4e127f3@changeid Signed-off-by: Georgi Djakov <[email protected]>
2020-07-27Merge 5.8-rc7 into char-misc-nextGreg Kroah-Hartman1-3/+9
This should resolve the merge/build issues reported when trying to create linux-next. Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-07-23interconnect: Do not skip aggregation for disabled pathsGeorgi Djakov1-3/+9
When an interconnect path is being disabled, currently we don't aggregate the requests for it afterwards. But the re-aggregation step shouldn't be skipped, as it may leave the nodes with outdated bandwidth data. This outdated data may actually keep the path still enabled and prevent the device from going into lower power states. Reported-by: Atul Dhudase <[email protected]> Fixes: 7d374b209083 ("interconnect: Add helpers for enabling/disabling a path") Reviewed-by: Sibi Sankar <[email protected]> Tested-by: Atul Dhudase <[email protected]> Reviewed-by: Atul Dhudase <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-06-16interconnect: Allow inter-provider pairs to be configuredArtur Świgoń1-6/+5
This patch adds support for a new boolean 'inter_set' field in struct icc_provider. Setting it to 'true' enables calling '->set' for inter-provider node pairs. All existing users of the interconnect framework allocate this structure with kzalloc, and are therefore unaffected by this change. This makes it easier for hierarchies like exynos-bus, where every bus is probed separately and registers a separate interconnect provider, to model constraints between buses. Signed-off-by: Artur Świgoń <[email protected]> Signed-off-by: Sylwester Nawrocki <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2020-06-16interconnect: Relax requirement in of_icc_get_from_provider()Artur Świgoń1-1/+1
This patch relaxes the condition in of_icc_get_from_provider() so that it is no longer required to set '#interconnect-cells' to <1> in the DT, and therefore it is not required to supply dummy node IDs in the 'interconnects' property when node IDs are dynamically generated rather than hardcoded (statically allocated). In case of the devfreq driver for exynos-bus, node IDs are dynamically allocated and '#interconnect-cells' is always zero. Signed-off-by: Artur Świgoń <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Chanwoo Choi <[email protected]> Signed-off-by: Sylwester Nawrocki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2020-06-16interconnect: Export of_icc_get_from_provider()Artur Świgoń1-1/+2
This patch makes the above function public (for use in exynos-bus devfreq driver). Signed-off-by: Artur Świgoń <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Chanwoo Choi <[email protected]> Signed-off-by: Sylwester Nawrocki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2020-06-10Merge tag 'pm-5.8-rc1-2' of ↵Linus Torvalds1-0/+18
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull more power management updates from Rafael Wysocki: "These are operating performance points (OPP) framework updates mostly, including support for interconnect bandwidth in the OPP core, plus a few cpufreq changes, including boost support in the CPPC cpufreq driver, an ACPI device power management fix and a hibernation code cleanup. Specifics: - Add support for interconnect bandwidth to the OPP core (Georgi Djakov, Saravana Kannan, Sibi Sankar, Viresh Kumar). - Add support for regulator enable/disable to the OPP core (Kamil Konieczny). - Add boost support to the CPPC cpufreq driver (Xiongfeng Wang). - Make the tegra186 cpufreq driver set the CPUFREQ_NEED_INITIAL_FREQ_CHECK flag (Mian Yousaf Kaukab). - Prevent the ACPI power management from using power resources with devices where the list of power resources for power state D0 (full power) is missing (Rafael Wysocki). - Annotate a hibernation-related function with __init (Christophe JAILLET)" * tag 'pm-5.8-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: PM: Avoid using power resources if there are none for D0 cpufreq: CPPC: add SW BOOST support cpufreq: change '.set_boost' to act on one policy PM: hibernate: Add __init annotation to swsusp_header_init() opp: Don't parse icc paths unnecessarily opp: Remove bandwidth votes when target_freq is zero opp: core: add regulators enable and disable opp: Reorder the code for !target_freq case opp: Expose bandwidth information via debugfs cpufreq: dt: Add support for interconnect bandwidth scaling opp: Update the bandwidth on OPP frequency changes opp: Add sanity checks in _read_opp_key() opp: Add support for parsing interconnect bandwidth cpufreq: tegra186: add CPUFREQ_NEED_INITIAL_FREQ_CHECK flag OPP: Add helpers for reading the binding properties dt-bindings: opp: Introduce opp-peak-kBps and opp-avg-kBps bindings
2020-05-29opp: Expose bandwidth information via debugfsViresh Kumar1-0/+18
Expose the bandwidth information as well via debugfs. Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Georgi Djakov <[email protected]>
2020-05-15Merge branch 'icc-get-by-index' into icc-nextGeorgi Djakov1-24/+55
This is an immutable branch shared with the OPP tree. It contains also the patches to convert the interconnect framework from tristate to bool after Greg agreed with that. This will make the integration between the OPP layer and interconnect much easier. * icc-get-by-index: interconnect: Add of_icc_get_by_index() helper function interconnect: Disallow interconnect core to be built as a module interconnect: Remove unused module exit code from core Signed-off-by: Georgi Djakov <[email protected]>
2020-05-15interconnect: Remove unused module exit code from coreJordan Crouse1-6/+1
The interconnect core is currently always built in: menuconfig INTERCONNECT bool "On-Chip Interconnect management support" So remove the module_exit function and symbolically rename module_init to device_initcall to drive home the point. Signed-off-by: Jordan Crouse <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2020-05-13interconnect: Add of_icc_get_by_index() helper functionGeorgi Djakov1-18/+54
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 <[email protected]> Reviewed-by: Sibi Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2020-05-10interconnect: Add helpers for enabling/disabling a pathGeorgi Djakov1-1/+38
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 <[email protected]> Suggested-by: Bjorn Andersson <[email protected]> Signed-off-by: Georgi Djakov <[email protected]> Reviewed-by: Matthias Kaehlcke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2020-04-27interconnect: Add devm_of_icc_get() as exported API for usersAkash Asthana1-0/+25
Users can use devm version of of_icc_get() to benefit from automatic resource release. Signed-off-by: Akash Asthana <[email protected]> Reviewed by: Matthias Kaehlcke <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2020-03-03interconnect: Handle memory allocation errorsGeorgi Djakov1-0/+9
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-01-07interconnect: Check for valid path in icc_set_bw()Georgi Djakov1-1/+4
Use IS_ERR() to ensure that the path passed to icc_set_bw() is valid. Reviewed-by: Evan Green <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Georgi Djakov <[email protected]>
2020-01-06interconnect: Print the tag in the debugfs summaryGeorgi Djakov1-5/+5
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 <[email protected]> Signed-off-by: Georgi Djakov <[email protected]>
2019-12-16interconnect: Add interconnect_graph file to debugfsLeonard Crestez1-0/+66
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 <[email protected]> Reviewed-by: Greg Kroah-Hartman <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Georgi Djakov <[email protected]>
2019-12-16interconnect: Add a common standard aggregate functionGeorgi Djakov1-0/+10
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 <[email protected]> Reviewed-by: Brian Masney <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Reviewed-by: Evan Green <[email protected]> Signed-off-by: Georgi Djakov <[email protected]>
2019-12-16interconnect: Add basic tracepointsGeorgi Djakov1-0/+7
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) <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Georgi Djakov <[email protected]>
2019-12-16interconnect: Add a name to struct icc_pathGeorgi Djakov1-3/+15
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 <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Georgi Djakov <[email protected]>
2019-12-16interconnect: Move internal structs into a separate fileGeorgi Djakov1-28/+2
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 <[email protected]> Signed-off-by: Georgi Djakov <[email protected]>
2019-12-16interconnect: Add a common helper for removing all nodesGeorgi Djakov1-0/+22
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 <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Georgi Djakov <[email protected]>
2019-10-20interconnect: Add locking in icc_set_tag()Georgi Djakov1-0/+4
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/[email protected]/ Fixes: 127ab2cc5f19 ("interconnect: Add support for path tags") Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Georgi Djakov <[email protected]>
2019-08-13interconnect: Add pre_aggregate() callbackGeorgi Djakov1-0/+3
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 <[email protected]> Reviewed-by: Evan Green <[email protected]> Signed-off-by: Georgi Djakov <[email protected]>
2019-08-13interconnect: Add support for path tagsGeorgi Djakov1-1/+23
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 <[email protected]> Signed-off-by: Georgi Djakov <[email protected]>
2019-04-06interconnect: convert to DEFINE_SHOW_ATTRIBUTEYangtao Li1-12/+1
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Signed-off-by: Yangtao Li <[email protected]> Signed-off-by: Georgi Djakov <[email protected]>
2019-01-22interconnect: Revert to previous config if any request failsGeorgi Djakov1-2/+15
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 <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-01-22interconnect: Add debugfs supportGeorgi Djakov1-0/+70
Add a functionality to provide information about the current constraints per each node and provider. Reviewed-by: Evan Green <[email protected]> Signed-off-by: Georgi Djakov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-01-22interconnect: Allow endpoints translation via DTGeorgi Djakov1-0/+149
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 <[email protected]> Signed-off-by: Georgi Djakov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2019-01-22interconnect: Add generic on-chip interconnect APIGeorgi Djakov1-0/+567
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 <[email protected]> Signed-off-by: Georgi Djakov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.