From: Georgi Djakov <georgi.djakov@linaro.org>
To: Matthias Kaehlcke <mka@chromium.org>
Cc: linux-pm@vger.kernel.org, gregkh@linuxfoundation.org,
rjw@rjwysocki.net, robh+dt@kernel.org, mturquette@baylibre.com,
khilman@baylibre.com, vincent.guittot@linaro.org,
skannan@codeaurora.org, bjorn.andersson@linaro.org,
amit.kucheria@linaro.org, seansw@qti.qualcomm.com,
daidavid1@codeaurora.org, evgreen@chromium.org,
mark.rutland@arm.com, lorenzo.pieralisi@arm.com,
abailon@baylibre.com, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v5 1/8] interconnect: Add generic on-chip interconnect API
Date: Sun, 1 Jul 2018 14:06:21 +0300 [thread overview]
Message-ID: <d52877d2-359f-6c79-01b9-739d0b2733ef@linaro.org> (raw)
In-Reply-To: <20180626233427.GR129942@google.com>
Hi Matthias,
Thanks for reviewing!
On 06/27/2018 02:34 AM, Matthias Kaehlcke wrote:
> Hi Georgi,
>
> On Wed, Jun 20, 2018 at 03:11:34PM +0300, Georgi Djakov wrote:
>> This patch introduce a new API to get requirements and configure the
>
> nit: s/introduce/introduces/
Thanks!
[..]
>> + if (found) {
>> + struct icc_path *path = path_allocate(dst, depth);
>> +
>> + if (IS_ERR(path))
>> + return path;
>> +
>> + /* initialize the path */
>> + for (i = 0; i < path->num_nodes; i++) {
>> + node = path->reqs[i].node;
>> + path->reqs[i].dev = dev;
>> + node->provider->users++;
>
> nit: doing the assignment of path->reqs[i].dev before assiging 'node'
> or after incrementing the 'users' would slightly improve readability.
Ok, will re-factor this a bit.
>> +static int apply_constraints(struct icc_path *path)
>> +{
>> + struct icc_node *next, *prev = NULL;
>> + int ret = 0;
>> + 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;
>> +
>> + aggregate_provider(p);
>> +
>> + if (p->set) {
>> + /* set the constraints */
>> + ret = p->set(prev, next, p->avg_bw, p->peak_bw);
>> + }
>
> remove curly brackets
>
> EDIT: actually the condition can be removed, icc_provider_add() fails
> when p->set is NULL.
Agree!
>
>> +int icc_set(struct icc_path *path, u32 avg_bw, u32 peak_bw)
>> +{
>> + struct icc_node *node;
>> + struct icc_provider *p;
>> + size_t i;
>> + int ret = 0;
>
> initialization is not necessary
>
Ok.
>> +struct icc_path *icc_get(struct device *dev, const int src_id, const int dst_id)
>> +{
>> + struct icc_node *src, *dst;
>> + struct icc_path *path = ERR_PTR(-EPROBE_DEFER);
>> +
>> + src = node_find(src_id);
>> + if (!src) {
>> + dev_err(dev, "%s: invalid src=%d\n", __func__, src_id);
>> + goto out;
>> + }
>> +
>> + dst = node_find(dst_id);
>> + if (!dst) {
>> + dev_err(dev, "%s: invalid dst=%d\n", __func__, dst_id);
>> + goto out;
>> + }
>> +
>> + mutex_lock(&icc_lock);
>> + path = path_find(dev, src, dst);
>> + mutex_unlock(&icc_lock);
>> + if (IS_ERR(path)) {
>> + dev_err(dev, "%s: invalid path=%ld\n", __func__, PTR_ERR(path));
>> + goto out;
>
> this goto isn't really needed
Ok.
>> +struct icc_node *icc_node_create(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;
>> + }
>> +
>> + mutex_lock(&icc_lock);
>> +
>> + id = idr_alloc(&icc_idr, node, id, id + 1, GFP_KERNEL);
>> + if (WARN(id < 0, "couldn't get idr")) {
>
> kfree(node);
Thanks!
>> +int icc_node_add(struct icc_node *node, struct icc_provider *provider)
>> +{
>> + mutex_lock(&icc_lock);
>> +
>> + node->provider = provider;
>> + list_add(&node->node_list, &provider->nodes);
>> +
>> + mutex_unlock(&icc_lock);
>> +
>> + return 0;
>> +}
>
> The function returns always 0. Should probably be void so callers
> don't add pointless checks of the return value.
Agree, will change it!
>> +int icc_provider_add(struct icc_provider *provider)
>> +{
>> + if (WARN_ON(!provider->set))
>> + return -EINVAL;
>> +
>> + mutex_init(&icc_lock);
>
> Shouldn't this be mutex_lock()?
Yes, right!
>> +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_careful(&provider->nodes)) {
>> + pr_warn("interconnect provider still has nodes\n");
>> + mutex_unlock(&icc_lock);
>> + return -EEXIST;
>> + }
>
> Could this be just list_empty()? If I didn't miss something icc_lock
> is held in all paths that change p->nodes (assuming that all changes
> should be done through the interfaces in this file).
It could be. Will update it. I just always want to be careful!
> Actually this check will always fail if icc_node_add() was called for
> this provider, it doesn't seem nodes are ever removed.
>
The provider driver is responsible for the node removal.
Thanks,
Georgi
next prev parent reply other threads:[~2018-07-01 11:06 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-20 12:11 [PATCH v5 0/8] Introduce on-chip interconnect API Georgi Djakov
2018-06-20 12:11 ` [PATCH v5 1/8] interconnect: Add generic " Georgi Djakov
2018-06-26 20:57 ` Evan Green
2018-06-26 21:58 ` Matthias Kaehlcke
2018-06-27 0:54 ` Rob Clark
2018-07-01 11:03 ` Georgi Djakov
2018-06-26 23:34 ` Matthias Kaehlcke
2018-07-01 11:06 ` Georgi Djakov [this message]
2018-06-27 6:19 ` Vincent Guittot
2018-07-01 11:09 ` Georgi Djakov
2018-07-02 7:23 ` Vincent Guittot
2018-06-20 12:11 ` [PATCH v5 2/8] dt-bindings: Introduce interconnect provider bindings Georgi Djakov
2018-06-20 12:11 ` [PATCH v5 3/8] interconnect: Add debugfs support Georgi Djakov
2018-06-20 12:11 ` [PATCH v5 4/8] interconnect: qcom: Add RPM communication Georgi Djakov
2018-06-26 20:47 ` Evan Green
2018-07-01 11:16 ` Georgi Djakov
2018-06-27 0:55 ` Matthias Kaehlcke
2018-07-01 11:18 ` Georgi Djakov
2018-06-20 12:11 ` [PATCH v5 5/8] dt-bindings: interconnect: Document qcom,msm8916 NoC bindings Georgi Djakov
2018-06-20 12:11 ` [PATCH v5 6/8] interconnect: qcom: Add msm8916 interconnect provider driver Georgi Djakov
2018-06-26 20:48 ` Evan Green
2018-07-01 12:12 ` Georgi Djakov
2018-07-02 17:08 ` Evan Green
2018-06-20 12:11 ` [PATCH v5 7/8] dt-bindings: Introduce interconnect consumers bindings Georgi Djakov
2018-06-20 12:11 ` [PATCH v5 8/8] interconnect: Allow endpoints translation via DT Georgi Djakov
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=d52877d2-359f-6c79-01b9-739d0b2733ef@linaro.org \
--to=georgi.djakov@linaro.org \
--cc=abailon@baylibre.com \
--cc=amit.kucheria@linaro.org \
--cc=bjorn.andersson@linaro.org \
--cc=daidavid1@codeaurora.org \
--cc=evgreen@chromium.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=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=mka@chromium.org \
--cc=mturquette@baylibre.com \
--cc=rjw@rjwysocki.net \
--cc=robh+dt@kernel.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;
as well as URLs for NNTP newsgroup(s).