[v10,0/8] Introduce on-chip interconnect API

Modern SoCs have multiple processors and various dedicated cores (video, gpu,
graphics, modem). These cores are talking to each other and can generate a
lot of data flowing through the on-chip interconnects. These interconnect
buses could form different topologies such as crossbar, point to point buses,
hierarchical buses or use the network-on-chip concept.

These buses have been sized usually to handle use cases with high data
throughput but it is not necessary all the time and consume a lot of power.
Furthermore, the priority between masters can vary depending on the running
use case like video playback or CPU intensive tasks.

Having an API to control the requirement of the system in terms of bandwidth
and QoS, so we can adapt the interconnect configuration to match those by
scaling the frequencies, setting link priority and tuning QoS parameters.
This configuration can be a static, one-time operation done at boot for some
platforms or a dynamic set of operations that happen at run-time.

This patchset introduce a new API to get the requirement and configure the
interconnect buses across the entire chipset to fit with the current demand.
The API is NOT for changing the performance of the endpoint devices, but only
the interconnect path in between them.

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) to an endpoint and set
the desired constraints on this data flow path. The provider(s) receive
requests from consumers and aggregate these requests for all master-slave
pairs on that path. Then the providers configure each participating in the
topology node according to the requested data flow path, physical links and
constraints. The topology could be complicated and multi-tiered and is SoC
specific.

Below is a simplified diagram of a real-world SoC topology. The interconnect
providers are the NoCs.

+----------------+    +----------------+
| HW Accelerator |--->|      M NoC     |<---------------+
+----------------+    +----------------+                |
                        |      |                    +------------+
 +-----+  +-------------+      V       +------+     |            |
 | DDR |  |                +--------+  | PCIe |     |            |
 +-----+  |                | Slaves |  +------+     |            |
   ^ ^    |                +--------+     |         |   C NoC    |
   | |    V                               V         |            |
+------------------+   +------------------------+   |            |   +-----+
|                  |-->|                        |-->|            |-->| CPU |
|                  |-->|                        |<--|            |   +-----+
|     Mem NoC      |   |         S NoC          |   +------------+
|                  |<--|                        |---------+    |
|                  |<--|                        |<------+ |    |   +--------+
+------------------+   +------------------------+       | |    +-->| Slaves |
  ^  ^    ^    ^          ^                             | |        +--------+
  |  |    |    |          |                             | V
+------+  |  +-----+   +-----+  +---------+   +----------------+   +--------+
| CPUs |  |  | GPU |   | DSP |  | Masters |-->|       P NoC    |-->| Slaves |
+------+  |  +-----+   +-----+  +---------+   +----------------+   +--------+
          |
      +-------+
      | Modem |
      +-------+

TODO:
* Create icc_set_extended() to handle parameters such as latency and other
  QoS values. Nvidia and Qcom guys are interested in this.
* Cache the path between the nodes instead of walking the graph on each get().
* Sync interconnect requests with the idle state of the device.

