linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chanwoo Choi <cwchoi00@gmail.com>
To: Saravana Kannan <saravanak@google.com>
Cc: MyungJoo Ham <myungjoo.ham@samsung.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Chanwoo Choi <cw00.choi@samsung.com>,
	Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>,
	Stephen Boyd <sboyd@kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	kernel-team@android.com, Linux PM list <linux-pm@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 2/3] OPP: Add function to look up required OPP's for a given OPP
Date: Sat, 22 Jun 2019 20:49:59 +0900	[thread overview]
Message-ID: <CAGTfZH18SQXj_2TpUf7iQPzWrZ5RP8-OCb_t6fp7qhuutGWz5A@mail.gmail.com> (raw)
In-Reply-To: <20190622003449.33707-3-saravanak@google.com>

Hi,

Absolutely, I like this approach. I think that it is necessary to make
the connection
between frequencies of devices. But, I have a question on below.

2019년 6월 22일 (토) 오전 9:35, Saravana Kannan <saravanak@google.com>님이 작성:
>
> Add a function that allows looking up required OPPs given a source OPP
> table, destination OPP table and the source OPP.
>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
> ---
>  drivers/opp/core.c     | 54 ++++++++++++++++++++++++++++++++++++++++++
>  include/linux/pm_opp.h | 11 +++++++++
>  2 files changed, 65 insertions(+)
>
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index 74c7bdc6f463..4f7870bffbf8 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -1830,6 +1830,60 @@ void dev_pm_opp_put_genpd_virt_dev(struct opp_table *opp_table,
>                 dev_err(virt_dev, "Failed to find required device entry\n");
>  }
>
> +/**
> + * dev_pm_opp_xlate_opp() - Find required OPP for src_table OPP.
> + * @src_table: OPP table which has dst_table as one of its required OPP table.
> + * @dst_table: Required OPP table of the src_table.
> + * @pstate: OPP of the src_table.
> + *
> + * This function returns the OPP (present in @dst_table) pointed out by the
> + * "required-opps" property of the OPP (present in @src_table).
> + *
> + * The callers are required to call dev_pm_opp_put() for the returned OPP after
> + * use.
> + *
> + * Return: destination table OPP on success, otherwise NULL on errors.
> + */
> +struct dev_pm_opp *dev_pm_opp_xlate_opp(struct opp_table *src_table,
> +                                       struct opp_table *dst_table,
> +                                       struct dev_pm_opp *src_opp)
> +{
> +       struct dev_pm_opp *opp, *dest_opp = NULL;
> +       int i;
> +
> +       if (!src_table || !dst_table || !src_opp)
> +               return NULL;
> +
> +       for (i = 0; i < src_table->required_opp_count; i++) {
> +               if (src_table->required_opp_tables[i]->np == dst_table->np)
> +                       break;
> +       }
> +
> +       if (unlikely(i == src_table->required_opp_count)) {
> +               pr_err("%s: Couldn't find matching OPP table (%p: %p)\n",
> +                      __func__, src_table, dst_table);
> +               return NULL;
> +       }
> +
> +       mutex_lock(&src_table->lock);
> +
> +       list_for_each_entry(opp, &src_table->opp_list, node) {
> +               if (opp == src_opp) {
> +                       dest_opp = opp->required_opps[i];

Correct me if I am wrong. This patch assume that 'i' index is same on between
[1] and [2]. But in order to guarantee this assumption, all OPP entries
in the same opp_table have to have the same number of 'required-opps' properties
and keep the sequence among 'required-opps' entries.

[1] src_table->required_opp_tables[i]->np
[2] opp->required_opps[I];

For example, three OPP entries in the 'parent_bus_opp'
have the different sequence of 'required-opps' and the different
number of 'required-opps'. Is it no problem?

parent_bus_opp: opp_table {
    compatible = "operating-points-v2";

    opp2 {
        opp-hz = /bits/ 64 <200000>;
        required-opps = <&child_bus_a_opp2>, <&child_bus_b_opp2>,
<&child_bus_c_opp2>;
    };

    opp1 {
        opp-hz = /bits/ 64 <200000>;
        // change the sequence between child_bus_b_opp2  and child_bus_c_opp2
        required-opps = <&child_bus_a_opp2>, <&child_bus_c_opp2>,
<&child_bus_b_opp2>
    };

    opp0 {
        opp-hz = /bits/ 64 <200000>;
        // missing 'child_bus_a_opp2'
        required-opps = <&child_bus_c_opp2>, <&child_bus_b_opp2>
    };

}



> +                       dev_pm_opp_get(dest_opp);
> +                       goto unlock;
> +               }
> +       }
> +
> +       pr_err("%s: Couldn't find matching OPP (%p: %p)\n", __func__, src_table,
> +              dst_table);
> +
> +unlock:
> +       mutex_unlock(&src_table->lock);
> +
> +       return dest_opp;
> +}
> +
>  /**
>   * dev_pm_opp_xlate_performance_state() - Find required OPP's pstate for src_table.
>   * @src_table: OPP table which has dst_table as one of its required OPP table.
> diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
> index b150fe97ce5a..bc5c68bdfc8d 100644
> --- a/include/linux/pm_opp.h
> +++ b/include/linux/pm_opp.h
> @@ -134,6 +134,9 @@ void dev_pm_opp_unregister_set_opp_helper(struct opp_table *opp_table);
>  struct opp_table *dev_pm_opp_set_genpd_virt_dev(struct device *dev, struct device *virt_dev, int index);
>  void dev_pm_opp_put_genpd_virt_dev(struct opp_table *opp_table, struct device *virt_dev);
>  int dev_pm_opp_xlate_performance_state(struct opp_table *src_table, struct opp_table *dst_table, unsigned int pstate);
> +struct dev_pm_opp *dev_pm_opp_xlate_opp(struct opp_table *src_table,
> +                                       struct opp_table *dst_table,
> +                                       struct dev_pm_opp *src_opp);
>  int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq);
>  int dev_pm_opp_set_sharing_cpus(struct device *cpu_dev, const struct cpumask *cpumask);
>  int dev_pm_opp_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpumask);
> @@ -307,6 +310,14 @@ static inline int dev_pm_opp_xlate_performance_state(struct opp_table *src_table
>         return -ENOTSUPP;
>  }
>
> +static inline struct dev_pm_opp *dev_pm_opp_xlate_opp(
> +                                               struct opp_table *src_table,
> +                                               struct opp_table *dst_table,
> +                                               struct dev_pm_opp *src_opp)
> +{
> +       return NULL;
> +}
> +
>  static inline int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
>  {
>         return -ENOTSUPP;
> --
> 2.22.0.410.gd8fdbe21b5-goog
>


-- 
Best Regards,
Chanwoo Choi

  reply	other threads:[~2019-06-22 11:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-22  0:34 [PATCH v1 0/3] Add required-opps support to devfreq passive gov Saravana Kannan
2019-06-22  0:34 ` [PATCH v1 1/3] OPP: Allow required-opps even if the device doesn't have power-domains Saravana Kannan
2019-06-22  0:34 ` [PATCH v1 2/3] OPP: Add function to look up required OPP's for a given OPP Saravana Kannan
2019-06-22 11:49   ` Chanwoo Choi [this message]
2019-06-22 21:41     ` Saravana Kannan
2019-06-23  4:27       ` Chanwoo Choi
2019-06-23  6:07         ` Saravana Kannan
2019-06-22  0:34 ` [PATCH v1 3/3] PM / devfreq: Add required OPPs support to passive governor Saravana Kannan
2019-06-22 12:00   ` Chanwoo Choi
2019-06-22 21:45     ` Saravana Kannan
2019-06-24  9:43 ` [PATCH v1 0/3] Add required-opps support to devfreq passive gov Viresh Kumar
2019-06-24 22:17   ` Saravana Kannan
2019-06-25  4:10     ` Viresh Kumar
2019-06-25  5:00       ` Saravana Kannan
2019-06-25  5:22         ` Viresh Kumar
2019-06-25  5:29           ` Saravana Kannan
2019-06-26  6:32             ` Viresh Kumar
2019-06-26 18:10               ` Saravana Kannan
2019-06-28  6:49                 ` Viresh Kumar
2019-06-28 20:26                   ` Saravana Kannan
2019-07-11 23:16                     ` Saravana Kannan

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=CAGTfZH18SQXj_2TpUf7iQPzWrZ5RP8-OCb_t6fp7qhuutGWz5A@mail.gmail.com \
    --to=cwchoi00@gmail.com \
    --cc=cw00.choi@samsung.com \
    --cc=kernel-team@android.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=myungjoo.ham@samsung.com \
    --cc=nm@ti.com \
    --cc=rjw@rjwysocki.net \
    --cc=saravanak@google.com \
    --cc=sboyd@kernel.org \
    --cc=vireshk@kernel.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).