From: Florian Fainelli <f.fainelli@gmail.com>
To: Viresh Kumar <viresh.kumar@linaro.org>,
Sudeep Holla <sudeep.holla@arm.com>
Cc: Markus Mayer <code@mmayer.net>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Brian Norris <computersforpeace@gmail.com>,
Gregory Fong <gregory.0xf0@gmail.com>,
Florian Fainelli <f.fainelli@gmail.com>,
Jim Quinlan <jim2101024@gmail.com>,
Broadcom Kernel List <bcm-kernel-feedback-list@broadcom.com>,
Power Management List <linux-pm@vger.kernel.org>,
ARM Kernel List <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Markus Mayer <mmayer@broadcom.com>
Subject: Re: [PATCH 2/2] cpufreq: brcmstb-avs-cpufreq: prefer SCMI cpufreq if supported
Date: Fri, 20 Apr 2018 09:50:16 -0700 [thread overview]
Message-ID: <52044000-513b-b5a1-27db-fb7fdb5ee04f@gmail.com> (raw)
In-Reply-To: <20180420093548.GA2989@vireshk-i7>
On 04/20/2018 02:35 AM, Viresh Kumar wrote:
> On 20-04-18, 10:15, Sudeep Holla wrote:
>> It still doesn't give the flexibility to switch between the two
>> implementations boot time based on some firmware config(e.g. DT status
>> property).
>
> I agree, but it didn't look like they need flexibility :)
>
> Lets see how the intend to use it. If they are *always* going to use SCPI if
> that is available, then it should be solved at Kconfig level only. Else they
> shouldn't put such code in the driver to quit early.
We have both drivers (brcmstb-avs-cpufreq and scmi-cpufreq) enabled in
our kernel configuration, however, depending on the firmware version, we
may have a number of combinations:
- arm,scmi DT node is present and enabled (status = okay) as well as
brcmstb-avs-cpufreq being present and enabled
- arm,scmi DT node is present but disabled (status = disabled) and
brcmstb-avs-cpufreq is being present and enabled
If you think this is a self inflicted, downstream and backwards/forwards
compatible relevant only change, I suppose we are fine with that too.
--
Florian
WARNING: multiple messages have this Message-ID (diff)
From: f.fainelli@gmail.com (Florian Fainelli)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] cpufreq: brcmstb-avs-cpufreq: prefer SCMI cpufreq if supported
Date: Fri, 20 Apr 2018 09:50:16 -0700 [thread overview]
Message-ID: <52044000-513b-b5a1-27db-fb7fdb5ee04f@gmail.com> (raw)
In-Reply-To: <20180420093548.GA2989@vireshk-i7>
On 04/20/2018 02:35 AM, Viresh Kumar wrote:
> On 20-04-18, 10:15, Sudeep Holla wrote:
>> It still doesn't give the flexibility to switch between the two
>> implementations boot time based on some firmware config(e.g. DT status
>> property).
>
> I agree, but it didn't look like they need flexibility :)
>
> Lets see how the intend to use it. If they are *always* going to use SCPI if
> that is available, then it should be solved at Kconfig level only. Else they
> shouldn't put such code in the driver to quit early.
We have both drivers (brcmstb-avs-cpufreq and scmi-cpufreq) enabled in
our kernel configuration, however, depending on the firmware version, we
may have a number of combinations:
- arm,scmi DT node is present and enabled (status = okay) as well as
brcmstb-avs-cpufreq being present and enabled
- arm,scmi DT node is present but disabled (status = disabled) and
brcmstb-avs-cpufreq is being present and enabled
If you think this is a self inflicted, downstream and backwards/forwards
compatible relevant only change, I suppose we are fine with that too.
--
Florian
next prev parent reply other threads:[~2018-04-20 16:50 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-18 15:56 [PATCH 0/2] brcmstb-avs-cpufreq changes Markus Mayer
2018-04-18 15:56 ` Markus Mayer
2018-04-18 15:56 ` [PATCH 1/2] cpufreq: brcmstb-avs-cpufreq: remove development debug support Markus Mayer
2018-04-18 15:56 ` Markus Mayer
2018-04-19 4:13 ` Viresh Kumar
2018-04-19 4:13 ` Viresh Kumar
2018-04-30 8:26 ` Rafael J. Wysocki
2018-04-30 8:26 ` Rafael J. Wysocki
2018-04-18 15:56 ` [PATCH 2/2] cpufreq: brcmstb-avs-cpufreq: prefer SCMI cpufreq if supported Markus Mayer
2018-04-18 15:56 ` Markus Mayer
2018-04-18 16:37 ` Florian Fainelli
2018-04-18 16:37 ` Florian Fainelli
2018-04-19 22:10 ` Markus Mayer
2018-04-19 22:10 ` Markus Mayer
2018-04-19 4:16 ` Viresh Kumar
2018-04-19 4:16 ` Viresh Kumar
2018-04-19 10:37 ` Sudeep Holla
2018-04-19 10:37 ` Sudeep Holla
2018-04-20 4:42 ` Viresh Kumar
2018-04-20 4:42 ` Viresh Kumar
2018-04-20 9:15 ` Sudeep Holla
2018-04-20 9:15 ` Sudeep Holla
2018-04-20 9:35 ` Viresh Kumar
2018-04-20 9:35 ` Viresh Kumar
2018-04-20 16:50 ` Florian Fainelli [this message]
2018-04-20 16:50 ` Florian Fainelli
2018-04-23 4:23 ` Viresh Kumar
2018-04-23 4:23 ` Viresh Kumar
2018-04-19 10:35 ` Sudeep Holla
2018-04-19 10:35 ` Sudeep Holla
2018-04-19 16:21 ` Florian Fainelli
2018-04-19 16:21 ` Florian Fainelli
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=52044000-513b-b5a1-27db-fb7fdb5ee04f@gmail.com \
--to=f.fainelli@gmail.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=code@mmayer.net \
--cc=computersforpeace@gmail.com \
--cc=gregory.0xf0@gmail.com \
--cc=jim2101024@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mmayer@broadcom.com \
--cc=rjw@rjwysocki.net \
--cc=sudeep.holla@arm.com \
--cc=viresh.kumar@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 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.