From: Georgi Djakov <georgi.djakov@linaro.org>
To: Saravana Kannan <skannan@codeaurora.org>
Cc: linux-pm@vger.kernel.org, rjw@rjwysocki.net, robh+dt@kernel.org,
gregkh@linuxfoundation.org, khilman@baylibre.com,
mturquette@baylibre.com, vincent.guittot@linaro.org,
sboyd@codeaurora.org, andy.gross@linaro.org,
seansw@qti.qualcomm.com, davidai@quicinc.com,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org
Subject: Re: [RFC v0 1/2] interconnect: Add generic interconnect controller API
Date: Tue, 14 Mar 2017 17:39:13 +0200 [thread overview]
Message-ID: <df0f892b-3318-8316-eafb-07e55ddc5406@linaro.org> (raw)
In-Reply-To: <58B8CFDA.3080303@codeaurora.org>
On 03/03/2017 04:07 AM, Saravana Kannan wrote:
> On 03/01/2017 10:22 AM, Georgi Djakov wrote:
>> This patch introduce a new API to get the requirement and configure the
>> interconnect buses across the entire chipset to fit with the current
>> demand.
>>
[..]
>> +int interconnect_set(struct interconnect_path *path, u32 bandwidth)
>> +{
>> + struct interconnect_node *node;
>> +
>> + list_for_each_entry(node, &path->node_list, search_list) {
>> + if (node->icp->ops->set)
>> + node->icp->ops->set(node, bandwidth);
>
> This ops needs to take a "source" and "dest" input and you'll need to
> pass in the prev/next nodes of each "node" in this list. This is needed
> so that each interconnect know the local source/destination and can make
> the aggregation decisions correctly based on the internal implementation
> of the interconnect. For the first and last nodes in the list, the
> source and destination nodes can be NULL, respectively.
I agree. Updated.
>
>> + }
>> +
>> + return 0;
>> +}
>> +
[..]
>> +void interconnect_put(struct interconnect_path *path)
>> +{
>> + struct interconnect_node *node;
>> + struct icn_qos *req;
>> + struct hlist_node *tmp;
>> +
>> + if (IS_ERR(path))
>> + return;
>> +
>> + list_for_each_entry(node, &path->node_list, search_list) {
>> + hlist_for_each_entry_safe(req, tmp, &node->qos_list, node) {
>> + if (req->path == path) {
>> + hlist_del(&req->node);
>> + kfree(req);
>> + }
>
> Should we go through and remove any bandwidth votes that were made on
> this path before we free it?
>
Yes, thanks! We should remove the constraints from the path, then
update the nodes and after that free the memory.
>> + }
>> + }
>> +
>> + kfree(path);
>> +}
>> +EXPORT_SYMBOL_GPL(interconnect_put);
>> +
>> +int interconnect_add_provider(struct icp *icp)
>> +{
>> + struct interconnect_node *node;
>> +
>> + WARN(!icp->ops->xlate, "%s: .xlate is not implemented\n", __func__);
>> + WARN(!icp->ops->set, "%s: .set is not implemented\n", __func__);
>> +
>> + mutex_lock(&interconnect_provider_list_mutex);
>> + list_add(&icp->icp_list, &interconnect_provider_list);
>> + mutex_unlock(&interconnect_provider_list_mutex);
>> +
>> + list_for_each_entry(node, &icp->nodes, icn_list) {
>> + INIT_HLIST_HEAD(&node->qos_list);
>> + }
>> +
>> + dev_info(icp->dev, "added interconnect provider %s\n", icp->name);
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(interconnect_add_provider);
>> +
>> +int interconnect_del_provider(struct icp *icp)
>> +{
>> + mutex_lock(&interconnect_provider_list_mutex);
>> + of_node_put(icp->of_node);
>> + list_del(&icp->icp_list);
>
> If there's a path with an active vote, we should probably return a
> -EBUSY to prevent deleting a provider that's actively used?
>
Thanks, sounds good. Will do.
BR,
Georgi
next prev parent reply other threads:[~2017-03-14 15:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-01 18:22 [RFC v0 0/2] Introduce on-chip interconnect API Georgi Djakov
2017-03-01 18:22 ` [RFC v0 1/2] interconnect: Add generic interconnect controller API Georgi Djakov
2017-03-02 23:53 ` Randy Dunlap
2017-03-14 15:35 ` Georgi Djakov
2017-03-03 2:07 ` Saravana Kannan
2017-03-14 15:39 ` Georgi Djakov [this message]
2017-03-09 9:56 ` Lucas Stach
2017-03-14 15:45 ` Georgi Djakov
2017-03-23 1:21 ` Michael Turquette
2017-03-23 15:21 ` Georgi Djakov
2017-03-01 18:22 ` [RFC v0 2/2] interconnect: Add Qualcomm msm8916 interconnect provider driver Georgi Djakov
2017-03-03 6:21 ` [RFC v0 0/2] Introduce on-chip interconnect API Rob Herring
2017-03-14 15:41 ` Georgi Djakov
2017-03-23 3:32 ` Moritz Fischer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=df0f892b-3318-8316-eafb-07e55ddc5406@linaro.org \
--to=georgi.djakov@linaro.org \
--cc=andy.gross@linaro.org \
--cc=davidai@quicinc.com \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=khilman@baylibre.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=rjw@rjwysocki.net \
--cc=robh+dt@kernel.org \
--cc=sboyd@codeaurora.org \
--cc=seansw@qti.qualcomm.com \
--cc=skannan@codeaurora.org \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome