From: Niklas Cassel <niklas.cassel@linaro.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Andy Gross <agross@kernel.org>,
linux-arm-msm@vger.kernel.org, jorge.ramirez-ortiz@linaro.org,
sboyd@kernel.org, vireshk@kernel.org, bjorn.andersson@linaro.org,
ulf.hansson@linaro.org, Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 11/13] arm64: dts: qcom: qcs404: Add CPR and populate OPP table
Date: Tue, 16 Jul 2019 12:53:18 +0200 [thread overview]
Message-ID: <20190716105318.GA26592@centauri> (raw)
In-Reply-To: <20190716103436.az5rdk6f3yoa3apz@vireshk-i7>
On Tue, Jul 16, 2019 at 04:04:36PM +0530, Viresh Kumar wrote:
> On 15-07-19, 15:24, Niklas Cassel wrote:
> > This was actually my initial thought when talking to you 6+ months ago.
> > However, the problem was that, from the CPR drivers' perspective, it
> > only sees the CPR OPP table.
> >
> >
> > So this is the order things are called,
> > from qcom-cpufreq-nvmem.c perspective:
> >
> > 1) dev_pm_opp_set_supported_hw()
> >
> > 2) dev_pm_opp_attach_genpd() ->
> > which results in
> > int cpr_pd_attach_dev(struct generic_pm_domain *domain,
> > struct device *dev)
> > being called.
> > This callback is inside the CPR driver, and here we have the
> > CPU's (genpd virtual) struct device, and this is where we would like to
> > know the opp-hz.
> > The problem here is that:
> > [ 3.114979] cpr_pd_attach_dev: dev_pm_opp_get_opp_count for dev: genpd:0:cpu0: -19
> > [ 3.119610] cpr_pd_attach_dev: dev_pm_opp_get_opp_count for dev: cpu0: 0
Here I cheated and simply used get_cpu_device(0).
Since I cheated, I used get_cpu_device(0) always,
so even when CPU1,CPU2,CPU3 is attached, dev_pm_opp_get_opp_count(cpu0) is
still 0.
I added a print in
[ 3.836533] cpr_set_performance: number of OPPs for dev: cpu0: 3
And there I can see that OPP count is 3, so it appears that with the
current code, we need to wait until cpufreq-dt.c:cpufreq_init()
has been called, maybe dev_pm_opp_of_cpumask_add_table() needs
to be called before dev_pm_opp_get_opp_count(cpu0) actually returns 3.
cpufreq_init() is called by platform_device_register_simple("cpufreq-dt", -1,
NULL, 0);
which is called after dev_pm_opp_attach_genpd().
What I don't understand is that dev_pm_opp_attach_genpd() actually returns
a OPP table. So why do we need to wait for dev_pm_opp_of_cpumask_add_table(),
before either dev_pm_opp_get_opp_count(cpu0) or
dev_pm_opp_get_opp_count(genpd_virtdev_for_cpu0) returns 3?
> > [ 3.126489] cpr_pd_attach_dev: dev_pm_opp_get_opp_count for dev: cpr@b018000: 3
> >
> > While we have the CPR OPP table in the attach callback, we don't
> > have the CPU OPP table, neither in the CPU struct device or the genpd virtual
> > struct device.
>
> If you can find CPU's physical number from the virtual device, then
> you can do get_cpu_device(X) and then life will be easy ?
>
> > Since we have called dev_pm_opp_attach_genpd(.., .., &virt_devs) which
> > attaches an OPP table to the CPU, I would have expected one of them to
> > be >= 0.
> > Especially since dev_name(virt_devs[0]) == genpd:0:cpu0
> >
> > I guess it should still be possible to parse the required-opps manually here,
> > by iterating the OF nodes, however, we won't be able to use the CPU's struct
> > opp_table (which is the nice representation of the OF nodes).
> >
> > Any suggestions?
>
> --
> viresh
next prev parent reply other threads:[~2019-07-16 10:53 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-05 9:57 [PATCH 00/13] Add support for QCOM Core Power Reduction Niklas Cassel
2019-07-05 9:57 ` Niklas Cassel
2019-07-05 9:57 ` [PATCH 01/13] dt-bindings: cpufreq: Re-organise kryo cpufreq to use it for other nvmem based qcom socs Niklas Cassel
2019-07-08 6:28 ` Ilia Lin
2019-07-24 14:53 ` Rob Herring
2019-07-24 14:53 ` Rob Herring
2019-07-05 9:57 ` [PATCH 02/13] cpufreq: qcom: " Niklas Cassel
2019-07-08 6:27 ` Ilia Lin
2019-07-10 6:18 ` Viresh Kumar
2019-07-16 11:11 ` Niklas Cassel
2019-07-05 9:57 ` [PATCH 03/13] dt-bindings: cpufreq: qcom-nvmem: Make speedbin related properties optional Niklas Cassel
2019-07-08 6:28 ` Ilia Lin
2019-07-24 14:56 ` Rob Herring
2019-07-24 14:56 ` Rob Herring
2019-07-05 9:57 ` [PATCH 04/13] cpufreq: qcom: Refactor the driver to make it easier to extend Niklas Cassel
2019-07-08 6:30 ` Ilia Lin
2019-07-10 6:30 ` Viresh Kumar
2019-07-16 11:11 ` Niklas Cassel
2019-07-05 9:57 ` [PATCH 05/13] dt-bindings: cpufreq: qcom-nvmem: Support pstates provided by a power domain Niklas Cassel
2019-07-24 15:26 ` Rob Herring
2019-07-05 9:57 ` [PATCH 06/13] cpufreq: qcom: Add support for qcs404 on nvmem driver Niklas Cassel
2019-07-05 9:57 ` [PATCH 07/13] cpufreq: Add qcs404 to cpufreq-dt-platdev blacklist Niklas Cassel
2019-07-05 9:57 ` [PATCH 08/13] dt-bindings: opp: Add qcom-opp bindings with properties needed for CPR Niklas Cassel
2019-07-24 16:03 ` Rob Herring
2019-07-05 9:57 ` [PATCH 09/13] dt-bindings: power: avs: Add support for CPR (Core Power Reduction) Niklas Cassel
2019-07-24 16:06 ` Rob Herring
2019-07-24 16:06 ` Rob Herring
2019-07-05 9:57 ` [PATCH 10/13] " Niklas Cassel
2019-07-05 9:57 ` [PATCH 11/13] arm64: dts: qcom: qcs404: Add CPR and populate OPP table Niklas Cassel
2019-07-10 9:03 ` Viresh Kumar
2019-07-15 13:24 ` Niklas Cassel
2019-07-16 10:34 ` Viresh Kumar
2019-07-16 10:53 ` Niklas Cassel [this message]
2019-07-17 4:49 ` Viresh Kumar
2019-07-19 15:45 ` Niklas Cassel
2019-07-23 1:56 ` Viresh Kumar
2019-07-25 10:40 ` Niklas Cassel
2019-07-05 9:57 ` [PATCH 12/13] arm64: defconfig: enable CONFIG_QCOM_CPR Niklas Cassel
2019-07-05 9:57 ` Niklas Cassel
2019-07-05 9:57 ` [PATCH 13/13] arm64: defconfig: enable CONFIG_ARM_QCOM_CPUFREQ_NVMEM Niklas Cassel
2019-07-05 9:57 ` Niklas Cassel
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=20190716105318.GA26592@centauri \
--to=niklas.cassel@linaro.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=jorge.ramirez-ortiz@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=ulf.hansson@linaro.org \
--cc=viresh.kumar@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.