All of lore.kernel.org
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Georgi Djakov <georgi.djakov@linaro.org>
Cc: vireshk@kernel.org, sboyd@kernel.org, nm@ti.com,
	robh+dt@kernel.org, mark.rutland@arm.com, rjw@rjwysocki.net,
	jcrouse@codeaurora.org, vincent.guittot@linaro.org,
	bjorn.andersson@linaro.org, amit.kucheria@linaro.org,
	seansw@qti.qualcomm.com, daidavid1@codeaurora.org,
	evgreen@chromium.org, sibis@codeaurora.org,
	linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH 2/4] OPP: Add support for parsing the interconnect bandwidth
Date: Wed, 10 Apr 2019 09:23:56 +0530	[thread overview]
Message-ID: <20190410035356.up3qxkc6az5lpjyt@vireshk-i7> (raw)
In-Reply-To: <0cb2d777-4d05-2b06-e458-755d171b3436@linaro.org>

On 09-04-19, 17:37, Georgi Djakov wrote:
> Hi Viresh,
> 
> On 3/14/19 08:30, Viresh Kumar wrote:
> > On 13-03-19, 11:00, Georgi Djakov wrote:
> >> The OPP bindings now support bandwidth values, so add support to parse it
> >> from device tree and store it into the new dev_pm_opp_icc_bw struct, which
> >> is part of the dev_pm_opp.
> >>
> >> Also add and export the dev_pm_opp_set_path() and dev_pm_opp_put_path()
> >> helpers, to set (and release) an interconnect path to a device. The
> >> bandwidth of this path will be updated when the OPPs are switched.
> >>
> >> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> >> ---
> >>  drivers/opp/core.c     | 67 ++++++++++++++++++++++++++++++++++++++++++
> >>  drivers/opp/of.c       | 44 +++++++++++++++++++++++++++
> >>  drivers/opp/opp.h      |  6 ++++
> >>  include/linux/pm_opp.h | 14 +++++++++
> >>  4 files changed, 131 insertions(+)
> >>
> >> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> >> index e06a0ab05ad6..4b019cecaa07 100644
> >> --- a/drivers/opp/core.c
> >> +++ b/drivers/opp/core.c
> >> @@ -19,6 +19,7 @@
> >>  #include <linux/slab.h>
> >>  #include <linux/device.h>
> >>  #include <linux/export.h>
> >> +#include <linux/interconnect.h>
> >>  #include <linux/pm_domain.h>
> >>  #include <linux/regulator/consumer.h>
> >>  
> >> @@ -1645,6 +1646,72 @@ void dev_pm_opp_put_clkname(struct opp_table *opp_table)
> >>  }
> >>  EXPORT_SYMBOL_GPL(dev_pm_opp_put_clkname);
> >>  
> >> +/**
> >> + * dev_pm_opp_set_path() - Set interconnect path for a device
> >> + * @dev: Device for which interconnect path is being set.
> >> + * @name: Interconnect path name or NULL.
> >> + *
> >> + * This must be called before any OPPs are initialized for the device.
> >> + */
> >> +struct opp_table *dev_pm_opp_set_path(struct device *dev, const char *name)
> > 
> > Maybe the OPP core can do it itself in a similar way to how we do
> > clk_get() today ?

It took me a decade to understand my own comment ;)

> Do you mean to directly call of_icc_get() in _allocate_opp_table()?

I believe I wanted to say s/clk_get()/clk_set_rate()/ . i.e. if someone calls
set-opp-rate, then the path should get set as well accordingly automagically.

-- 
viresh

  reply	other threads:[~2019-04-10  3:53 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-13  9:00 [PATCH 0/4] Introduce OPP bandwidth bindings Georgi Djakov
2019-03-13  9:00 ` [PATCH 1/4] dt-bindings: opp: Introduce opp-bw-MBs bindings Georgi Djakov
2019-03-14  6:23   ` Viresh Kumar
2019-04-09 14:36     ` Georgi Djakov
2019-04-10  4:05       ` Viresh Kumar
2019-04-10  9:52         ` Georgi Djakov
2019-03-28 15:12   ` Rob Herring
2019-04-09 14:39     ` Georgi Djakov
2019-03-13  9:00 ` [PATCH 2/4] OPP: Add support for parsing the interconnect bandwidth Georgi Djakov
2019-03-14  6:30   ` Viresh Kumar
2019-04-09 14:37     ` Georgi Djakov
2019-04-10  3:53       ` Viresh Kumar [this message]
2019-03-13  9:00 ` [PATCH 3/4] OPP: Update the bandwidth on OPP frequency changes Georgi Djakov
2019-03-13  9:00 ` [PATCH 4/4] cpufreq: dt: Add support for interconnect bandwidth scaling Georgi Djakov
2019-03-15 19:02 ` [PATCH 0/4] Introduce OPP bandwidth bindings Sibi Sankar
2019-03-28 15:16   ` Rob Herring

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=20190410035356.up3qxkc6az5lpjyt@vireshk-i7 \
    --to=viresh.kumar@linaro.org \
    --cc=amit.kucheria@linaro.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=daidavid1@codeaurora.org \
    --cc=devicetree@vger.kernel.org \
    --cc=evgreen@chromium.org \
    --cc=georgi.djakov@linaro.org \
    --cc=jcrouse@codeaurora.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=nm@ti.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=seansw@qti.qualcomm.com \
    --cc=sibis@codeaurora.org \
    --cc=vincent.guittot@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.