Message ID | 20181127180349.29997-1-georgi.djakov@linaro.org |
---|---|
Headers | show |
Series | Introduce on-chip interconnect API | expand |
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