From: <ilialin@codeaurora.org>
To: 'Viresh Kumar' <viresh.kumar@linaro.org>,
'Sudeep Holla' <sudeep.holla@arm.com>
Cc: 'Viresh Kumar' <vireshk@kernel.org>, 'Nishanth Menon' <nm@ti.com>,
'Stephen Boyd' <sboyd@kernel.org>,
'Rob Herring' <robh@kernel.org>,
'Mark Rutland' <mark.rutland@arm.com>,
"'Rafael J. Wysocki'" <rjw@rjwysocki.net>,
linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
'Linux Kernel Mailing List' <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v10 1/2] cpufreq: Add Kryo CPU scaling driver
Date: Wed, 23 May 2018 14:34:41 +0300 [thread overview]
Message-ID: <002b01d3f28a$0d033900$2709ab00$@codeaurora.org> (raw)
In-Reply-To: <CAKohponbpErCeTYu9iQm_-dupz5SUr+TKsYXzqmmARB-pq95iA@mail.gmail.com>
> -----Original Message-----
> From: Viresh Kumar <viresh.kumar@linaro.org>
> Sent: Wednesday, May 23, 2018 14:31
> To: Ilia Lin <ilialin@codeaurora.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>; Viresh Kumar
> <vireshk@kernel.org>; Nishanth Menon <nm@ti.com>; Stephen Boyd
> <sboyd@kernel.org>; Rob Herring <robh@kernel.org>; Mark Rutland
> <mark.rutland@arm.com>; Rafael J. Wysocki <rjw@rjwysocki.net>; linux-
> pm@vger.kernel.org; devicetree@vger.kernel.org; Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v10 1/2] cpufreq: Add Kryo CPU scaling driver
>
> On 23 May 2018 at 16:36, <ilialin@codeaurora.org> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Sudeep Holla <sudeep.holla@arm.com>
> >> Sent: Wednesday, May 23, 2018 13:40
> >> To: Ilia Lin <ilialin@codeaurora.org>; vireshk@kernel.org; nm@ti.com;
> >> sboyd@kernel.org; robh@kernel.org; mark.rutland@arm.com;
> >> rjw@rjwysocki.net; linux-pm@vger.kernel.org;
> >> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> >> Cc: Sudeep Holla <sudeep.holla@arm.com>
> >> Subject: Re: [PATCH v10 1/2] cpufreq: Add Kryo CPU scaling driver
> >>
> >>
> >>
> >> On 23/05/18 10:40, Ilia Lin wrote:
> >> > In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO
> >> > processors, the CPU frequency subset and voltage value of each OPP
> >> > varies based on the silicon variant in use. Qualcomm Process
> >> > Voltage Scaling Tables defines the voltage and frequency value
> >> > based on the msm-id in SMEM and speedbin blown in the efuse
> combination.
> >> > The qcom-cpufreq-kryo driver reads the msm-id and efuse value from
> >> > the SoC to provide the OPP framework with required information.
> >> > This is used to determine the voltage and frequency value for each
> >> > OPP of
> >> > operating-points-v2 table when it is parsed by the OPP framework.
> >> >
> >> > Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
> >>
> >> [...]
> >>
> >> > + pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
> >> > + if (!IS_ERR(pdev))
> >> > + return 0;
> >> > +
> >> > + ret = PTR_ERR(pdev);
> >> > + dev_err(cpu_dev, "Failed to register platform device\n");
> >> > +
> >> > +free_opp:
> >> > + for_each_possible_cpu(cpu) {
> >> > + if (IS_ERR_OR_NULL(opp_tables[cpu]))
> >> > + break;
> >> > + dev_pm_opp_put_supported_hw(opp_tables[cpu]);
> >> > + }
> >> > +free_np:
> >> > + of_node_put(np);
> >> > +
> >> > + return ret;
> >> > +}
> >> > +late_initcall(qcom_cpufreq_kryo_driver_init);
> >>
> >> Any particular reason why this *has* to be late initcall ?
> >> Please change it to module_initcall otherwise.
> >
> > The purpose is to give the cpufreq-dt the time to register the driver and
> only then my driver will add the platform device.
>
> That isn't required, the device and its driver can be registered in any order.
You are right. I already checked that in the code...
However, with module_init() the driver fails on reading the nvmem.
WARNING: multiple messages have this Message-ID (diff)
From: <ilialin@codeaurora.org>
To: "'Viresh Kumar'" <viresh.kumar@linaro.org>,
"'Sudeep Holla'" <sudeep.holla@arm.com>
Cc: "'Viresh Kumar'" <vireshk@kernel.org>,
"'Nishanth Menon'" <nm@ti.com>,
"'Stephen Boyd'" <sboyd@kernel.org>,
"'Rob Herring'" <robh@kernel.org>,
"'Mark Rutland'" <mark.rutland@arm.com>,
"'Rafael J. Wysocki'" <rjw@rjwysocki.net>,
<linux-pm@vger.kernel.org>, <devicetree@vger.kernel.org>,
"'Linux Kernel Mailing List'" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v10 1/2] cpufreq: Add Kryo CPU scaling driver
Date: Wed, 23 May 2018 14:34:41 +0300 [thread overview]
Message-ID: <002b01d3f28a$0d033900$2709ab00$@codeaurora.org> (raw)
In-Reply-To: <CAKohponbpErCeTYu9iQm_-dupz5SUr+TKsYXzqmmARB-pq95iA@mail.gmail.com>
> -----Original Message-----
> From: Viresh Kumar <viresh.kumar@linaro.org>
> Sent: Wednesday, May 23, 2018 14:31
> To: Ilia Lin <ilialin@codeaurora.org>
> Cc: Sudeep Holla <sudeep.holla@arm.com>; Viresh Kumar
> <vireshk@kernel.org>; Nishanth Menon <nm@ti.com>; Stephen Boyd
> <sboyd@kernel.org>; Rob Herring <robh@kernel.org>; Mark Rutland
> <mark.rutland@arm.com>; Rafael J. Wysocki <rjw@rjwysocki.net>; linux-
> pm@vger.kernel.org; devicetree@vger.kernel.org; Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v10 1/2] cpufreq: Add Kryo CPU scaling driver
>
> On 23 May 2018 at 16:36, <ilialin@codeaurora.org> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Sudeep Holla <sudeep.holla@arm.com>
> >> Sent: Wednesday, May 23, 2018 13:40
> >> To: Ilia Lin <ilialin@codeaurora.org>; vireshk@kernel.org; nm@ti.com;
> >> sboyd@kernel.org; robh@kernel.org; mark.rutland@arm.com;
> >> rjw@rjwysocki.net; linux-pm@vger.kernel.org;
> >> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> >> Cc: Sudeep Holla <sudeep.holla@arm.com>
> >> Subject: Re: [PATCH v10 1/2] cpufreq: Add Kryo CPU scaling driver
> >>
> >>
> >>
> >> On 23/05/18 10:40, Ilia Lin wrote:
> >> > In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO
> >> > processors, the CPU frequency subset and voltage value of each OPP
> >> > varies based on the silicon variant in use. Qualcomm Process
> >> > Voltage Scaling Tables defines the voltage and frequency value
> >> > based on the msm-id in SMEM and speedbin blown in the efuse
> combination.
> >> > The qcom-cpufreq-kryo driver reads the msm-id and efuse value from
> >> > the SoC to provide the OPP framework with required information.
> >> > This is used to determine the voltage and frequency value for each
> >> > OPP of
> >> > operating-points-v2 table when it is parsed by the OPP framework.
> >> >
> >> > Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
> >>
> >> [...]
> >>
> >> > + pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
> >> > + if (!IS_ERR(pdev))
> >> > + return 0;
> >> > +
> >> > + ret = PTR_ERR(pdev);
> >> > + dev_err(cpu_dev, "Failed to register platform device\n");
> >> > +
> >> > +free_opp:
> >> > + for_each_possible_cpu(cpu) {
> >> > + if (IS_ERR_OR_NULL(opp_tables[cpu]))
> >> > + break;
> >> > + dev_pm_opp_put_supported_hw(opp_tables[cpu]);
> >> > + }
> >> > +free_np:
> >> > + of_node_put(np);
> >> > +
> >> > + return ret;
> >> > +}
> >> > +late_initcall(qcom_cpufreq_kryo_driver_init);
> >>
> >> Any particular reason why this *has* to be late initcall ?
> >> Please change it to module_initcall otherwise.
> >
> > The purpose is to give the cpufreq-dt the time to register the driver and
> only then my driver will add the platform device.
>
> That isn't required, the device and its driver can be registered in any order.
You are right. I already checked that in the code...
However, with module_init() the driver fails on reading the nvmem.
next prev parent reply other threads:[~2018-05-23 11:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-23 9:40 [PATCH v10 0/2] Kryo CPU scaling driver Ilia Lin
2018-05-23 9:40 ` [PATCH v10 1/2] cpufreq: Add " Ilia Lin
2018-05-23 10:03 ` Viresh Kumar
2018-05-23 10:39 ` Sudeep Holla
2018-05-23 11:06 ` ilialin
2018-05-23 11:06 ` ilialin
2018-05-23 11:31 ` Viresh Kumar
2018-05-23 11:34 ` ilialin [this message]
2018-05-23 11:34 ` ilialin
2018-05-23 11:46 ` Viresh Kumar
2018-05-23 11:47 ` ilialin
2018-05-23 11:47 ` ilialin
2018-05-23 11:51 ` Viresh Kumar
2018-05-23 9:40 ` [PATCH v10 2/2] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu Ilia Lin
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='002b01d3f28a$0d033900$2709ab00$@codeaurora.org' \
--to=ilialin@codeaurora.org \
--cc=devicetree@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@kernel.org \
--cc=sboyd@kernel.org \
--cc=sudeep.holla@arm.com \
--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.