There is a repeated pattern in multiple drivers where they want to switch
the bandwidth between zero and some other value. This is happening often
in the suspend/resume callbacks. Let's add helper functions to enable and
disable the path, so that callers don't have to take care of remembering
the bandwidth values and handle this in the framework instead.
With this patch the users can call icc_disable() and icc_enable() to lower
their bandwidth request to zero and then restore it back to it's previous
value.
Suggested-by: Evan Green <[email protected]>
Suggested-by: Bjorn Andersson <[email protected]>
Signed-off-by: Georgi Djakov <[email protected]>
---
drivers/interconnect/core.c | 50 ++++++++++++++++++++++++++++++++-
drivers/interconnect/internal.h | 2 ++
include/linux/interconnect.h | 12 ++++++++
3 files changed, 63 insertions(+), 1 deletion(-)
diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index 2c6515e3ecf1..6af68e506ac2 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -158,6 +158,7 @@ static struct icc_path *path_init(struct device *dev, struct icc_node *dst,
hlist_add_head(&path->reqs[i].req_node, &node->req_list);
path->reqs[i].node = node;
path->reqs[i].dev = dev;
+ path->reqs[i].enabled = true;
/* reference to previous node was saved during path traversal */
node = node->reverse;
}
@@ -249,9 +250,12 @@ static int aggregate_requests(struct icc_node *node)
if (p->pre_aggregate)
p->pre_aggregate(node);
- hlist_for_each_entry(r, &node->req_list, req_node)
+ hlist_for_each_entry(r, &node->req_list, req_node) {
+ if (!r->enabled)
+ continue;
p->aggregate(node, r->tag, r->avg_bw, r->peak_bw,
&node->avg_bw, &node->peak_bw);
+ }
return 0;
}
@@ -546,6 +550,50 @@ int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw)
}
EXPORT_SYMBOL_GPL(icc_set_bw);
+int icc_disable(struct icc_path *path)
+{
+ int i;
+
+ if (!path)
+ return 0;
+
+ if (WARN_ON(IS_ERR(path) || !path->num_nodes))
+ return -EINVAL;
+
+ mutex_lock(&icc_lock);
+
+ for (i = 0; i < path->num_nodes; i++)
+ path->reqs[i].enabled = false;
+
+ mutex_unlock(&icc_lock);
+
+ return icc_set_bw(path, path->reqs[0].avg_bw,
+ path->reqs[0].peak_bw);
+}
+EXPORT_SYMBOL_GPL(icc_disable);
+
+int icc_enable(struct icc_path *path)
+{
+ int i;
+
+ if (!path)
+ return 0;
+
+ if (WARN_ON(IS_ERR(path) || !path->num_nodes))
+ return -EINVAL;
+
+ mutex_lock(&icc_lock);
+
+ for (i = 0; i < path->num_nodes; i++)
+ path->reqs[i].enabled = true;
+
+ mutex_unlock(&icc_lock);
+
+ return icc_set_bw(path, path->reqs[0].avg_bw,
+ path->reqs[0].peak_bw);
+}
+EXPORT_SYMBOL_GPL(icc_enable);
+
/**
* icc_get() - return a handle for path between two endpoints
* @dev: the device requesting the path
diff --git a/drivers/interconnect/internal.h b/drivers/interconnect/internal.h
index bf18cb7239df..f5f82a5c939e 100644
--- a/drivers/interconnect/internal.h
+++ b/drivers/interconnect/internal.h
@@ -14,6 +14,7 @@
* @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
+ * @enabled: indicates whether the path with this request is enabled
* @tag: path tag (optional)
* @avg_bw: an integer describing the average bandwidth in kBps
* @peak_bw: an integer describing the peak bandwidth in kBps
@@ -22,6 +23,7 @@ struct icc_req {
struct hlist_node req_node;
struct icc_node *node;
struct device *dev;
+ bool enabled;
u32 tag;
u32 avg_bw;
u32 peak_bw;
diff --git a/include/linux/interconnect.h b/include/linux/interconnect.h
index d70a914cba11..21dd232d81ff 100644
--- a/include/linux/interconnect.h
+++ b/include/linux/interconnect.h
@@ -29,6 +29,8 @@ 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_disable(struct icc_path *path);
+int icc_enable(struct icc_path *path);
int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw);
void icc_set_tag(struct icc_path *path, u32 tag);
@@ -50,6 +52,16 @@ static inline void icc_put(struct icc_path *path)
{
}
+static inline int icc_disable(struct icc_path *path)
+{
+ return 0;
+}
+
+static inline int icc_enable(struct icc_path *path)
+{
+ return 0;
+}
+
static inline int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw)
{
return 0;
Hi Georgi,
On Tue, Apr 28, 2020 at 12:16:50PM +0300, Georgi Djakov wrote:
> There is a repeated pattern in multiple drivers where they want to switch
> the bandwidth between zero and some other value. This is happening often
> in the suspend/resume callbacks. Let's add helper functions to enable and
> disable the path, so that callers don't have to take care of remembering
> the bandwidth values and handle this in the framework instead.
>
> With this patch the users can call icc_disable() and icc_enable() to lower
> their bandwidth request to zero and then restore it back to it's previous
> value.
>
> Suggested-by: Evan Green <[email protected]>
> Suggested-by: Bjorn Andersson <[email protected]>
> Signed-off-by: Georgi Djakov <[email protected]>
> ---
> drivers/interconnect/core.c | 50 ++++++++++++++++++++++++++++++++-
> drivers/interconnect/internal.h | 2 ++
> include/linux/interconnect.h | 12 ++++++++
> 3 files changed, 63 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
> index 2c6515e3ecf1..6af68e506ac2 100644
> --- a/drivers/interconnect/core.c
> +++ b/drivers/interconnect/core.c
> @@ -158,6 +158,7 @@ static struct icc_path *path_init(struct device *dev, struct icc_node *dst,
> hlist_add_head(&path->reqs[i].req_node, &node->req_list);
> path->reqs[i].node = node;
> path->reqs[i].dev = dev;
> + path->reqs[i].enabled = true;
> /* reference to previous node was saved during path traversal */
> node = node->reverse;
> }
> @@ -249,9 +250,12 @@ static int aggregate_requests(struct icc_node *node)
> if (p->pre_aggregate)
> p->pre_aggregate(node);
>
> - hlist_for_each_entry(r, &node->req_list, req_node)
> + hlist_for_each_entry(r, &node->req_list, req_node) {
> + if (!r->enabled)
> + continue;
> p->aggregate(node, r->tag, r->avg_bw, r->peak_bw,
> &node->avg_bw, &node->peak_bw);
> + }
>
> return 0;
> }
> @@ -546,6 +550,50 @@ int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw)
> }
> EXPORT_SYMBOL_GPL(icc_set_bw);
>
> +int icc_disable(struct icc_path *path)
> +{
> + int i;
> +
> + if (!path)
> + return 0;
> +
> + if (WARN_ON(IS_ERR(path) || !path->num_nodes))
> + return -EINVAL;
> +
> + mutex_lock(&icc_lock);
> +
> + for (i = 0; i < path->num_nodes; i++)
> + path->reqs[i].enabled = false;
> +
> + mutex_unlock(&icc_lock);
> +
> + return icc_set_bw(path, path->reqs[0].avg_bw,
> + path->reqs[0].peak_bw);
> +}
> +EXPORT_SYMBOL_GPL(icc_disable);
> +
> +int icc_enable(struct icc_path *path)
> +{
> + int i;
> +
> + if (!path)
> + return 0;
> +
> + if (WARN_ON(IS_ERR(path) || !path->num_nodes))
> + return -EINVAL;
> +
> + mutex_lock(&icc_lock);
> +
> + for (i = 0; i < path->num_nodes; i++)
> + path->reqs[i].enabled = true;
> +
> + mutex_unlock(&icc_lock);
> +
> + return icc_set_bw(path, path->reqs[0].avg_bw,
> + path->reqs[0].peak_bw);
> +}
The two functions are identical except for the assignment of the 'enabled'
flags. You could add a helper _icc_enable(struct icc_path *path, bool enable)
and call it from icc_enable/disable().
Hi Matthias,
On 4/28/20 18:28, Matthias Kaehlcke wrote:
> Hi Georgi,
>
> On Tue, Apr 28, 2020 at 12:16:50PM +0300, Georgi Djakov wrote:
>> There is a repeated pattern in multiple drivers where they want to switch
>> the bandwidth between zero and some other value. This is happening often
>> in the suspend/resume callbacks. Let's add helper functions to enable and
>> disable the path, so that callers don't have to take care of remembering
>> the bandwidth values and handle this in the framework instead.
>>
>> With this patch the users can call icc_disable() and icc_enable() to lower
>> their bandwidth request to zero and then restore it back to it's previous
>> value.
>>
>> Suggested-by: Evan Green <[email protected]>
>> Suggested-by: Bjorn Andersson <[email protected]>
>> Signed-off-by: Georgi Djakov <[email protected]>
[..]
>> +
>> + return icc_set_bw(path, path->reqs[0].avg_bw,
>> + path->reqs[0].peak_bw);
>> +}
>
> The two functions are identical except for the assignment of the 'enabled'
> flags. You could add a helper _icc_enable(struct icc_path *path, bool enable)
> and call it from icc_enable/disable().
>
Yes, indeed! Will send a v2. Thank you!
BR,
Georgi
Hi Georgi,
On 4/28/2020 2:46 PM, Georgi Djakov wrote:
> There is a repeated pattern in multiple drivers where they want to switch
> the bandwidth between zero and some other value. This is happening often
> in the suspend/resume callbacks. Let's add helper functions to enable and
> disable the path, so that callers don't have to take care of remembering
> the bandwidth values and handle this in the framework instead.
>
> With this patch the users can call icc_disable() and icc_enable() to lower
> their bandwidth request to zero and then restore it back to it's previous
> value.
Thanks for this patch.
Are you planning to add bulk versions of icc_enable/disable APIs?
Regards,
Akash
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na Linux Foundation Collaborative Project
On 5/4/20 11:57, Akash Asthana wrote:
> Hi Georgi,
>
> On 4/28/2020 2:46 PM, Georgi Djakov wrote:
>> There is a repeated pattern in multiple drivers where they want to switch
>> the bandwidth between zero and some other value. This is happening often
>> in the suspend/resume callbacks. Let's add helper functions to enable and
>> disable the path, so that callers don't have to take care of remembering
>> the bandwidth values and handle this in the framework instead.
>>
>> With this patch the users can call icc_disable() and icc_enable() to lower
>> their bandwidth request to zero and then restore it back to it's previous
>> value.
>
> Thanks for this patch.
>
> Are you planning to add bulk versions of icc_enable/disable APIs?
>
Yes, i have already a bunch of patches that add bulk versions for most
of the API functions. Will post them on the list.
Thanks,
Georgi