Changes since patchset v9 (https://lkml.org/lkml/2018/8/31/444)
* Converted from using global node identifiers to local per provider ids.
* Dropped msm8916 platform driver until we figure out DT bindings.
* Included sdm845 platform driver instead.
* Added macros for converting to mbps, gbps, etc. to icc units.
* Added comments about aggregation, other minor changes.
* Fixed uninitialized variable. (Gustavo A. R. Silva)
* Removed set but not used variable. (YueHaibing)
* Fixed build error without DEBUGFS. (Arnd Bergmann)

Changes since patchset v8 (https://lkml.org/lkml/2018/8/10/387)
* Fixed the names of the files when built as modules.
* Corrected some typos in comments.

Changes since patchset v7 (https://lkml.org/lkml/2018/7/31/647)
* Addressed comments on kernel-doc and grammar. (Randy)
* Picked Reviewed-by: Evan
* Squashed consumer and provider DT bindings into single patch. (Rob)
* Cleaned-up msm8916 DT bindings docs by removing unused port ids.
* Updated documentation for the cases when NULL is returned. (Saravana)
* New patch to add myself as maintainer.

Changes since patchset v6 (https://lkml.org/lkml/2018/7/9/698)
* [patches 1,6]: Move the aggregation within the provider from the framework to
  the platform driver's set() callback, as the aggregation point could be SoC
  specific.
* [patch 1]: Include missing header, reset state only of the traversed nodes,
  move more code into path_init(), add more asserts, move misplaced mutex,
  simplify icc_link_destroy() (Evan)
* [patch 1]: Fix the order of requests to go from source to destination. (Alex)
* [patch 7]: Use better wording in the documentation. (Evan)
* [patch 6]: Reorder struct members, sort nodes alphabetically, improve naming
  of variables , add missing clk_disable_unprepare() in error paths. (Matthias)
* [patch 6]: Remove redundant NULL pointer check in msm8916 driver. (Alex)
* [patch 6]: Add missing depend on QCOM_SMD_RPM in Kconfig. (Evan)
* [patch 3]: Don't check for errors on debugfs calls, remove debugfs directory
  when module is unloaded (Greg)

Changes since patchset v5 (https://lkml.org/lkml/2018/6/20/453)
* Fix the modular build, make rpm-smd driver a module.
* Optimize locking and move to higher level. (Evan)
* Code cleanups. Fix typos. (Evan, Matthias)
* Add the source node to the path. (Evan)
* Rename path_allocate() to path_init() with minor refactoring. (Evan)
* Rename *_remove() functions to *_destroy().
* Return fixed errors in icc_link_destroy(). (Evan)
* Fix krealloc() usage in icc_link_destroy(). (Evan)
* Add missing kfree() in icc_node_create(). (Matthias)
* Make icc_node_add() return void. (Matthias)
* Change mutex_init to mutex_lock in icc_provider_add(). (Matthias)
* Add new icc_node_del() function to delete nodes from provider.
* Fix the header guard to reflect the path in smd-rpm.h. (Evan)
* Check for errors returned by qcom_icc_rpm_smd_send(). (Evan)
* Propagate the error of icc_provider_del(). (Evan)

Changes since patchset v4 (https://lkml.org/lkml/2018/3/9/856)
* Simplified locking by using a single global mutex. (Evan)
* Changed the aggregation function interface.
* Implemented functions for node, link, provider removal. (Evan)
* Naming changes on variables and functions, removed redundant code. (Evan)
* Fixes and clarifications in the docs. (Matthias, Evan, Amit, Alexandre)
* Removed mandatory reg DT property, made interconnect-names optional. (Bjorn)
* Made interconnect-cells property required to align with other bindings. (Neil)
* Moved msm8916 specific bindings into a separate file and patch. (Bjorn)
* Use the names, instead of the hardcoded ids for topology. (Matthias)
* Init the node before creating the links. (Evan)
* Added icc_units_to_bps macro. (Amit)

Changes since patchset v3 (https://lkml.org/lkml/2017/9/8/544)
* Refactored the constraints aggregation.
* Use the IDR API.
* Split the provider and consumer bindings into separate patches and propose
  new bindings for consumers, which allows to specify the local source port.
* Adopted the icc_ prefix for API functions.
* Introduced separate API functions for creating interconnect nodes and links.
* Added DT lookup support in addition to platform data.
* Dropped the event tracing patch for now.
* Added a patch to provide summary via debugfs.
* Use macro for the list of topology definitions in the platform driver.
* Various minor changes.

Changes since patchset v2 (https://lkml.org/lkml/2017/7/20/825)
* Split the aggregation into per node and per provider. Cache the
  aggregated values.
* Various small refactorings and cleanups in the framework.
* Added a patch introducing basic tracepoint support for monitoring
  the time required to update the interconnect nodes.

Changes since patchset v1 (https://lkml.org/lkml/2017/6/27/890)
* Updates in the documentation.
* Changes in request aggregation, locking.
* Dropped the aggregate() callback and use the default as it currently
  sufficient for the single vendor driver. Will add it later when needed.
* Dropped the dt-bindings draft patch for now.

Changes since RFC v2 (https://lkml.org/lkml/2017/6/12/316)
* Converted documentation to rst format.
* Fixed an incorrect call to mutex_lock. Renamed max_bw to peak_bw.

Changes since RFC v1 (https://lkml.org/lkml/2017/5/15/605)
* Refactored code into shorter functions.
* Added a new aggregate() API function.
* Rearranged some structs to reduce padding bytes.

Changes since RFC v0 (https://lkml.org/lkml/2017/3/1/599)
* Removed DT support and added optional Patch 3 with new bindings proposal.
* Converted the topology into internal driver data.
* Made the framework modular.
* interconnect_get() now takes (src and dst ports as arguments).
* Removed public declarations of some structs.
* Now passing prev/next nodes to the vendor driver.
* Properly remove requests on _put().
* Added refcounting.
* Updated documentation.
* Changed struct interconnect_path to use array instead of linked list.

David Dai (2):
  interconnect: qcom: Add sdm845 interconnect provider driver
  arm64: dts: sdm845: Add interconnect provider DT nodes

Georgi Djakov (5):
  interconnect: Add generic on-chip interconnect API
  dt-bindings: Introduce interconnect binding
  interconnect: Allow endpoints translation via DT
  interconnect: Add debugfs support
  MAINTAINERS: add a maintainer for the interconnect API

 .../bindings/interconnect/interconnect.txt    |  60 ++
 .../bindings/interconnect/qcom,sdm845.txt     |  24 +
 Documentation/interconnect/interconnect.rst   |  94 ++
 MAINTAINERS                                   |  10 +
 arch/arm64/boot/dts/qcom/sdm845.dtsi          |   5 +
 drivers/Kconfig                               |   2 +
 drivers/Makefile                              |   1 +
 drivers/interconnect/Kconfig                  |  15 +
 drivers/interconnect/Makefile                 |   6 +
 drivers/interconnect/core.c                   | 796 +++++++++++++++++
 drivers/interconnect/qcom/Kconfig             |  13 +
 drivers/interconnect/qcom/Makefile            |   5 +
 drivers/interconnect/qcom/sdm845.c            | 836 ++++++++++++++++++
 .../dt-bindings/interconnect/qcom,sdm845.h    | 143 +++
 include/linux/interconnect-provider.h         | 142 +++
 include/linux/interconnect.h                  |  58 ++
 16 files changed, 2210 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/interconnect/interconnect.txt
 create mode 100644 Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt
 create mode 100644 Documentation/interconnect/interconnect.rst
 create mode 100644 drivers/interconnect/Kconfig
 create mode 100644 drivers/interconnect/Makefile
 create mode 100644 drivers/interconnect/core.c
 create mode 100644 drivers/interconnect/qcom/Kconfig
 create mode 100644 drivers/interconnect/qcom/Makefile
 create mode 100644 drivers/interconnect/qcom/sdm845.c
 create mode 100644 include/dt-bindings/interconnect/qcom,sdm845.h
 create mode 100644 include/linux/interconnect-provider.h
 create mode 100644 include/linux/interconnect.h

On Tue, 2018-11-27 at 20:03 +0200, Georgi Djakov wrote:
> This patch introduces a new API to get requirements and configure the
> interconnect buses across the entire chipset to fit with the current
> demand.

trivial notes:

> diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
[]
> +static int apply_constraints(struct icc_path *path)
> +{
> +	struct icc_node *next, *prev = NULL;
> +	int ret = -EINVAL;
> +	int i;
> +
> +	for (i = 0; i < path->num_nodes; i++, prev = next) {
> +		struct icc_provider *p;
> +
> +		next = path->reqs[i].node;
> +		/*
> +		 * Both endpoints should be valid master-slave pairs of the
> +		 * same interconnect provider that will be configured.
> +		 */
> +		if (!prev || next->provider != prev->provider)
> +			continue;
> +
> +		p = next->provider;
> +
> +		/* set the constraints */
> +		ret = p->set(prev, next);
> +		if (ret)
> +			goto out;
> +	}
> +out:
> +	return ret;
> +}

The use of ", prev = next" appears somewhat tricky code.
Perhaps move the assignment of prev to the bottom of the loop.
Perhaps the temporary p assignment isn't useful either.

> +int icc_set(struct icc_path *path, u32 avg_bw, u32 peak_bw)
> +{
[]
> +	ret = apply_constraints(path);
> +	if (ret)
> +		pr_debug("interconnect: error applying constraints (%d)", ret);

Ideally all pr_<foo> formats should end in '\n'

> +static struct icc_node *icc_node_create_nolock(int id)
> +{
> +	struct icc_node *node;
> +
> +	/* check if node already exists */
> +	node = node_find(id);
> +	if (node)
> +		goto out;
> +
> +	node = kzalloc(sizeof(*node), GFP_KERNEL);
> +	if (!node) {
> +		node = ERR_PTR(-ENOMEM);
> +		goto out;

Generally, this code appears to overly rely on goto when
direct returns could be more readable.

> +	}
> +
> +	id = idr_alloc(&icc_idr, node, id, id + 1, GFP_KERNEL);
> +	if (WARN(id < 0, "couldn't get idr")) {

This seems to unnecessarily hide the id < 0 test in a WARN

Why is this a WARN and not a simpler
	if (id < 0) {
		[ pr_err(...); or WARN(1, ...); ]

> +		kfree(node);
> +		node = ERR_PTR(id);
> +		goto out;
> +	}
> +
> +	node->id = id;
> +
> +out:
> +	return node;
> +}
[]
> diff --git a/include/linux/interconnect.h b/include/linux/interconnect.h
[]
> +/* macros for converting to icc units */
> +#define bps_to_icc(x)	(1)
> +#define kBps_to_icc(x)	(x)
[]
> +#define MBps_to_icc(x)	(x * 1000)
> +#define GBps_to_icc(x)	(x * 1000 * 1000)
> +#define kbps_to_icc(x)	(x / 8 + ((x) % 8 ? 1 : 0))
> +#define Mbps_to_icc(x)	(x * 1000 / 8 )
> +#define Gbps_to_icc(x)	(x * 1000 * 1000 / 8)

The last 5 macros should parenthesize x

Hi Joe,

On 11/27/18 20:35, Joe Perches wrote:
> On Tue, 2018-11-27 at 20:03 +0200, Georgi Djakov wrote:
>> This patch introduces a new API to get requirements and configure the
>> interconnect buses across the entire chipset to fit with the current
>> demand.
> 
> trivial notes:
> 
>> diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
> []
>> +static int apply_constraints(struct icc_path *path)
>> +{
>> +	struct icc_node *next, *prev = NULL;
>> +	int ret = -EINVAL;
>> +	int i;
>> +
>> +	for (i = 0; i < path->num_nodes; i++, prev = next) {
>> +		struct icc_provider *p;
>> +
>> +		next = path->reqs[i].node;
>> +		/*
>> +		 * Both endpoints should be valid master-slave pairs of the
>> +		 * same interconnect provider that will be configured.
>> +		 */
>> +		if (!prev || next->provider != prev->provider)
>> +			continue;
>> +
>> +		p = next->provider;
>> +
>> +		/* set the constraints */
>> +		ret = p->set(prev, next);
>> +		if (ret)
>> +			goto out;
>> +	}
>> +out:
>> +	return ret;
>> +}
> 
> The use of ", prev = next" appears somewhat tricky code.
> Perhaps move the assignment of prev to the bottom of the loop.
> Perhaps the temporary p assignment isn't useful either.
> 
>> +int icc_set(struct icc_path *path, u32 avg_bw, u32 peak_bw)
>> +{
> []
>> +	ret = apply_constraints(path);
>> +	if (ret)
>> +		pr_debug("interconnect: error applying constraints (%d)", ret);
> 
> Ideally all pr_<foo> formats should end in '\n'
> 
>> +static struct icc_node *icc_node_create_nolock(int id)
>> +{
>> +	struct icc_node *node;
>> +
>> +	/* check if node already exists */
>> +	node = node_find(id);
>> +	if (node)
>> +		goto out;
>> +
>> +	node = kzalloc(sizeof(*node), GFP_KERNEL);
>> +	if (!node) {
>> +		node = ERR_PTR(-ENOMEM);
>> +		goto out;
> 
> Generally, this code appears to overly rely on goto when
> direct returns could be more readable.
> 
>> +	}
>> +
>> +	id = idr_alloc(&icc_idr, node, id, id + 1, GFP_KERNEL);
>> +	if (WARN(id < 0, "couldn't get idr")) {
> 
> This seems to unnecessarily hide the id < 0 test in a WARN
> 
> Why is this a WARN and not a simpler
> 	if (id < 0) {
> 		[ pr_err(...); or WARN(1, ...); ]
> 
>> +		kfree(node);
>> +		node = ERR_PTR(id);
>> +		goto out;
>> +	}
>> +
>> +	node->id = id;
>> +
>> +out:
>> +	return node;
>> +}

Thank you for helping to improve the code. The above suggestions make it 
cleaner indeed.

> []
>> diff --git a/include/linux/interconnect.h b/include/linux/interconnect.h
> []
>> +/* macros for converting to icc units */
>> +#define bps_to_icc(x)	(1)
>> +#define kBps_to_icc(x)	(x)
> []
>> +#define MBps_to_icc(x)	(x * 1000)
>> +#define GBps_to_icc(x)	(x * 1000 * 1000)
>> +#define kbps_to_icc(x)	(x / 8 + ((x) % 8 ? 1 : 0))
>> +#define Mbps_to_icc(x)	(x * 1000 / 8 )
>> +#define Gbps_to_icc(x)	(x * 1000 * 1000 / 8)
> 
> The last 5 macros should parenthesize x

Oops.. obviously i forgot to run checkpatch --strict. Will fix!

BR,
Georgi

On Tue, Nov 27, 2018 at 10:03 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>
> 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 participating in the
> topology node according to the requested data flow path, physical links and

Strange word ordering. Consider something like: "Then the providers
configure each node participating in the topology"

...Or a slightly different flavor: "Then the providers configure each
node along the path to support a bandwidth that satisfies all
bandwidth requests that cross through that node".

> constraints. The topology could be complicated and multi-tiered and is SoC
> specific.
>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> Reviewed-by: Evan Green <evgreen@chromium.org>

This already has my reviewed by, and I still stand by it, but I
couldn't help finding some nits anyway. Sorry :)

> ---
>  Documentation/interconnect/interconnect.rst |  94 ++++
>  drivers/Kconfig                             |   2 +
>  drivers/Makefile                            |   1 +
>  drivers/interconnect/Kconfig                |  10 +
>  drivers/interconnect/Makefile               |   5 +
>  drivers/interconnect/core.c                 | 569 ++++++++++++++++++++
>  include/linux/interconnect-provider.h       | 125 +++++
>  include/linux/interconnect.h                |  51 ++
>  8 files changed, 857 insertions(+)
>  create mode 100644 Documentation/interconnect/interconnect.rst
>  create mode 100644 drivers/interconnect/Kconfig
>  create mode 100644 drivers/interconnect/Makefile
>  create mode 100644 drivers/interconnect/core.c
>  create mode 100644 include/linux/interconnect-provider.h
>  create mode 100644 include/linux/interconnect.h
>
...
> diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
> new file mode 100644
> index 000000000000..3ae8e5a58969
> --- /dev/null
> +++ b/drivers/interconnect/core.c
> @@ -0,0 +1,569 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Interconnect framework core driver
> + *
> + * Copyright (c) 2018, Linaro Ltd.
> + * Author: Georgi Djakov <georgi.djakov@linaro.org>
> + */
> +
> +#include <linux/device.h>
> +#include <linux/idr.h>
> +#include <linux/init.h>
> +#include <linux/interconnect.h>
> +#include <linux/interconnect-provider.h>
> +#include <linux/list.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/slab.h>
> +#include <linux/overflow.h>
> +
> +static DEFINE_IDR(icc_idr);
> +static LIST_HEAD(icc_providers);
> +static DEFINE_MUTEX(icc_lock);
> +
> +/**
> + * struct icc_req - constraints that are attached to each node
> + * @req_node: entry in list of requests for the particular @node
> + * @node: the interconnect node to which this constraint applies
> + * @dev: reference to the device that sets the constraints
> + * @avg_bw: an integer describing the average bandwidth in kBps
> + * @peak_bw: an integer describing the peak bandwidth in kBps
> + */
> +struct icc_req {
> +       struct hlist_node req_node;
> +       struct icc_node *node;
> +       struct device *dev;
> +       u32 avg_bw;
> +       u32 peak_bw;
> +};
> +
> +/**
> + * struct icc_path - interconnect path structure
> + * @num_nodes: number of hops (nodes)
> + * @reqs: array of the requests applicable to this path of nodes
> + */
> +struct icc_path {
> +       size_t num_nodes;
> +       struct icc_req reqs[];
> +};
> +
> +static struct icc_node *node_find(const int id)
> +{
> +       return idr_find(&icc_idr, id);
> +}
> +
> +static struct icc_path *path_init(struct device *dev, struct icc_node *dst,
> +                                 ssize_t num_nodes)
> +{
> +       struct icc_node *node = dst;
> +       struct icc_path *path;
> +       int i;
> +
> +       path = kzalloc(struct_size(path, reqs, num_nodes), GFP_KERNEL);
> +       if (!path)
> +               return ERR_PTR(-ENOMEM);
> +
> +       path->num_nodes = num_nodes;
> +
> +       for (i = num_nodes - 1; i >= 0; i--) {
> +               node->provider->users++;
> +               hlist_add_head(&path->reqs[i].req_node, &node->req_list);
> +               path->reqs[i].node = node;
> +               path->reqs[i].dev = dev;
> +               /* reference to previous node was saved during path traversal */
> +               node = node->reverse;
> +       }
> +
> +       return path;
> +}
> +
> +static struct icc_path *path_find(struct device *dev, struct icc_node *src,
> +                                 struct icc_node *dst)
> +{
> +       struct icc_path *path = ERR_PTR(-EPROBE_DEFER);
> +       struct icc_node *n, *node = NULL;
> +       struct list_head traverse_list;
> +       struct list_head edge_list;
> +       struct list_head visited_list;
> +       size_t i, depth = 1;
> +       bool found = false;
> +
> +       INIT_LIST_HEAD(&traverse_list);
> +       INIT_LIST_HEAD(&edge_list);
> +       INIT_LIST_HEAD(&visited_list);
> +
> +       list_add(&src->search_list, &traverse_list);
> +       src->reverse = NULL;
> +
> +       do {
> +               list_for_each_entry_safe(node, n, &traverse_list, search_list) {
> +                       if (node == dst) {
> +                               found = true;
> +                               list_splice_init(&edge_list, &visited_list);
> +                               list_splice_init(&traverse_list, &visited_list);
> +                               break;
> +                       }
> +                       for (i = 0; i < node->num_links; i++) {
> +                               struct icc_node *tmp = node->links[i];
> +
> +                               if (!tmp) {
> +                                       path = ERR_PTR(-ENOENT);
> +                                       goto out;
> +                               }
> +
> +                               if (tmp->is_traversed)
> +                                       continue;
> +
> +                               tmp->is_traversed = true;
> +                               tmp->reverse = node;
> +                               list_add_tail(&tmp->search_list, &edge_list);
> +                       }
> +               }
> +
> +               if (found)
> +                       break;
> +
> +               list_splice_init(&traverse_list, &visited_list);
> +               list_splice_init(&edge_list, &traverse_list);
> +
> +               /* count the hops including the source */
> +               depth++;
> +
> +       } while (!list_empty(&traverse_list));
> +
> +out:
> +
> +       /* reset the traversed state */
> +       list_for_each_entry_reverse(n, &visited_list, search_list)
> +               n->is_traversed = false;
> +
> +       if (found)
> +               path = path_init(dev, dst, depth);
> +
> +       return path;
> +}
> +
> +/*
> + * We want the path to honor all bandwidth requests, so the average and peak
> + * bandwidth requirements from each consumer are aggregated at each node.
> + * The aggregation is platform specific, so each platform can customize it by
> + * implementing it's own aggregate() function.

Grammar police: remove the apostrophe in its.

> + */
> +
> +static int aggregate_requests(struct icc_node *node)
> +{
> +       struct icc_provider *p = node->provider;
> +       struct icc_req *r;
> +
> +       node->avg_bw = 0;
> +       node->peak_bw = 0;
> +
> +       hlist_for_each_entry(r, &node->req_list, req_node)
> +               p->aggregate(node, r->avg_bw, r->peak_bw,
> +                            &node->avg_bw, &node->peak_bw);
> +
> +       return 0;
> +}
> +
> +static int apply_constraints(struct icc_path *path)
> +{
> +       struct icc_node *next, *prev = NULL;
> +       int ret = -EINVAL;
> +       int i;
> +
> +       for (i = 0; i < path->num_nodes; i++, prev = next) {
> +               struct icc_provider *p;
> +
> +               next = path->reqs[i].node;
> +               /*
> +                * Both endpoints should be valid master-slave pairs of the
> +                * same interconnect provider that will be configured.
> +                */
> +               if (!prev || next->provider != prev->provider)
> +                       continue;

I wonder if we should explicitly ban paths where we bounce through an
odd number of nodes within one provider. Otherwise, set() won't be
called on all nodes in the path. Or, if we wanted to support those
kinds of topologies, you could call set with one of the nodes set to
NULL to represent either the ingress or egress bandwidth to this NoC.
This doesn't necessarily need to be addressed in this series, but is
something that other providers might bump into when implementing their
topologies.

> +
> +               p = next->provider;
> +
> +               /* set the constraints */
> +               ret = p->set(prev, next);
> +               if (ret)
> +                       goto out;
> +       }
> +out:
> +       return ret;
> +}
> +
...
> +
> +/**
> + * icc_link_destroy() - destroy a link between two nodes
> + * @src: pointer to source node
> + * @dst: pointer to destination node
> + *
> + * Return: 0 on success, or an error code otherwise
> + */
> +int icc_link_destroy(struct icc_node *src, struct icc_node *dst)
> +{
> +       struct icc_node **new;
> +       size_t slot;
> +       int ret = 0;
> +
> +       if (IS_ERR_OR_NULL(src))
> +               return -EINVAL;
> +
> +       if (IS_ERR_OR_NULL(dst))
> +               return -EINVAL;
> +
> +       mutex_lock(&icc_lock);
> +
> +       for (slot = 0; slot < src->num_links; slot++)
> +               if (src->links[slot] == dst)
> +                       break;
> +
> +       if (WARN_ON(slot == src->num_links)) {
> +               ret = -ENXIO;
> +               goto out;
> +       }
> +
> +       src->links[slot] = src->links[--src->num_links];
> +
> +       new = krealloc(src->links,
> +                      (src->num_links) * sizeof(*src->links),

These parentheses aren't needed.

> +                      GFP_KERNEL);
> +       if (new)
> +               src->links = new;
> +
> +out:
> +       mutex_unlock(&icc_lock);
> +
> +       return ret;
> +}
> +EXPORT_SYMBOL_GPL(icc_link_destroy);
> +
> +/**
> + * icc_node_add() - add interconnect node to interconnect provider
> + * @node: pointer to the interconnect node
> + * @provider: pointer to the interconnect provider
> + */
> +void icc_node_add(struct icc_node *node, struct icc_provider *provider)
> +{
> +       mutex_lock(&icc_lock);
> +
> +       node->provider = provider;
> +       list_add_tail(&node->node_list, &provider->nodes);
> +
> +       mutex_unlock(&icc_lock);
> +}
> +EXPORT_SYMBOL_GPL(icc_node_add);
> +
> +/**
> + * icc_node_del() - delete interconnect node from interconnect provider
> + * @node: pointer to the interconnect node
> + */
> +void icc_node_del(struct icc_node *node)
> +{
> +       mutex_lock(&icc_lock);
> +
> +       list_del(&node->node_list);
> +
> +       mutex_unlock(&icc_lock);
> +}
> +EXPORT_SYMBOL_GPL(icc_node_del);
> +
> +/**
> + * icc_provider_add() - add a new interconnect provider
> + * @provider: the interconnect provider that will be added into topology
> + *
> + * Return: 0 on success, or an error code otherwise
> + */
> +int icc_provider_add(struct icc_provider *provider)
> +{
> +       if (WARN_ON(!provider->set))
> +               return -EINVAL;
> +
> +       mutex_lock(&icc_lock);
> +
> +       INIT_LIST_HEAD(&provider->nodes);
> +       list_add_tail(&provider->provider_list, &icc_providers);
> +
> +       mutex_unlock(&icc_lock);
> +
> +       dev_dbg(provider->dev, "interconnect provider added to topology\n");
> +
> +       return 0;
> +}
> +EXPORT_SYMBOL_GPL(icc_provider_add);
> +
> +/**
> + * icc_provider_del() - delete previously added interconnect provider
> + * @provider: the interconnect provider that will be removed from topology
> + *
> + * Return: 0 on success, or an error code otherwise
> + */
> +int icc_provider_del(struct icc_provider *provider)
> +{
> +       mutex_lock(&icc_lock);
> +       if (provider->users) {
> +               pr_warn("interconnect provider still has %d users\n",
> +                       provider->users);
> +               mutex_unlock(&icc_lock);
> +               return -EBUSY;
> +       }
> +
> +       if (!list_empty(&provider->nodes)) {
> +               pr_warn("interconnect provider still has nodes\n");
> +               mutex_unlock(&icc_lock);
> +               return -EBUSY;
> +       }
> +
> +       list_del(&provider->provider_list);
> +       mutex_unlock(&icc_lock);
> +
> +       return 0;
> +}
> +EXPORT_SYMBOL_GPL(icc_provider_del);
> +
> +MODULE_AUTHOR("Georgi Djakov <georgi.djakov@linaro.org");

This is missing the closing >

> +MODULE_DESCRIPTION("Interconnect Driver Core");
> +MODULE_LICENSE("GPL v2");
...
> diff --git a/include/linux/interconnect.h b/include/linux/interconnect.h
> new file mode 100644
> index 000000000000..04b2966ded9f
> --- /dev/null
> +++ b/include/linux/interconnect.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2018, Linaro Ltd.
> + * Author: Georgi Djakov <georgi.djakov@linaro.org>
> + */
> +
> +#ifndef __LINUX_INTERCONNECT_H
> +#define __LINUX_INTERCONNECT_H
> +
> +#include <linux/mutex.h>
> +#include <linux/types.h>
> +
> +/* macros for converting to icc units */
> +#define bps_to_icc(x)  (1)
> +#define kBps_to_icc(x) (x)
> +#define MBps_to_icc(x) (x * 1000)
> +#define GBps_to_icc(x) (x * 1000 * 1000)
> +#define kbps_to_icc(x) (x / 8 + ((x) % 8 ? 1 : 0))
> +#define Mbps_to_icc(x) (x * 1000 / 8 )

Remove extra space before )

> +#define Gbps_to_icc(x) (x * 1000 * 1000 / 8)
> +
> +struct icc_path;
> +struct device;
> +
> +#if IS_ENABLED(CONFIG_INTERCONNECT)
> +
> +struct icc_path *icc_get(struct device *dev, const int src_id,
> +                        const int dst_id);
> +void icc_put(struct icc_path *path);
> +int icc_set(struct icc_path *path, u32 avg_bw, u32 peak_bw);
> +
> +#else
> +
> +static inline struct icc_path *icc_get(struct device *dev, const int src_id,
> +                                      const int dst_id)
> +{
> +       return NULL;
> +}
> +
> +static inline void icc_put(struct icc_path *path)
> +{
> +}
> +
> +static inline int icc_set(struct icc_path *path, u32 avg_bw, u32 peak_bw)
> +{
> +       return 0;

Should this really succeed?

> +}
> +
> +#endif /* CONFIG_INTERCONNECT */
> +
> +#endif /* __LINUX_INTERCONNECT_H */

On Tue, Nov 27, 2018 at 10:04 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>
> 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.
>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
>  drivers/interconnect/core.c           | 156 ++++++++++++++++++++++++++
>  include/linux/interconnect-provider.h |  17 +++
>  include/linux/interconnect.h          |   7 ++
>  3 files changed, 180 insertions(+)
>
> diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
> index 3ae8e5a58969..ebc42ef9fa46 100644
> --- a/drivers/interconnect/core.c
> +++ b/drivers/interconnect/core.c
> @@ -15,6 +15,7 @@
>  #include <linux/module.h>
>  #include <linux/mutex.h>
>  #include <linux/slab.h>
> +#include <linux/of.h>
>  #include <linux/overflow.h>
>
>  static DEFINE_IDR(icc_idr);
> @@ -193,6 +194,159 @@ static int apply_constraints(struct icc_path *path)
>         return ret;
>  }
>
> +/* of_icc_xlate_onecell() - Xlate function using a single index.

It would be nice if translate were spelled out instead of xlate in the
description portion (throughout).

> + * @spec: OF phandle args to map into an interconnect node.
> + * @data: private data (pointer to struct icc_onecell_data)
> + *
> + * This is a generic xlate function that can be used to model simple
> + * interconnect providers that have one device tree node and provide
> + * multiple interconnect nodes. A single cell is used as an index into
> + * an array of icc nodes specified in the icc_onecell_data struct when
> + * registering the provider.
> + */
> +struct icc_node *of_icc_xlate_onecell(struct of_phandle_args *spec,
> +                                     void *data)
> +{
> +       struct icc_onecell_data *icc_data = data;
> +       unsigned int idx = spec->args[0];
> +
> +       if (idx >= icc_data->num_nodes) {
> +               pr_err("%s: invalid index %u\n", __func__, idx);
> +               return ERR_PTR(-EINVAL);
> +       }
> +
> +       return icc_data->nodes[idx];
> +}
> +EXPORT_SYMBOL_GPL(of_icc_xlate_onecell);
> +
> +/**
> + * of_icc_get_from_provider() - Look-up interconnect node
> + * @spec: OF phandle args to use for look-up
> + *
> + * Looks for interconnect provider under the node specified by @spec and if
> + * found, uses xlate function of the provider to map phandle args to node.
> + *
> + * Returns a valid pointer to struct icc_node on success or ERR_PTR()
> + * on failure.
> + */
> +static struct icc_node *of_icc_get_from_provider(struct of_phandle_args *spec)
> +{
> +       struct icc_node *node = ERR_PTR(-EPROBE_DEFER);
> +       struct icc_provider *provider;
> +
> +       if (!spec)
> +               return ERR_PTR(-EINVAL);
> +
> +       mutex_lock(&icc_lock);
> +       list_for_each_entry(provider, &icc_providers, provider_list) {
> +               if (provider->dev->of_node == spec->np)
> +                       node = provider->xlate(spec, provider->data);
> +               if (!IS_ERR(node))
> +                       break;
> +       }
> +       mutex_unlock(&icc_lock);
> +
> +       return node;
> +}
> +
> +/**
> + * of_icc_get() - get a path handle from a DT node based on name
> + * @dev: device pointer for the consumer device
> + * @name: interconnect path name
> + *
> + * This function will search for a path two endpoints and return an

path between two endpoints

> + * icc_path handle on success. Use icc_put() to release constraints when
> + * they are not needed anymore.
> + * If the interconnect API is disabled, NULL is returned and the consumer
> + * drivers will still build. Drivers are free to handle this specifically,
> + * but they don't have to. NULL is also returned when the "interconnects"

I'm not sure the sentence starting with "Drivers are free" adds much.
Also, you mention that null is returned when the interconnect API is
disabled both above and below. We probably only need it once.

> + * DT property is missing.
> + *
> + * Return: icc_path pointer on success or ERR_PTR() on error. NULL is returned
> + * when the API is disabled or the "interconnects" DT property is missing.
> + */
> +struct icc_path *of_icc_get(struct device *dev, const char *name)
> +{
> +       struct icc_path *path = ERR_PTR(-EPROBE_DEFER);
> +       struct icc_node *src_node, *dst_node;
> +       struct device_node *np = NULL;
> +       struct of_phandle_args src_args, dst_args;
> +       int idx = 0;
> +       int ret;
> +
> +       if (!dev || !dev->of_node)
> +               return ERR_PTR(-ENODEV);
> +
> +       np = dev->of_node;
> +
> +       /*
> +        * When the consumer DT node do not have "interconnects" property
> +        * return a NULL path to skip setting constraints.
> +        */
> +       if (!of_find_property(np, "interconnects", NULL))
> +               return NULL;
> +
> +       /*
> +        * We use a combination of phandle and specifier for endpoint. For now
> +        * lets support only global ids and extend this is the future if needed

s/is the future/in the future/

> +        * without breaking DT compatibility.
> +        */
> +       if (name) {
> +               idx = of_property_match_string(np, "interconnect-names", name);
> +               if (idx < 0)
> +                       return ERR_PTR(idx);
> +       }
> +
> +       ret = of_parse_phandle_with_args(np, "interconnects",
> +                                        "#interconnect-cells", idx * 2,
> +                                        &src_args);
> +       if (ret)
> +               return ERR_PTR(ret);
> +
> +       of_node_put(src_args.np);
> +
> +       if (!src_args.args_count || src_args.args_count > 1)

This could be src_args.argc_count != 1

> +               return ERR_PTR(-EINVAL);
> +
> +       ret = of_parse_phandle_with_args(np, "interconnects",
> +                                        "#interconnect-cells", idx * 2 + 1,
> +                                        &dst_args);
> +       if (ret)
> +               return ERR_PTR(ret);
> +
> +       of_node_put(dst_args.np);
> +
> +       if (!dst_args.args_count || dst_args.args_count > 1)

Similarly, this could be dst_args.args_count != 1

> +               return ERR_PTR(-EINVAL);
> +
> +       src_node = of_icc_get_from_provider(&src_args);
> +
> +       if (IS_ERR(src_node)) {
> +               if (PTR_ERR(src_node) != -EPROBE_DEFER)
> +                       dev_err(dev, "error finding src node: %ld\n",
> +                               PTR_ERR(src_node));
> +               return ERR_CAST(src_node);
> +       }
> +
> +       dst_node = of_icc_get_from_provider(&dst_args);
> +
> +       if (IS_ERR(dst_node)) {
> +               if (PTR_ERR(dst_node) != -EPROBE_DEFER)
> +                       dev_err(dev, "error finding dst node: %ld\n",
> +                               PTR_ERR(dst_node));
> +               return ERR_CAST(dst_node);
> +       }
> +
> +       mutex_lock(&icc_lock);
> +       path = path_find(dev, src_node, dst_node);
> +       if (IS_ERR(path))
> +               dev_err(dev, "%s: invalid path=%ld\n", __func__, PTR_ERR(path));
> +       mutex_unlock(&icc_lock);
> +
> +       return path;
> +}
> +EXPORT_SYMBOL_GPL(of_icc_get);
> +
>  /**
>   * icc_set() - set constraints on an interconnect path between two endpoints
>   * @path: reference to the path returned by icc_get()
> @@ -521,6 +675,8 @@ int icc_provider_add(struct icc_provider *provider)
>  {
>         if (WARN_ON(!provider->set))
>                 return -EINVAL;
> +       if (WARN_ON(!provider->xlate))
> +               return -EINVAL;
>
>         mutex_lock(&icc_lock);
>
> diff --git a/include/linux/interconnect-provider.h b/include/linux/interconnect-provider.h
> index 78208a754181..63caccadc2db 100644
> --- a/include/linux/interconnect-provider.h
> +++ b/include/linux/interconnect-provider.h
> @@ -12,6 +12,21 @@
>  #define icc_units_to_bps(bw)  ((bw) * 1000ULL)
>
>  struct icc_node;
> +struct of_phandle_args;
> +
> +/**
> + * struct icc_onecell_data - driver data for onecell interconnect providers
> + *
> + * @num_nodes: number of nodes in this device
> + * @nodes: array of pointers to the nodes in this device
> + */
> +struct icc_onecell_data {
> +       unsigned int num_nodes;
> +       struct icc_node *nodes[];
> +};
> +
> +struct icc_node *of_icc_xlate_onecell(struct of_phandle_args *spec,
> +                                     void *data);
>
>  /**
>   * struct icc_provider - interconnect provider (controller) entity that might
> @@ -21,6 +36,7 @@ struct icc_node;
>   * @nodes: internal list of the interconnect provider nodes
>   * @set: pointer to device specific set operation function
>   * @aggregate: pointer to device specific aggregate operation function
> + * @xlate: provider-specific callback for mapping nodes from phandle arguments
>   * @dev: the device this interconnect provider belongs to
>   * @users: count of active users
>   * @data: pointer to private data
> @@ -31,6 +47,7 @@ struct icc_provider {
>         int (*set)(struct icc_node *src, struct icc_node *dst);
>         int (*aggregate)(struct icc_node *node, u32 avg_bw, u32 peak_bw,
>                          u32 *agg_avg, u32 *agg_peak);
> +       struct icc_node* (*xlate)(struct of_phandle_args *spec, void *data);
>         struct device           *dev;
>         int                     users;
>         void                    *data;
> diff --git a/include/linux/interconnect.h b/include/linux/interconnect.h
> index 04b2966ded9f..41f7ecc2f20f 100644
> --- a/include/linux/interconnect.h
> +++ b/include/linux/interconnect.h
> @@ -26,6 +26,7 @@ struct device;
>
>  struct icc_path *icc_get(struct device *dev, const int src_id,
>                          const int dst_id);
> +struct icc_path *of_icc_get(struct device *dev, const char *name);
>  void icc_put(struct icc_path *path);
>  int icc_set(struct icc_path *path, u32 avg_bw, u32 peak_bw);
>
> @@ -37,6 +38,12 @@ static inline struct icc_path *icc_get(struct device *dev, const int src_id,
>         return NULL;
>  }
>
> +static inline struct icc_path *of_icc_get(struct device *dev,
> +                                         const char *name)
> +{
> +       return NULL;
> +}
> +
>  static inline void icc_put(struct icc_path *path)
>  {
>  }

With these nits fixed:

Reviewed-by: Evan Green <evgreen@chromium.org>

On Tue, Nov 27, 2018 at 10:04 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>
> From: David Dai <daidavid1@codeaurora.org>
>
> Add RSC (Resource State Coordinator) provider
> dictating network-on-chip interconnect bus performance
> found on SDM845-based platforms.
>
> Signed-off-by: David Dai <daidavid1@codeaurora.org>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index b72bdb0a31a5..856d33604e9c 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -1324,6 +1324,11 @@
>                                 compatible = "qcom,sdm845-rpmh-clk";
>                                 #clock-cells = <1>;
>                         };
> +
> +                       qnoc: qnoc {
> +                               compatible = "qcom,sdm845-rsc-hlos";
> +                               #interconnect-cells = <1>;
> +                       };

Should we alphabetize this node above rpmhcc?

>                 };
>
>                 intc: interrupt-controller@17a00000 {

Hi Evan,

On 12/1/18 02:38, Evan Green wrote:
> On Tue, Nov 27, 2018 at 10:03 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>
>> 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 participating in the
>> topology node according to the requested data flow path, physical links and
> 
> Strange word ordering. Consider something like: "Then the providers
> configure each node participating in the topology"
> 
> ...Or a slightly different flavor: "Then the providers configure each
> node along the path to support a bandwidth that satisfies all
> bandwidth requests that cross through that node".
> 

This sounds better!

>> constraints. The topology could be complicated and multi-tiered and is SoC
>> specific.
>>
>> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
>> Reviewed-by: Evan Green <evgreen@chromium.org>
> 
> This already has my reviewed by, and I still stand by it, but I
> couldn't help finding some nits anyway. Sorry :)

Thanks for finding them!

>> ---
>>  Documentation/interconnect/interconnect.rst |  94 ++++
>>  drivers/Kconfig                             |   2 +
>>  drivers/Makefile                            |   1 +
>>  drivers/interconnect/Kconfig                |  10 +
>>  drivers/interconnect/Makefile               |   5 +
>>  drivers/interconnect/core.c                 | 569 ++++++++++++++++++++
>>  include/linux/interconnect-provider.h       | 125 +++++
>>  include/linux/interconnect.h                |  51 ++
>>  8 files changed, 857 insertions(+)
>>  create mode 100644 Documentation/interconnect/interconnect.rst
>>  create mode 100644 drivers/interconnect/Kconfig
>>  create mode 100644 drivers/interconnect/Makefile
>>  create mode 100644 drivers/interconnect/core.c
>>  create mode 100644 include/linux/interconnect-provider.h
>>  create mode 100644 include/linux/interconnect.h
>>
[..]
>> +/*
>> + * We want the path to honor all bandwidth requests, so the average and peak
>> + * bandwidth requirements from each consumer are aggregated at each node.
>> + * The aggregation is platform specific, so each platform can customize it by
>> + * implementing it's own aggregate() function.
> 
> Grammar police: remove the apostrophe in its.
> 

Oops.

>> + */
>> +
>> +static int aggregate_requests(struct icc_node *node)
>> +{
>> +       struct icc_provider *p = node->provider;
>> +       struct icc_req *r;
>> +
>> +       node->avg_bw = 0;
>> +       node->peak_bw = 0;
>> +
>> +       hlist_for_each_entry(r, &node->req_list, req_node)
>> +               p->aggregate(node, r->avg_bw, r->peak_bw,
>> +                            &node->avg_bw, &node->peak_bw);
>> +
>> +       return 0;
>> +}
>> +
>> +static int apply_constraints(struct icc_path *path)
>> +{
>> +       struct icc_node *next, *prev = NULL;
>> +       int ret = -EINVAL;
>> +       int i;
>> +
>> +       for (i = 0; i < path->num_nodes; i++, prev = next) {
>> +               struct icc_provider *p;
>> +
>> +               next = path->reqs[i].node;
>> +               /*
>> +                * Both endpoints should be valid master-slave pairs of the
>> +                * same interconnect provider that will be configured.
>> +                */
>> +               if (!prev || next->provider != prev->provider)
>> +                       continue;
> 
> I wonder if we should explicitly ban paths where we bounce through an
> odd number of nodes within one provider. Otherwise, set() won't be
> called on all nodes in the path. Or, if we wanted to support those
> kinds of topologies, you could call set with one of the nodes set to
> NULL to represent either the ingress or egress bandwidth to this NoC.
> This doesn't necessarily need to be addressed in this series, but is
> something that other providers might bump into when implementing their
> topologies.
> 

Yes, we can do something like this. But i prefer that we first add
support for more platforms and then according to the requirements we can
work out something.

[..]

>> +       new = krealloc(src->links,
>> +                      (src->num_links) * sizeof(*src->links),
> 
> These parentheses aren't needed.

Sure!

>> +                      GFP_KERNEL);
>> +       if (new)
>> +               src->links = new;
>> +

[..]

>> +
>> +MODULE_AUTHOR("Georgi Djakov <georgi.djakov@linaro.org");
> 
> This is missing the closing >

Thanks!

>> +MODULE_DESCRIPTION("Interconnect Driver Core");
>> +MODULE_LICENSE("GPL v2");
> ...
>> diff --git a/include/linux/interconnect.h b/include/linux/interconnect.h
>> new file mode 100644
>> index 000000000000..04b2966ded9f
>> --- /dev/null
>> +++ b/include/linux/interconnect.h
>> @@ -0,0 +1,51 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Copyright (c) 2018, Linaro Ltd.
>> + * Author: Georgi Djakov <georgi.djakov@linaro.org>
>> + */
>> +
>> +#ifndef __LINUX_INTERCONNECT_H
>> +#define __LINUX_INTERCONNECT_H
>> +
>> +#include <linux/mutex.h>
>> +#include <linux/types.h>
>> +
>> +/* macros for converting to icc units */
>> +#define bps_to_icc(x)  (1)
>> +#define kBps_to_icc(x) (x)
>> +#define MBps_to_icc(x) (x * 1000)
>> +#define GBps_to_icc(x) (x * 1000 * 1000)
>> +#define kbps_to_icc(x) (x / 8 + ((x) % 8 ? 1 : 0))
>> +#define Mbps_to_icc(x) (x * 1000 / 8 )
> 
> Remove extra space before )

Done.

>> +#define Gbps_to_icc(x) (x * 1000 * 1000 / 8)
>> +
>> +struct icc_path;
>> +struct device;
>> +
>> +#if IS_ENABLED(CONFIG_INTERCONNECT)
>> +
>> +struct icc_path *icc_get(struct device *dev, const int src_id,
>> +                        const int dst_id);
>> +void icc_put(struct icc_path *path);
>> +int icc_set(struct icc_path *path, u32 avg_bw, u32 peak_bw);
>> +
>> +#else
>> +
>> +static inline struct icc_path *icc_get(struct device *dev, const int src_id,
>> +                                      const int dst_id)
>> +{
>> +       return NULL;
>> +}
>> +
>> +static inline void icc_put(struct icc_path *path)
>> +{
>> +}
>> +
>> +static inline int icc_set(struct icc_path *path, u32 avg_bw, u32 peak_bw)
>> +{
>> +       return 0;
> 
> Should this really succeed?

Yes, it should succeed if the framework is not enabled. The drivers
should handle the case of whether the framework is enabled or not when
icc_get() or of_icc_get() returns NULL. Based on that they should decide
if can continue without interconnect support or not.

BR,
Georgi

Hi Evan,

On 12/1/18 02:38, Evan Green wrote:
> On Tue, Nov 27, 2018 at 10:04 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>
>> 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.
>>
>> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
>> ---
>>  drivers/interconnect/core.c           | 156 ++++++++++++++++++++++++++
>>  include/linux/interconnect-provider.h |  17 +++
>>  include/linux/interconnect.h          |   7 ++
>>  3 files changed, 180 insertions(+)
>>
>> diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
>> index 3ae8e5a58969..ebc42ef9fa46 100644
>> --- a/drivers/interconnect/core.c
>> +++ b/drivers/interconnect/core.c
>> @@ -15,6 +15,7 @@
>>  #include <linux/module.h>
>>  #include <linux/mutex.h>
>>  #include <linux/slab.h>
>> +#include <linux/of.h>
>>  #include <linux/overflow.h>
>>
>>  static DEFINE_IDR(icc_idr);
>> @@ -193,6 +194,159 @@ static int apply_constraints(struct icc_path *path)
>>         return ret;
>>  }
>>
>> +/* of_icc_xlate_onecell() - Xlate function using a single index.
> 
> It would be nice if translate were spelled out instead of xlate in the
> description portion (throughout).

Ok, done.

>> + * @spec: OF phandle args to map into an interconnect node.
>> + * @data: private data (pointer to struct icc_onecell_data)
>> + *
>> + * This is a generic xlate function that can be used to model simple
>> + * interconnect providers that have one device tree node and provide
>> + * multiple interconnect nodes. A single cell is used as an index into
>> + * an array of icc nodes specified in the icc_onecell_data struct when
>> + * registering the provider.
>> + */
[..]
>> +/**
>> + * of_icc_get() - get a path handle from a DT node based on name
>> + * @dev: device pointer for the consumer device
>> + * @name: interconnect path name
>> + *
>> + * This function will search for a path two endpoints and return an
> 
> path between two endpoints
> 

Ok.

>> + * icc_path handle on success. Use icc_put() to release constraints when
>> + * they are not needed anymore.
>> + * If the interconnect API is disabled, NULL is returned and the consumer
>> + * drivers will still build. Drivers are free to handle this specifically,
>> + * but they don't have to. NULL is also returned when the "interconnects"
> 
> I'm not sure the sentence starting with "Drivers are free" adds much.
> Also, you mention that null is returned when the interconnect API is
> disabled both above and below. We probably only need it once.
> 

So it depends on the driver how to handle it. If an enabled interconnect
is a hard requirement for a driver to work, it can choose to fail. If it
is optional, the driver can succeed and continue and all bandwidth
requests will be silently ignored.

>> + * DT property is missing.
>> + *
>> + * Return: icc_path pointer on success or ERR_PTR() on error. NULL is returned
>> + * when the API is disabled or the "interconnects" DT property is missing.
>> + */
>> +struct icc_path *of_icc_get(struct device *dev, const char *name)
>> +{
>> +       struct icc_path *path = ERR_PTR(-EPROBE_DEFER);
>> +       struct icc_node *src_node, *dst_node;
>> +       struct device_node *np = NULL;
>> +       struct of_phandle_args src_args, dst_args;
>> +       int idx = 0;
>> +       int ret;
>> +
>> +       if (!dev || !dev->of_node)
>> +               return ERR_PTR(-ENODEV);
>> +
>> +       np = dev->of_node;
>> +
>> +       /*
>> +        * When the consumer DT node do not have "interconnects" property
>> +        * return a NULL path to skip setting constraints.
>> +        */
>> +       if (!of_find_property(np, "interconnects", NULL))
>> +               return NULL;
>> +
>> +       /*
>> +        * We use a combination of phandle and specifier for endpoint. For now
>> +        * lets support only global ids and extend this is the future if needed
> 
> s/is the future/in the future/

Ok.

>> +        * without breaking DT compatibility.
>> +        */
>> +       if (name) {
>> +               idx = of_property_match_string(np, "interconnect-names", name);
>> +               if (idx < 0)
>> +                       return ERR_PTR(idx);
>> +       }
>> +
>> +       ret = of_parse_phandle_with_args(np, "interconnects",
>> +                                        "#interconnect-cells", idx * 2,
>> +                                        &src_args);
>> +       if (ret)
>> +               return ERR_PTR(ret);
>> +
>> +       of_node_put(src_args.np);
>> +
>> +       if (!src_args.args_count || src_args.args_count > 1)
> 
> This could be src_args.argc_count != 1
> 
>> +               return ERR_PTR(-EINVAL);
>> +
>> +       ret = of_parse_phandle_with_args(np, "interconnects",
>> +                                        "#interconnect-cells", idx * 2 + 1,
>> +                                        &dst_args);
>> +       if (ret)
>> +               return ERR_PTR(ret);
>> +
>> +       of_node_put(dst_args.np);
>> +
>> +       if (!dst_args.args_count || dst_args.args_count > 1)
> 
> Similarly, this could be dst_args.args_count != 1

Yes, and actually it might be even better if i move these checks to
of_icc_get_from_provider().

>> +               return ERR_PTR(-EINVAL);
>> +
>> +       src_node = of_icc_get_from_provider(&src_args);
>> +
>> +       if (IS_ERR(src_node)) {
>> +               if (PTR_ERR(src_node) != -EPROBE_DEFER)
>> +                       dev_err(dev, "error finding src node: %ld\n",
>> +                               PTR_ERR(src_node));
>> +               return ERR_CAST(src_node);
>> +       }
>> +
>> +       dst_node = of_icc_get_from_provider(&dst_args);
>> +
[..]>
> With these nits fixed:
> 
> Reviewed-by: Evan Green <evgreen@chromium.org>
> 

Thanks,
Georgi

Hi Evan,

On 12/1/18 02:39, Evan Green wrote:
> On Tue, Nov 27, 2018 at 10:04 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>
>> From: David Dai <daidavid1@codeaurora.org>
>>
>> Add RSC (Resource State Coordinator) provider
>> dictating network-on-chip interconnect bus performance
>> found on SDM845-based platforms.
>>
>> Signed-off-by: David Dai <daidavid1@codeaurora.org>
>> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
>> ---
>>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> index b72bdb0a31a5..856d33604e9c 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> @@ -1324,6 +1324,11 @@
>>                                 compatible = "qcom,sdm845-rpmh-clk";
>>                                 #clock-cells = <1>;
>>                         };
>> +
>> +                       qnoc: qnoc {
>> +                               compatible = "qcom,sdm845-rsc-hlos";
>> +                               #interconnect-cells = <1>;
>> +                       };
> 
> Should we alphabetize this node above rpmhcc?

Sure!

Thanks,
Georgi

On Tue, Nov 27, 2018 at 12:03 PM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>
> 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 participating in the
> topology node according to the requested data flow path, physical links and
> constraints. The topology could be complicated and multi-tiered and is SoC
> specific.
>
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> Reviewed-by: Evan Green <evgreen@chromium.org>

[...]

> +struct icc_path *icc_get(struct device *dev, const int src_id,
> +                        const int dst_id);
> +void icc_put(struct icc_path *path);
> +int icc_set(struct icc_path *path, u32 avg_bw, u32 peak_bw);

icc_set() is very generic, but this function isn't easily extended to
other parameters than bandwidth. Perhaps icc_set_bandwidth() instead.
Then when you add some other setting, you just add a new function. Of
course, if you wind up with a bunch of different parameters, then
you'll probably need an atomic type interface where you test all the
settings together and then commit them separately in one call. But
from a DT perspective, I certainly hope there are not lots of new
settings folks want to add. :)

Rob

On Tue, Nov 27, 2018 at 10:03 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>
> Modern SoCs have multiple processors and various dedicated cores (video, gpu,
> graphics, modem). These cores are talking to each other and can generate a
> lot of data flowing through the on-chip interconnects. These interconnect
> buses could form different topologies such as crossbar, point to point buses,
> hierarchical buses or use the network-on-chip concept.
>
> These buses have been sized usually to handle use cases with high data
> throughput but it is not necessary all the time and consume a lot of power.
> Furthermore, the priority between masters can vary depending on the running
> use case like video playback or CPU intensive tasks.
>
> Having an API to control the requirement of the system in terms of bandwidth
> and QoS, so we can adapt the interconnect configuration to match those by
> scaling the frequencies, setting link priority and tuning QoS parameters.
> This configuration can be a static, one-time operation done at boot for some
> platforms or a dynamic set of operations that happen at run-time.
>
> This patchset introduce a new API to get the requirement and configure the
> interconnect buses across the entire chipset to fit with the current demand.
> The API is NOT for changing the performance of the endpoint devices, but only
> the interconnect path in between them.

For what it's worth, we are ready to land this in Chrome OS. I think
this series has been very well discussed and reviewed, hasn't changed
much in the last few spins, and is in good enough shape to use as a
base for future patches. Georgi's also done a great job reaching out
to other SoC vendors, and there appears to be enough consensus that
this framework will be usable by more than just Qualcomm. There are
also several drivers out on the list trying to add patches to use this
framework, with more to come, so it made sense (to us) to get this
base framework nailed down. In my experiments this is an important
piece of the overall power management story, especially on systems
that are mostly idle.

I'll continue to track changes to this series and we will ultimately
reconcile with whatever happens upstream, but I thought it was worth
sending this note to express our "thumbs up" towards this framework.

-Evan

On Wed, Dec 05, 2018 at 12:41:35PM -0800, Evan Green wrote:
> On Tue, Nov 27, 2018 at 10:03 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
> >
> > Modern SoCs have multiple processors and various dedicated cores (video, gpu,
> > graphics, modem). These cores are talking to each other and can generate a
> > lot of data flowing through the on-chip interconnects. These interconnect
> > buses could form different topologies such as crossbar, point to point buses,
> > hierarchical buses or use the network-on-chip concept.
> >
> > These buses have been sized usually to handle use cases with high data
> > throughput but it is not necessary all the time and consume a lot of power.
> > Furthermore, the priority between masters can vary depending on the running
> > use case like video playback or CPU intensive tasks.
> >
> > Having an API to control the requirement of the system in terms of bandwidth
> > and QoS, so we can adapt the interconnect configuration to match those by
> > scaling the frequencies, setting link priority and tuning QoS parameters.
> > This configuration can be a static, one-time operation done at boot for some
> > platforms or a dynamic set of operations that happen at run-time.
> >
> > This patchset introduce a new API to get the requirement and configure the
> > interconnect buses across the entire chipset to fit with the current demand.
> > The API is NOT for changing the performance of the endpoint devices, but only
> > the interconnect path in between them.
> 
> For what it's worth, we are ready to land this in Chrome OS. I think
> this series has been very well discussed and reviewed, hasn't changed
> much in the last few spins, and is in good enough shape to use as a
> base for future patches. Georgi's also done a great job reaching out
> to other SoC vendors, and there appears to be enough consensus that
> this framework will be usable by more than just Qualcomm. There are
> also several drivers out on the list trying to add patches to use this
> framework, with more to come, so it made sense (to us) to get this
> base framework nailed down. In my experiments this is an important
> piece of the overall power management story, especially on systems
> that are mostly idle.
> 
> I'll continue to track changes to this series and we will ultimately
> reconcile with whatever happens upstream, but I thought it was worth
> sending this note to express our "thumbs up" towards this framework.

Looks like a v11 will be forthcoming, so I'll wait for that one to apply
it to the tree if all looks good.

thanks,

greg k-h

Hi Greg and Evan,

On 12/6/18 16:55, Greg KH wrote:
> On Wed, Dec 05, 2018 at 12:41:35PM -0800, Evan Green wrote:
>> On Tue, Nov 27, 2018 at 10:03 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>>
>>> Modern SoCs have multiple processors and various dedicated cores (video, gpu,
>>> graphics, modem). These cores are talking to each other and can generate a
>>> lot of data flowing through the on-chip interconnects. These interconnect
>>> buses could form different topologies such as crossbar, point to point buses,
>>> hierarchical buses or use the network-on-chip concept.
>>>
>>> These buses have been sized usually to handle use cases with high data
>>> throughput but it is not necessary all the time and consume a lot of power.
>>> Furthermore, the priority between masters can vary depending on the running
>>> use case like video playback or CPU intensive tasks.
>>>
>>> Having an API to control the requirement of the system in terms of bandwidth
>>> and QoS, so we can adapt the interconnect configuration to match those by
>>> scaling the frequencies, setting link priority and tuning QoS parameters.
>>> This configuration can be a static, one-time operation done at boot for some
>>> platforms or a dynamic set of operations that happen at run-time.
>>>
>>> This patchset introduce a new API to get the requirement and configure the
>>> interconnect buses across the entire chipset to fit with the current demand.
>>> The API is NOT for changing the performance of the endpoint devices, but only
>>> the interconnect path in between them.
>>
>> For what it's worth, we are ready to land this in Chrome OS. I think
>> this series has been very well discussed and reviewed, hasn't changed
>> much in the last few spins, and is in good enough shape to use as a
>> base for future patches. Georgi's also done a great job reaching out
>> to other SoC vendors, and there appears to be enough consensus that
>> this framework will be usable by more than just Qualcomm. There are
>> also several drivers out on the list trying to add patches to use this
>> framework, with more to come, so it made sense (to us) to get this
>> base framework nailed down. In my experiments this is an important
>> piece of the overall power management story, especially on systems
>> that are mostly idle.
>>
>> I'll continue to track changes to this series and we will ultimately
>> reconcile with whatever happens upstream, but I thought it was worth
>> sending this note to express our "thumbs up" towards this framework.
> 
> Looks like a v11 will be forthcoming, so I'll wait for that one to apply
> it to the tree if all looks good.
> 

Yes, it's coming. I will also include an additional fixup patch, as the
sdm845 provider driver will fail to build in linux-next, due to a recent
change in the cmd_db API.

Thanks,
Georgi

Hi Rob,

On 12/5/18 18:16, Rob Herring wrote:
> On Tue, Nov 27, 2018 at 12:03 PM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>
>> 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 participating in the
>> topology node according to the requested data flow path, physical links and
>> constraints. The topology could be complicated and multi-tiered and is SoC
>> specific.
>>
>> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
>> Reviewed-by: Evan Green <evgreen@chromium.org>
> 
> [...]
> 
>> +struct icc_path *icc_get(struct device *dev, const int src_id,
>> +                        const int dst_id);
>> +void icc_put(struct icc_path *path);
>> +int icc_set(struct icc_path *path, u32 avg_bw, u32 peak_bw);
> 
> icc_set() is very generic, but this function isn't easily extended to
> other parameters than bandwidth. Perhaps icc_set_bandwidth() instead.
> Then when you add some other setting, you just add a new function. Of
> course, if you wind up with a bunch of different parameters, then
> you'll probably need an atomic type interface where you test all the
> settings together and then commit them separately in one call. But

Thanks for the comment. We have already started some discussion with the
Nvidia guys about supporting also latency and priority. We can do a
structure based approach and pass a struct with all the bandwidth /
latency / priority stuff to a function like icc_set_extended(); It's
very early for any conclusions yet and for now we support only
bandwidth. The function name still can be easy changed with a follow-up
patch until one is using it yet. Let me think again.

> from a DT perspective, I certainly hope there are not lots of new
> settings folks want to add. 
Regarding DT, all settings should go into the drivers for now and
later we can decide if something makes sense to be really in device-tree.

Thanks,
Georgi

On Thu, Dec 6, 2018 at 3:55 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Dec 05, 2018 at 12:41:35PM -0800, Evan Green wrote:
> > On Tue, Nov 27, 2018 at 10:03 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
> > >
> > > Modern SoCs have multiple processors and various dedicated cores (video, gpu,
> > > graphics, modem). These cores are talking to each other and can generate a
> > > lot of data flowing through the on-chip interconnects. These interconnect
> > > buses could form different topologies such as crossbar, point to point buses,
> > > hierarchical buses or use the network-on-chip concept.
> > >
> > > These buses have been sized usually to handle use cases with high data
> > > throughput but it is not necessary all the time and consume a lot of power.
> > > Furthermore, the priority between masters can vary depending on the running
> > > use case like video playback or CPU intensive tasks.
> > >
> > > Having an API to control the requirement of the system in terms of bandwidth
> > > and QoS, so we can adapt the interconnect configuration to match those by
> > > scaling the frequencies, setting link priority and tuning QoS parameters.
> > > This configuration can be a static, one-time operation done at boot for some
> > > platforms or a dynamic set of operations that happen at run-time.
> > >
> > > This patchset introduce a new API to get the requirement and configure the
> > > interconnect buses across the entire chipset to fit with the current demand.
> > > The API is NOT for changing the performance of the endpoint devices, but only
> > > the interconnect path in between them.
> >
> > For what it's worth, we are ready to land this in Chrome OS. I think
> > this series has been very well discussed and reviewed, hasn't changed
> > much in the last few spins, and is in good enough shape to use as a
> > base for future patches. Georgi's also done a great job reaching out
> > to other SoC vendors, and there appears to be enough consensus that
> > this framework will be usable by more than just Qualcomm. There are
> > also several drivers out on the list trying to add patches to use this
> > framework, with more to come, so it made sense (to us) to get this
> > base framework nailed down. In my experiments this is an important
> > piece of the overall power management story, especially on systems
> > that are mostly idle.
> >
> > I'll continue to track changes to this series and we will ultimately
> > reconcile with whatever happens upstream, but I thought it was worth
> > sending this note to express our "thumbs up" towards this framework.
>
> Looks like a v11 will be forthcoming, so I'll wait for that one to apply
> it to the tree if all looks good.

I'm honestly not sure if it is ready yet.

New versions are coming on and on, which may make such an impression,
but we had some discussion on it at the LPC and some serious questions
were asked during it, for instance regarding the DT binding introduced
here.  I'm not sure how this particular issue has been addressed here,
for example.

Thanks,
Rafael

Hi Rafael,

On 12/10/18 11:04, Rafael J. Wysocki wrote:
> On Thu, Dec 6, 2018 at 3:55 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>>
>> On Wed, Dec 05, 2018 at 12:41:35PM -0800, Evan Green wrote:
>>> On Tue, Nov 27, 2018 at 10:03 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>>>
>>>> Modern SoCs have multiple processors and various dedicated cores (video, gpu,
>>>> graphics, modem). These cores are talking to each other and can generate a
>>>> lot of data flowing through the on-chip interconnects. These interconnect
>>>> buses could form different topologies such as crossbar, point to point buses,
>>>> hierarchical buses or use the network-on-chip concept.
>>>>
>>>> These buses have been sized usually to handle use cases with high data
>>>> throughput but it is not necessary all the time and consume a lot of power.
>>>> Furthermore, the priority between masters can vary depending on the running
>>>> use case like video playback or CPU intensive tasks.
>>>>
>>>> Having an API to control the requirement of the system in terms of bandwidth
>>>> and QoS, so we can adapt the interconnect configuration to match those by
>>>> scaling the frequencies, setting link priority and tuning QoS parameters.
>>>> This configuration can be a static, one-time operation done at boot for some
>>>> platforms or a dynamic set of operations that happen at run-time.
>>>>
>>>> This patchset introduce a new API to get the requirement and configure the
>>>> interconnect buses across the entire chipset to fit with the current demand.
>>>> The API is NOT for changing the performance of the endpoint devices, but only
>>>> the interconnect path in between them.
>>>
>>> For what it's worth, we are ready to land this in Chrome OS. I think
>>> this series has been very well discussed and reviewed, hasn't changed
>>> much in the last few spins, and is in good enough shape to use as a
>>> base for future patches. Georgi's also done a great job reaching out
>>> to other SoC vendors, and there appears to be enough consensus that
>>> this framework will be usable by more than just Qualcomm. There are
>>> also several drivers out on the list trying to add patches to use this
>>> framework, with more to come, so it made sense (to us) to get this
>>> base framework nailed down. In my experiments this is an important
>>> piece of the overall power management story, especially on systems
>>> that are mostly idle.
>>>
>>> I'll continue to track changes to this series and we will ultimately
>>> reconcile with whatever happens upstream, but I thought it was worth
>>> sending this note to express our "thumbs up" towards this framework.
>>
>> Looks like a v11 will be forthcoming, so I'll wait for that one to apply
>> it to the tree if all looks good.
> 
> I'm honestly not sure if it is ready yet.
> 
> New versions are coming on and on, which may make such an impression,
> but we had some discussion on it at the LPC and some serious questions
> were asked during it, for instance regarding the DT binding introduced
> here.  I'm not sure how this particular issue has been addressed here,
> for example.

There have been no changes in bindings since v4 (other than squashing
consumer and provider bindings into a single patch and fixing typos).

The last DT comment was on v9 [1] where Rob wanted confirmation from
other SoC vendors that this works for them too. And now we have that
confirmation and there are patches posted on the list [2].

The second thing (also discussed at LPC) was about possible cases where
some consumer drivers can't calculate how much bandwidth they actually
need and how to address that. The proposal was to extend the OPP
bindings with one more property, but this is not part of this patchset.
It is a future step that needs more discussion on the mailing list. If a
driver really needs some bandwidth data now, it should be put into the
driver and not in DT. After we have enough consumers, we can discuss
again if it makes sense to extract something into DT or not.

Thanks,
Georgi

[1] https://lkml.org/lkml/2018/9/25/939
[2] https://lkml.org/lkml/2018/11/28/12

On Mon, Dec 10, 2018 at 11:18 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>
> Hi Rafael,
>
> On 12/10/18 11:04, Rafael J. Wysocki wrote:
> > On Thu, Dec 6, 2018 at 3:55 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >>
> >> On Wed, Dec 05, 2018 at 12:41:35PM -0800, Evan Green wrote:
> >>> On Tue, Nov 27, 2018 at 10:03 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
> >>>>
> >>>> Modern SoCs have multiple processors and various dedicated cores (video, gpu,
> >>>> graphics, modem). These cores are talking to each other and can generate a
> >>>> lot of data flowing through the on-chip interconnects. These interconnect
> >>>> buses could form different topologies such as crossbar, point to point buses,
> >>>> hierarchical buses or use the network-on-chip concept.
> >>>>
> >>>> These buses have been sized usually to handle use cases with high data
> >>>> throughput but it is not necessary all the time and consume a lot of power.
> >>>> Furthermore, the priority between masters can vary depending on the running
> >>>> use case like video playback or CPU intensive tasks.
> >>>>
> >>>> Having an API to control the requirement of the system in terms of bandwidth
> >>>> and QoS, so we can adapt the interconnect configuration to match those by
> >>>> scaling the frequencies, setting link priority and tuning QoS parameters.
> >>>> This configuration can be a static, one-time operation done at boot for some
> >>>> platforms or a dynamic set of operations that happen at run-time.
> >>>>
> >>>> This patchset introduce a new API to get the requirement and configure the
> >>>> interconnect buses across the entire chipset to fit with the current demand.
> >>>> The API is NOT for changing the performance of the endpoint devices, but only
> >>>> the interconnect path in between them.
> >>>
> >>> For what it's worth, we are ready to land this in Chrome OS. I think
> >>> this series has been very well discussed and reviewed, hasn't changed
> >>> much in the last few spins, and is in good enough shape to use as a
> >>> base for future patches. Georgi's also done a great job reaching out
> >>> to other SoC vendors, and there appears to be enough consensus that
> >>> this framework will be usable by more than just Qualcomm. There are
> >>> also several drivers out on the list trying to add patches to use this
> >>> framework, with more to come, so it made sense (to us) to get this
> >>> base framework nailed down. In my experiments this is an important
> >>> piece of the overall power management story, especially on systems
> >>> that are mostly idle.
> >>>
> >>> I'll continue to track changes to this series and we will ultimately
> >>> reconcile with whatever happens upstream, but I thought it was worth
> >>> sending this note to express our "thumbs up" towards this framework.
> >>
> >> Looks like a v11 will be forthcoming, so I'll wait for that one to apply
> >> it to the tree if all looks good.
> >
> > I'm honestly not sure if it is ready yet.
> >
> > New versions are coming on and on, which may make such an impression,
> > but we had some discussion on it at the LPC and some serious questions
> > were asked during it, for instance regarding the DT binding introduced
> > here.  I'm not sure how this particular issue has been addressed here,
> > for example.
>
> There have been no changes in bindings since v4 (other than squashing
> consumer and provider bindings into a single patch and fixing typos).
>
> The last DT comment was on v9 [1] where Rob wanted confirmation from
> other SoC vendors that this works for them too. And now we have that
> confirmation and there are patches posted on the list [2].

OK

> The second thing (also discussed at LPC) was about possible cases where
> some consumer drivers can't calculate how much bandwidth they actually
> need and how to address that. The proposal was to extend the OPP
> bindings with one more property, but this is not part of this patchset.
> It is a future step that needs more discussion on the mailing list. If a
> driver really needs some bandwidth data now, it should be put into the
> driver and not in DT. After we have enough consumers, we can discuss
> again if it makes sense to extract something into DT or not.

That's fine by me.

Admittedly, I have some reservations regarding the extent to which
this approach will turn out to be useful in practice, but I guess as
long as there is enough traction, the best way to find out it to try
and see. :-)

>From now on I will assume that this series is going to be applied by Greg.

Thanks,
Rafael

On 12/10/18 13:00, Rafael J. Wysocki wrote:
> On Mon, Dec 10, 2018 at 11:18 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>
>> Hi Rafael,
>>
>> On 12/10/18 11:04, Rafael J. Wysocki wrote:
>>> On Thu, Dec 6, 2018 at 3:55 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>>>>
>>>> On Wed, Dec 05, 2018 at 12:41:35PM -0800, Evan Green wrote:
>>>>> On Tue, Nov 27, 2018 at 10:03 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>>>>>
>>>>>> Modern SoCs have multiple processors and various dedicated cores (video, gpu,
>>>>>> graphics, modem). These cores are talking to each other and can generate a
>>>>>> lot of data flowing through the on-chip interconnects. These interconnect
>>>>>> buses could form different topologies such as crossbar, point to point buses,
>>>>>> hierarchical buses or use the network-on-chip concept.
>>>>>>
>>>>>> These buses have been sized usually to handle use cases with high data
>>>>>> throughput but it is not necessary all the time and consume a lot of power.
>>>>>> Furthermore, the priority between masters can vary depending on the running
>>>>>> use case like video playback or CPU intensive tasks.
>>>>>>
>>>>>> Having an API to control the requirement of the system in terms of bandwidth
>>>>>> and QoS, so we can adapt the interconnect configuration to match those by
>>>>>> scaling the frequencies, setting link priority and tuning QoS parameters.
>>>>>> This configuration can be a static, one-time operation done at boot for some
>>>>>> platforms or a dynamic set of operations that happen at run-time.
>>>>>>
>>>>>> This patchset introduce a new API to get the requirement and configure the
>>>>>> interconnect buses across the entire chipset to fit with the current demand.
>>>>>> The API is NOT for changing the performance of the endpoint devices, but only
>>>>>> the interconnect path in between them.
>>>>>
>>>>> For what it's worth, we are ready to land this in Chrome OS. I think
>>>>> this series has been very well discussed and reviewed, hasn't changed
>>>>> much in the last few spins, and is in good enough shape to use as a
>>>>> base for future patches. Georgi's also done a great job reaching out
>>>>> to other SoC vendors, and there appears to be enough consensus that
>>>>> this framework will be usable by more than just Qualcomm. There are
>>>>> also several drivers out on the list trying to add patches to use this
>>>>> framework, with more to come, so it made sense (to us) to get this
>>>>> base framework nailed down. In my experiments this is an important
>>>>> piece of the overall power management story, especially on systems
>>>>> that are mostly idle.
>>>>>
>>>>> I'll continue to track changes to this series and we will ultimately
>>>>> reconcile with whatever happens upstream, but I thought it was worth
>>>>> sending this note to express our "thumbs up" towards this framework.
>>>>
>>>> Looks like a v11 will be forthcoming, so I'll wait for that one to apply
>>>> it to the tree if all looks good.
>>>
>>> I'm honestly not sure if it is ready yet.
>>>
>>> New versions are coming on and on, which may make such an impression,
>>> but we had some discussion on it at the LPC and some serious questions
>>> were asked during it, for instance regarding the DT binding introduced
>>> here.  I'm not sure how this particular issue has been addressed here,
>>> for example.
>>
>> There have been no changes in bindings since v4 (other than squashing
>> consumer and provider bindings into a single patch and fixing typos).
>>
>> The last DT comment was on v9 [1] where Rob wanted confirmation from
>> other SoC vendors that this works for them too. And now we have that
>> confirmation and there are patches posted on the list [2].
> 
> OK
> 
>> The second thing (also discussed at LPC) was about possible cases where
>> some consumer drivers can't calculate how much bandwidth they actually
>> need and how to address that. The proposal was to extend the OPP
>> bindings with one more property, but this is not part of this patchset.
>> It is a future step that needs more discussion on the mailing list. If a
>> driver really needs some bandwidth data now, it should be put into the
>> driver and not in DT. After we have enough consumers, we can discuss
>> again if it makes sense to extract something into DT or not.
> 
> That's fine by me.
> 
> Admittedly, I have some reservations regarding the extent to which
> this approach will turn out to be useful in practice, but I guess as
> long as there is enough traction, the best way to find out it to try
> and see. :-)
> 
> From now on I will assume that this series is going to be applied by Greg.

That was the initial idea, but the problem is that there is a recent
change in the cmd_db API (needed by the sdm845 provider driver), which
is going through arm-soc/qcom/drivers. So either Greg pulls also the
qcom-drivers-for-4.21 tag from Andy or the whole series goes via Olof
and Arnd. Maybe there are other options. I don't have any preference and
don't want to put extra burden on any maintainers, so i am ok with what
they prefer.

Thanks,
Georgi

On Mon, Dec 10, 2018 at 04:50:00PM +0200, Georgi Djakov wrote:
> On 12/10/18 13:00, Rafael J. Wysocki wrote:
> > On Mon, Dec 10, 2018 at 11:18 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
> >>
> >> Hi Rafael,
> >>
> >> On 12/10/18 11:04, Rafael J. Wysocki wrote:
> >>> On Thu, Dec 6, 2018 at 3:55 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >>>>
> >>>> On Wed, Dec 05, 2018 at 12:41:35PM -0800, Evan Green wrote:
> >>>>> On Tue, Nov 27, 2018 at 10:03 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
> >>>>>>
> >>>>>> Modern SoCs have multiple processors and various dedicated cores (video, gpu,
> >>>>>> graphics, modem). These cores are talking to each other and can generate a
> >>>>>> lot of data flowing through the on-chip interconnects. These interconnect
> >>>>>> buses could form different topologies such as crossbar, point to point buses,
> >>>>>> hierarchical buses or use the network-on-chip concept.
> >>>>>>
> >>>>>> These buses have been sized usually to handle use cases with high data
> >>>>>> throughput but it is not necessary all the time and consume a lot of power.
> >>>>>> Furthermore, the priority between masters can vary depending on the running
> >>>>>> use case like video playback or CPU intensive tasks.
> >>>>>>
> >>>>>> Having an API to control the requirement of the system in terms of bandwidth
> >>>>>> and QoS, so we can adapt the interconnect configuration to match those by
> >>>>>> scaling the frequencies, setting link priority and tuning QoS parameters.
> >>>>>> This configuration can be a static, one-time operation done at boot for some
> >>>>>> platforms or a dynamic set of operations that happen at run-time.
> >>>>>>
> >>>>>> This patchset introduce a new API to get the requirement and configure the
> >>>>>> interconnect buses across the entire chipset to fit with the current demand.
> >>>>>> The API is NOT for changing the performance of the endpoint devices, but only
> >>>>>> the interconnect path in between them.
> >>>>>
> >>>>> For what it's worth, we are ready to land this in Chrome OS. I think
> >>>>> this series has been very well discussed and reviewed, hasn't changed
> >>>>> much in the last few spins, and is in good enough shape to use as a
> >>>>> base for future patches. Georgi's also done a great job reaching out
> >>>>> to other SoC vendors, and there appears to be enough consensus that
> >>>>> this framework will be usable by more than just Qualcomm. There are
> >>>>> also several drivers out on the list trying to add patches to use this
> >>>>> framework, with more to come, so it made sense (to us) to get this
> >>>>> base framework nailed down. In my experiments this is an important
> >>>>> piece of the overall power management story, especially on systems
> >>>>> that are mostly idle.
> >>>>>
> >>>>> I'll continue to track changes to this series and we will ultimately
> >>>>> reconcile with whatever happens upstream, but I thought it was worth
> >>>>> sending this note to express our "thumbs up" towards this framework.
> >>>>
> >>>> Looks like a v11 will be forthcoming, so I'll wait for that one to apply
> >>>> it to the tree if all looks good.
> >>>
> >>> I'm honestly not sure if it is ready yet.
> >>>
> >>> New versions are coming on and on, which may make such an impression,
> >>> but we had some discussion on it at the LPC and some serious questions
> >>> were asked during it, for instance regarding the DT binding introduced
> >>> here.  I'm not sure how this particular issue has been addressed here,
> >>> for example.
> >>
> >> There have been no changes in bindings since v4 (other than squashing
> >> consumer and provider bindings into a single patch and fixing typos).
> >>
> >> The last DT comment was on v9 [1] where Rob wanted confirmation from
> >> other SoC vendors that this works for them too. And now we have that
> >> confirmation and there are patches posted on the list [2].
> > 
> > OK
> > 
> >> The second thing (also discussed at LPC) was about possible cases where
> >> some consumer drivers can't calculate how much bandwidth they actually
> >> need and how to address that. The proposal was to extend the OPP
> >> bindings with one more property, but this is not part of this patchset.
> >> It is a future step that needs more discussion on the mailing list. If a
> >> driver really needs some bandwidth data now, it should be put into the
> >> driver and not in DT. After we have enough consumers, we can discuss
> >> again if it makes sense to extract something into DT or not.
> > 
> > That's fine by me.
> > 
> > Admittedly, I have some reservations regarding the extent to which
> > this approach will turn out to be useful in practice, but I guess as
> > long as there is enough traction, the best way to find out it to try
> > and see. :-)
> > 
> > From now on I will assume that this series is going to be applied by Greg.
> 
> That was the initial idea, but the problem is that there is a recent
> change in the cmd_db API (needed by the sdm845 provider driver), which
> is going through arm-soc/qcom/drivers. So either Greg pulls also the
> qcom-drivers-for-4.21 tag from Andy or the whole series goes via Olof
> and Arnd. Maybe there are other options. I don't have any preference and
> don't want to put extra burden on any maintainers, so i am ok with what
> they prefer.

Let me take the time later this week to review the code, which I haven't
done in a while...

thanks,

greg k-h

Hi Greg,

On 12/11/18 08:58, Greg Kroah-Hartman wrote:
> On Mon, Dec 10, 2018 at 04:50:00PM +0200, Georgi Djakov wrote:
>> On 12/10/18 13:00, Rafael J. Wysocki wrote:
>>> On Mon, Dec 10, 2018 at 11:18 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>>>
>>>> Hi Rafael,
>>>>
>>>> On 12/10/18 11:04, Rafael J. Wysocki wrote:
>>>>> On Thu, Dec 6, 2018 at 3:55 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>>>>>>
>>>>>> On Wed, Dec 05, 2018 at 12:41:35PM -0800, Evan Green wrote:
>>>>>>> On Tue, Nov 27, 2018 at 10:03 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>>>>>>>
>>>>>>>> Modern SoCs have multiple processors and various dedicated cores (video, gpu,
>>>>>>>> graphics, modem). These cores are talking to each other and can generate a
>>>>>>>> lot of data flowing through the on-chip interconnects. These interconnect
>>>>>>>> buses could form different topologies such as crossbar, point to point buses,
>>>>>>>> hierarchical buses or use the network-on-chip concept.
>>>>>>>>
>>>>>>>> These buses have been sized usually to handle use cases with high data
>>>>>>>> throughput but it is not necessary all the time and consume a lot of power.
>>>>>>>> Furthermore, the priority between masters can vary depending on the running
>>>>>>>> use case like video playback or CPU intensive tasks.
>>>>>>>>
>>>>>>>> Having an API to control the requirement of the system in terms of bandwidth
>>>>>>>> and QoS, so we can adapt the interconnect configuration to match those by
>>>>>>>> scaling the frequencies, setting link priority and tuning QoS parameters.
>>>>>>>> This configuration can be a static, one-time operation done at boot for some
>>>>>>>> platforms or a dynamic set of operations that happen at run-time.
>>>>>>>>
>>>>>>>> This patchset introduce a new API to get the requirement and configure the
>>>>>>>> interconnect buses across the entire chipset to fit with the current demand.
>>>>>>>> The API is NOT for changing the performance of the endpoint devices, but only
>>>>>>>> the interconnect path in between them.
>>>>>>>
>>>>>>> For what it's worth, we are ready to land this in Chrome OS. I think
>>>>>>> this series has been very well discussed and reviewed, hasn't changed
>>>>>>> much in the last few spins, and is in good enough shape to use as a
>>>>>>> base for future patches. Georgi's also done a great job reaching out
>>>>>>> to other SoC vendors, and there appears to be enough consensus that
>>>>>>> this framework will be usable by more than just Qualcomm. There are
>>>>>>> also several drivers out on the list trying to add patches to use this
>>>>>>> framework, with more to come, so it made sense (to us) to get this
>>>>>>> base framework nailed down. In my experiments this is an important
>>>>>>> piece of the overall power management story, especially on systems
>>>>>>> that are mostly idle.
>>>>>>>
>>>>>>> I'll continue to track changes to this series and we will ultimately
>>>>>>> reconcile with whatever happens upstream, but I thought it was worth
>>>>>>> sending this note to express our "thumbs up" towards this framework.
>>>>>>
>>>>>> Looks like a v11 will be forthcoming, so I'll wait for that one to apply
>>>>>> it to the tree if all looks good.
>>>>>
>>>>> I'm honestly not sure if it is ready yet.
>>>>>
>>>>> New versions are coming on and on, which may make such an impression,
>>>>> but we had some discussion on it at the LPC and some serious questions
>>>>> were asked during it, for instance regarding the DT binding introduced
>>>>> here.  I'm not sure how this particular issue has been addressed here,
>>>>> for example.
>>>>
>>>> There have been no changes in bindings since v4 (other than squashing
>>>> consumer and provider bindings into a single patch and fixing typos).
>>>>
>>>> The last DT comment was on v9 [1] where Rob wanted confirmation from
>>>> other SoC vendors that this works for them too. And now we have that
>>>> confirmation and there are patches posted on the list [2].
>>>
>>> OK
>>>
>>>> The second thing (also discussed at LPC) was about possible cases where
>>>> some consumer drivers can't calculate how much bandwidth they actually
>>>> need and how to address that. The proposal was to extend the OPP
>>>> bindings with one more property, but this is not part of this patchset.
>>>> It is a future step that needs more discussion on the mailing list. If a
>>>> driver really needs some bandwidth data now, it should be put into the
>>>> driver and not in DT. After we have enough consumers, we can discuss
>>>> again if it makes sense to extract something into DT or not.
>>>
>>> That's fine by me.
>>>
>>> Admittedly, I have some reservations regarding the extent to which
>>> this approach will turn out to be useful in practice, but I guess as
>>> long as there is enough traction, the best way to find out it to try
>>> and see. :-)
>>>
>>> From now on I will assume that this series is going to be applied by Greg.
>>
>> That was the initial idea, but the problem is that there is a recent
>> change in the cmd_db API (needed by the sdm845 provider driver), which
>> is going through arm-soc/qcom/drivers. So either Greg pulls also the
>> qcom-drivers-for-4.21 tag from Andy or the whole series goes via Olof
>> and Arnd. Maybe there are other options. I don't have any preference and
>> don't want to put extra burden on any maintainers, so i am ok with what
>> they prefer.
> 
> Let me take the time later this week to review the code, which I haven't
> done in a while...
> 

When you get a chance to review, please keep in mind that the latest
version is v12 (from 08.Dec). The same is also available in linux-next
with no reported issues.

Thanks,
Georgi

Hi Greg,

On 12/17/18 13:17, Georgi Djakov wrote:
> Hi Greg,
> 
> On 12/11/18 08:58, Greg Kroah-Hartman wrote:
>> On Mon, Dec 10, 2018 at 04:50:00PM +0200, Georgi Djakov wrote:
>>> On 12/10/18 13:00, Rafael J. Wysocki wrote:
>>>> On Mon, Dec 10, 2018 at 11:18 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>>>>
>>>>> Hi Rafael,
>>>>>
>>>>> On 12/10/18 11:04, Rafael J. Wysocki wrote:
>>>>>> On Thu, Dec 6, 2018 at 3:55 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>>>>>>>
>>>>>>> On Wed, Dec 05, 2018 at 12:41:35PM -0800, Evan Green wrote:
>>>>>>>> On Tue, Nov 27, 2018 at 10:03 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>>>>>>>>
>>>>>>>>> Modern SoCs have multiple processors and various dedicated cores (video, gpu,
>>>>>>>>> graphics, modem). These cores are talking to each other and can generate a
>>>>>>>>> lot of data flowing through the on-chip interconnects. These interconnect
>>>>>>>>> buses could form different topologies such as crossbar, point to point buses,
>>>>>>>>> hierarchical buses or use the network-on-chip concept.
>>>>>>>>>
>>>>>>>>> These buses have been sized usually to handle use cases with high data
>>>>>>>>> throughput but it is not necessary all the time and consume a lot of power.
>>>>>>>>> Furthermore, the priority between masters can vary depending on the running
>>>>>>>>> use case like video playback or CPU intensive tasks.
>>>>>>>>>
>>>>>>>>> Having an API to control the requirement of the system in terms of bandwidth
>>>>>>>>> and QoS, so we can adapt the interconnect configuration to match those by
>>>>>>>>> scaling the frequencies, setting link priority and tuning QoS parameters.
>>>>>>>>> This configuration can be a static, one-time operation done at boot for some
>>>>>>>>> platforms or a dynamic set of operations that happen at run-time.
>>>>>>>>>
>>>>>>>>> This patchset introduce a new API to get the requirement and configure the
>>>>>>>>> interconnect buses across the entire chipset to fit with the current demand.
>>>>>>>>> The API is NOT for changing the performance of the endpoint devices, but only
>>>>>>>>> the interconnect path in between them.
>>>>>>>>
>>>>>>>> For what it's worth, we are ready to land this in Chrome OS. I think
>>>>>>>> this series has been very well discussed and reviewed, hasn't changed
>>>>>>>> much in the last few spins, and is in good enough shape to use as a
>>>>>>>> base for future patches. Georgi's also done a great job reaching out
>>>>>>>> to other SoC vendors, and there appears to be enough consensus that
>>>>>>>> this framework will be usable by more than just Qualcomm. There are
>>>>>>>> also several drivers out on the list trying to add patches to use this
>>>>>>>> framework, with more to come, so it made sense (to us) to get this
>>>>>>>> base framework nailed down. In my experiments this is an important
>>>>>>>> piece of the overall power management story, especially on systems
>>>>>>>> that are mostly idle.
>>>>>>>>
>>>>>>>> I'll continue to track changes to this series and we will ultimately
>>>>>>>> reconcile with whatever happens upstream, but I thought it was worth
>>>>>>>> sending this note to express our "thumbs up" towards this framework.
>>>>>>>
>>>>>>> Looks like a v11 will be forthcoming, so I'll wait for that one to apply
>>>>>>> it to the tree if all looks good.
>>>>>>
>>>>>> I'm honestly not sure if it is ready yet.
>>>>>>
>>>>>> New versions are coming on and on, which may make such an impression,
>>>>>> but we had some discussion on it at the LPC and some serious questions
>>>>>> were asked during it, for instance regarding the DT binding introduced
>>>>>> here.  I'm not sure how this particular issue has been addressed here,
>>>>>> for example.
>>>>>
>>>>> There have been no changes in bindings since v4 (other than squashing
>>>>> consumer and provider bindings into a single patch and fixing typos).
>>>>>
>>>>> The last DT comment was on v9 [1] where Rob wanted confirmation from
>>>>> other SoC vendors that this works for them too. And now we have that
>>>>> confirmation and there are patches posted on the list [2].
>>>>
>>>> OK
>>>>
>>>>> The second thing (also discussed at LPC) was about possible cases where
>>>>> some consumer drivers can't calculate how much bandwidth they actually
>>>>> need and how to address that. The proposal was to extend the OPP
>>>>> bindings with one more property, but this is not part of this patchset.
>>>>> It is a future step that needs more discussion on the mailing list. If a
>>>>> driver really needs some bandwidth data now, it should be put into the
>>>>> driver and not in DT. After we have enough consumers, we can discuss
>>>>> again if it makes sense to extract something into DT or not.
>>>>
>>>> That's fine by me.
>>>>
>>>> Admittedly, I have some reservations regarding the extent to which
>>>> this approach will turn out to be useful in practice, but I guess as
>>>> long as there is enough traction, the best way to find out it to try
>>>> and see. :-)
>>>>
>>>> From now on I will assume that this series is going to be applied by Greg.
>>>
>>> That was the initial idea, but the problem is that there is a recent
>>> change in the cmd_db API (needed by the sdm845 provider driver), which
>>> is going through arm-soc/qcom/drivers. So either Greg pulls also the
>>> qcom-drivers-for-4.21 tag from Andy or the whole series goes via Olof
>>> and Arnd. Maybe there are other options. I don't have any preference and
>>> don't want to put extra burden on any maintainers, so i am ok with what
>>> they prefer.
>>
>> Let me take the time later this week to review the code, which I haven't
>> done in a while...
>>
> 
> When you get a chance to review, please keep in mind that the latest
> version is v12 (from 08.Dec). The same is also available in linux-next
> with no reported issues.

The dependencies for this patchset have been already merged in v5.0-rc1,
so i was wondering if this can still go into -rc2? Various patches that
use this API are already posted and having it sooner will make dealing
with dependencies and merge paths a bit easier during the next merge
window. Or i can just rebase and resend everything targeting v5.1.

Thanks,
Georgi

On Thu, Jan 10, 2019 at 04:19:14PM +0200, Georgi Djakov wrote:
> Hi Greg,
> 
> On 12/17/18 13:17, Georgi Djakov wrote:
> > Hi Greg,
> > 
> > On 12/11/18 08:58, Greg Kroah-Hartman wrote:
> >> On Mon, Dec 10, 2018 at 04:50:00PM +0200, Georgi Djakov wrote:
> >>> On 12/10/18 13:00, Rafael J. Wysocki wrote:
> >>>> On Mon, Dec 10, 2018 at 11:18 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
> >>>>>
> >>>>> Hi Rafael,
> >>>>>
> >>>>> On 12/10/18 11:04, Rafael J. Wysocki wrote:
> >>>>>> On Thu, Dec 6, 2018 at 3:55 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >>>>>>>
> >>>>>>> On Wed, Dec 05, 2018 at 12:41:35PM -0800, Evan Green wrote:
> >>>>>>>> On Tue, Nov 27, 2018 at 10:03 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
> >>>>>>>>>
> >>>>>>>>> Modern SoCs have multiple processors and various dedicated cores (video, gpu,
> >>>>>>>>> graphics, modem). These cores are talking to each other and can generate a
> >>>>>>>>> lot of data flowing through the on-chip interconnects. These interconnect
> >>>>>>>>> buses could form different topologies such as crossbar, point to point buses,
> >>>>>>>>> hierarchical buses or use the network-on-chip concept.
> >>>>>>>>>
> >>>>>>>>> These buses have been sized usually to handle use cases with high data
> >>>>>>>>> throughput but it is not necessary all the time and consume a lot of power.
> >>>>>>>>> Furthermore, the priority between masters can vary depending on the running
> >>>>>>>>> use case like video playback or CPU intensive tasks.
> >>>>>>>>>
> >>>>>>>>> Having an API to control the requirement of the system in terms of bandwidth
> >>>>>>>>> and QoS, so we can adapt the interconnect configuration to match those by
> >>>>>>>>> scaling the frequencies, setting link priority and tuning QoS parameters.
> >>>>>>>>> This configuration can be a static, one-time operation done at boot for some
> >>>>>>>>> platforms or a dynamic set of operations that happen at run-time.
> >>>>>>>>>
> >>>>>>>>> This patchset introduce a new API to get the requirement and configure the
> >>>>>>>>> interconnect buses across the entire chipset to fit with the current demand.
> >>>>>>>>> The API is NOT for changing the performance of the endpoint devices, but only
> >>>>>>>>> the interconnect path in between them.
> >>>>>>>>
> >>>>>>>> For what it's worth, we are ready to land this in Chrome OS. I think
> >>>>>>>> this series has been very well discussed and reviewed, hasn't changed
> >>>>>>>> much in the last few spins, and is in good enough shape to use as a
> >>>>>>>> base for future patches. Georgi's also done a great job reaching out
> >>>>>>>> to other SoC vendors, and there appears to be enough consensus that
> >>>>>>>> this framework will be usable by more than just Qualcomm. There are
> >>>>>>>> also several drivers out on the list trying to add patches to use this
> >>>>>>>> framework, with more to come, so it made sense (to us) to get this
> >>>>>>>> base framework nailed down. In my experiments this is an important
> >>>>>>>> piece of the overall power management story, especially on systems
> >>>>>>>> that are mostly idle.
> >>>>>>>>
> >>>>>>>> I'll continue to track changes to this series and we will ultimately
> >>>>>>>> reconcile with whatever happens upstream, but I thought it was worth
> >>>>>>>> sending this note to express our "thumbs up" towards this framework.
> >>>>>>>
> >>>>>>> Looks like a v11 will be forthcoming, so I'll wait for that one to apply
> >>>>>>> it to the tree if all looks good.
> >>>>>>
> >>>>>> I'm honestly not sure if it is ready yet.
> >>>>>>
> >>>>>> New versions are coming on and on, which may make such an impression,
> >>>>>> but we had some discussion on it at the LPC and some serious questions
> >>>>>> were asked during it, for instance regarding the DT binding introduced
> >>>>>> here.  I'm not sure how this particular issue has been addressed here,
> >>>>>> for example.
> >>>>>
> >>>>> There have been no changes in bindings since v4 (other than squashing
> >>>>> consumer and provider bindings into a single patch and fixing typos).
> >>>>>
> >>>>> The last DT comment was on v9 [1] where Rob wanted confirmation from
> >>>>> other SoC vendors that this works for them too. And now we have that
> >>>>> confirmation and there are patches posted on the list [2].
> >>>>
> >>>> OK
> >>>>
> >>>>> The second thing (also discussed at LPC) was about possible cases where
> >>>>> some consumer drivers can't calculate how much bandwidth they actually
> >>>>> need and how to address that. The proposal was to extend the OPP
> >>>>> bindings with one more property, but this is not part of this patchset.
> >>>>> It is a future step that needs more discussion on the mailing list. If a
> >>>>> driver really needs some bandwidth data now, it should be put into the
> >>>>> driver and not in DT. After we have enough consumers, we can discuss
> >>>>> again if it makes sense to extract something into DT or not.
> >>>>
> >>>> That's fine by me.
> >>>>
> >>>> Admittedly, I have some reservations regarding the extent to which
> >>>> this approach will turn out to be useful in practice, but I guess as
> >>>> long as there is enough traction, the best way to find out it to try
> >>>> and see. :-)
> >>>>
> >>>> From now on I will assume that this series is going to be applied by Greg.
> >>>
> >>> That was the initial idea, but the problem is that there is a recent
> >>> change in the cmd_db API (needed by the sdm845 provider driver), which
> >>> is going through arm-soc/qcom/drivers. So either Greg pulls also the
> >>> qcom-drivers-for-4.21 tag from Andy or the whole series goes via Olof
> >>> and Arnd. Maybe there are other options. I don't have any preference and
> >>> don't want to put extra burden on any maintainers, so i am ok with what
> >>> they prefer.
> >>
> >> Let me take the time later this week to review the code, which I haven't
> >> done in a while...
> >>
> > 
> > When you get a chance to review, please keep in mind that the latest
> > version is v12 (from 08.Dec). The same is also available in linux-next
> > with no reported issues.
> 
> The dependencies for this patchset have been already merged in v5.0-rc1,
> so i was wondering if this can still go into -rc2? Various patches that
> use this API are already posted and having it sooner will make dealing
> with dependencies and merge paths a bit easier during the next merge
> window. Or i can just rebase and resend everything targeting v5.1.

We can't add new features after -rc1, sorry.

Please rebase and resend to target 5.1

thanks,

greg k-h

On 1/10/19 18:29, Greg Kroah-Hartman wrote:
> On Thu, Jan 10, 2019 at 04:19:14PM +0200, Georgi Djakov wrote:
>> Hi Greg,
>>
>> On 12/17/18 13:17, Georgi Djakov wrote:
>>> Hi Greg,
>>>
>>> On 12/11/18 08:58, Greg Kroah-Hartman wrote:
>>>> On Mon, Dec 10, 2018 at 04:50:00PM +0200, Georgi Djakov wrote:
>>>>> On 12/10/18 13:00, Rafael J. Wysocki wrote:
>>>>>> On Mon, Dec 10, 2018 at 11:18 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>>>>>>
>>>>>>> Hi Rafael,
>>>>>>>
>>>>>>> On 12/10/18 11:04, Rafael J. Wysocki wrote:
>>>>>>>> On Thu, Dec 6, 2018 at 3:55 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>>>>>>>>>
>>>>>>>>> On Wed, Dec 05, 2018 at 12:41:35PM -0800, Evan Green wrote:
>>>>>>>>>> On Tue, Nov 27, 2018 at 10:03 AM Georgi Djakov <georgi.djakov@linaro.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Modern SoCs have multiple processors and various dedicated cores (video, gpu,
>>>>>>>>>>> graphics, modem). These cores are talking to each other and can generate a
>>>>>>>>>>> lot of data flowing through the on-chip interconnects. These interconnect
>>>>>>>>>>> buses could form different topologies such as crossbar, point to point buses,
>>>>>>>>>>> hierarchical buses or use the network-on-chip concept.
>>>>>>>>>>>
>>>>>>>>>>> These buses have been sized usually to handle use cases with high data
>>>>>>>>>>> throughput but it is not necessary all the time and consume a lot of power.
>>>>>>>>>>> Furthermore, the priority between masters can vary depending on the running
>>>>>>>>>>> use case like video playback or CPU intensive tasks.
>>>>>>>>>>>
>>>>>>>>>>> Having an API to control the requirement of the system in terms of bandwidth
>>>>>>>>>>> and QoS, so we can adapt the interconnect configuration to match those by
>>>>>>>>>>> scaling the frequencies, setting link priority and tuning QoS parameters.
>>>>>>>>>>> This configuration can be a static, one-time operation done at boot for some
>>>>>>>>>>> platforms or a dynamic set of operations that happen at run-time.
>>>>>>>>>>>
>>>>>>>>>>> This patchset introduce a new API to get the requirement and configure the
>>>>>>>>>>> interconnect buses across the entire chipset to fit with the current demand.
>>>>>>>>>>> The API is NOT for changing the performance of the endpoint devices, but only
>>>>>>>>>>> the interconnect path in between them.
>>>>>>>>>>
>>>>>>>>>> For what it's worth, we are ready to land this in Chrome OS. I think
>>>>>>>>>> this series has been very well discussed and reviewed, hasn't changed
>>>>>>>>>> much in the last few spins, and is in good enough shape to use as a
>>>>>>>>>> base for future patches. Georgi's also done a great job reaching out
>>>>>>>>>> to other SoC vendors, and there appears to be enough consensus that
>>>>>>>>>> this framework will be usable by more than just Qualcomm. There are
>>>>>>>>>> also several drivers out on the list trying to add patches to use this
>>>>>>>>>> framework, with more to come, so it made sense (to us) to get this
>>>>>>>>>> base framework nailed down. In my experiments this is an important
>>>>>>>>>> piece of the overall power management story, especially on systems
>>>>>>>>>> that are mostly idle.
>>>>>>>>>>
>>>>>>>>>> I'll continue to track changes to this series and we will ultimately
>>>>>>>>>> reconcile with whatever happens upstream, but I thought it was worth
>>>>>>>>>> sending this note to express our "thumbs up" towards this framework.
>>>>>>>>>
>>>>>>>>> Looks like a v11 will be forthcoming, so I'll wait for that one to apply
>>>>>>>>> it to the tree if all looks good.
>>>>>>>>
>>>>>>>> I'm honestly not sure if it is ready yet.
>>>>>>>>
>>>>>>>> New versions are coming on and on, which may make such an impression,
>>>>>>>> but we had some discussion on it at the LPC and some serious questions
>>>>>>>> were asked during it, for instance regarding the DT binding introduced
>>>>>>>> here.  I'm not sure how this particular issue has been addressed here,
>>>>>>>> for example.
>>>>>>>
>>>>>>> There have been no changes in bindings since v4 (other than squashing
>>>>>>> consumer and provider bindings into a single patch and fixing typos).
>>>>>>>
>>>>>>> The last DT comment was on v9 [1] where Rob wanted confirmation from
>>>>>>> other SoC vendors that this works for them too. And now we have that
>>>>>>> confirmation and there are patches posted on the list [2].
>>>>>>
>>>>>> OK
>>>>>>
>>>>>>> The second thing (also discussed at LPC) was about possible cases where
>>>>>>> some consumer drivers can't calculate how much bandwidth they actually
>>>>>>> need and how to address that. The proposal was to extend the OPP
>>>>>>> bindings with one more property, but this is not part of this patchset.
>>>>>>> It is a future step that needs more discussion on the mailing list. If a
>>>>>>> driver really needs some bandwidth data now, it should be put into the
>>>>>>> driver and not in DT. After we have enough consumers, we can discuss
>>>>>>> again if it makes sense to extract something into DT or not.
>>>>>>
>>>>>> That's fine by me.
>>>>>>
>>>>>> Admittedly, I have some reservations regarding the extent to which
>>>>>> this approach will turn out to be useful in practice, but I guess as
>>>>>> long as there is enough traction, the best way to find out it to try
>>>>>> and see. :-)
>>>>>>
>>>>>> From now on I will assume that this series is going to be applied by Greg.
>>>>>
>>>>> That was the initial idea, but the problem is that there is a recent
>>>>> change in the cmd_db API (needed by the sdm845 provider driver), which
>>>>> is going through arm-soc/qcom/drivers. So either Greg pulls also the
>>>>> qcom-drivers-for-4.21 tag from Andy or the whole series goes via Olof
>>>>> and Arnd. Maybe there are other options. I don't have any preference and
>>>>> don't want to put extra burden on any maintainers, so i am ok with what
>>>>> they prefer.
>>>>
>>>> Let me take the time later this week to review the code, which I haven't
>>>> done in a while...
>>>>
>>>
>>> When you get a chance to review, please keep in mind that the latest
>>> version is v12 (from 08.Dec). The same is also available in linux-next
>>> with no reported issues.
>>
>> The dependencies for this patchset have been already merged in v5.0-rc1,
>> so i was wondering if this can still go into -rc2? Various patches that
>> use this API are already posted and having it sooner will make dealing
>> with dependencies and merge paths a bit easier during the next merge
>> window. Or i can just rebase and resend everything targeting v5.1.
> 
> We can't add new features after -rc1, sorry.
> 
> Please rebase and resend to target 5.1

Ok, i was expecting that. Thanks for confirming!

BR,
Georgi