| Message ID | 1509720477-18936-1-git-send-email-sudeep.holla@arm.com |
|---|---|
| Headers | show |
| Series | firmware: ARM System Control and Management Interface(SCMI) support | expand |
Hi Ulf, On 03/11/17 14:47, Sudeep Holla wrote: > This patch hooks up the support for device power domain provided by > SCMI using the Linux generic power domain infrastructure. > > Cc: Kevin Hilman <khilman@baylibre.com> > Cc: Ulf Hansson <ulf.hansson@linaro.org> Sorry for not adding you Reviewed-by tag along with dev_warn suggestion you gave. I seem to have lost that change locally somehow. I have fixed it now.
On Fri, Nov 3, 2017 at 8:17 PM, Sudeep Holla <sudeep.holla@arm.com> wrote: ..... > +int scmi_do_xfer(const struct scmi_handle *handle, struct scmi_xfer *xfer) > +{ > + int ret; > + int timeout; > + struct scmi_info *info = handle_to_scmi_info(handle); > + struct device *dev = info->dev; > + > + ret = mbox_send_message(info->tx_chan, xfer); > ^^^^^^^^ The call still remains unchanged and broken. https://lkml.org/lkml/2017/7/24/502 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03-11-17, 14:47, Sudeep Holla wrote: > On some ARM based systems, a separate Cortex-M based System Control > Processor(SCP) provides the overall power, clock, reset and system > control including CPU DVFS. SCMI Message Protocol is used to > communicate with the SCP. > > This patch adds a cpufreq driver for such systems using SCMI interface > to drive CPU DVFS. > > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> > Cc: Viresh Kumar <viresh.kumar@linaro.org> > Cc: linux-pm@vger.kernel.org > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > --- > MAINTAINERS | 2 +- > drivers/cpufreq/Kconfig.arm | 11 ++ > drivers/cpufreq/Makefile | 1 + > drivers/cpufreq/scmi-cpufreq.c | 274 +++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 287 insertions(+), 1 deletion(-) > create mode 100644 drivers/cpufreq/scmi-cpufreq.c Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
On 03-11-17, 14:47, Sudeep Holla wrote: > The cpufreq core provides option for drivers to implement fast_switch > callback which is invoked for frequency switching from interrupt context. > > This patch adds support for fast_switch callback in SCMI cpufreq driver > by making use of polling based SCMI transfer. It also sets the flag > fast_switch_possible. > > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> > Cc: Viresh Kumar <viresh.kumar@linaro.org> > Cc: linux-pm@vger.kernel.org > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > --- > drivers/cpufreq/scmi-cpufreq.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c > index b1057a13e6a7..91df5013f7b2 100644 > --- a/drivers/cpufreq/scmi-cpufreq.c > +++ b/drivers/cpufreq/scmi-cpufreq.c > @@ -64,6 +64,19 @@ scmi_cpufreq_set_target(struct cpufreq_policy *policy, unsigned int index) > return perf_ops->freq_set(handle, priv->domain_id, freq, false); > } > > +static unsigned int scmi_cpufreq_fast_switch(struct cpufreq_policy *policy, > + unsigned int target_freq) > +{ > + struct scmi_data *priv = policy->driver_data; > + struct scmi_perf_ops *perf_ops = handle->perf_ops; > + > + if (!perf_ops->freq_set(handle, priv->domain_id, > + target_freq * 1000, true)) > + return target_freq; > + > + return 0; > +} > + > static int > scmi_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpumask) > { > @@ -167,6 +180,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy) > > policy->cpuinfo.transition_latency = latency; > > + policy->fast_switch_possible = true; > return 0; > > out_free_cpufreq_table: > @@ -183,6 +197,7 @@ static int scmi_cpufreq_exit(struct cpufreq_policy *policy) > { > struct scmi_data *priv = policy->driver_data; > > + policy->fast_switch_possible = false; You don't need this. > cpufreq_cooling_unregister(priv->cdev); > dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &policy->freq_table); > kfree(priv); > @@ -226,6 +241,7 @@ static struct cpufreq_driver scmi_cpufreq_driver = { > .verify = cpufreq_generic_frequency_table_verify, > .attr = cpufreq_generic_attr, > .target_index = scmi_cpufreq_set_target, > + .fast_switch = scmi_cpufreq_fast_switch, > .get = scmi_cpufreq_get_rate, > .init = scmi_cpufreq_init, > .exit = scmi_cpufreq_exit, Apart from that. Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
On 07/11/17 06:19, Viresh Kumar wrote: > On 03-11-17, 14:47, Sudeep Holla wrote: >> The cpufreq core provides option for drivers to implement fast_switch >> callback which is invoked for frequency switching from interrupt context. >> >> This patch adds support for fast_switch callback in SCMI cpufreq driver >> by making use of polling based SCMI transfer. It also sets the flag >> fast_switch_possible. >> >> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> >> Cc: Viresh Kumar <viresh.kumar@linaro.org> >> Cc: linux-pm@vger.kernel.org >> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> >> --- >> drivers/cpufreq/scmi-cpufreq.c | 16 ++++++++++++++++ >> 1 file changed, 16 insertions(+) >> >> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c >> index b1057a13e6a7..91df5013f7b2 100644 >> --- a/drivers/cpufreq/scmi-cpufreq.c >> +++ b/drivers/cpufreq/scmi-cpufreq.c >> @@ -64,6 +64,19 @@ scmi_cpufreq_set_target(struct cpufreq_policy *policy, unsigned int index) >> return perf_ops->freq_set(handle, priv->domain_id, freq, false); >> } >> >> +static unsigned int scmi_cpufreq_fast_switch(struct cpufreq_policy *policy, >> + unsigned int target_freq) >> +{ >> + struct scmi_data *priv = policy->driver_data; >> + struct scmi_perf_ops *perf_ops = handle->perf_ops; >> + >> + if (!perf_ops->freq_set(handle, priv->domain_id, >> + target_freq * 1000, true)) >> + return target_freq; >> + >> + return 0; >> +} >> + >> static int >> scmi_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpumask) >> { >> @@ -167,6 +180,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy) >> >> policy->cpuinfo.transition_latency = latency; >> >> + policy->fast_switch_possible = true; >> return 0; >> >> out_free_cpufreq_table: >> @@ -183,6 +197,7 @@ static int scmi_cpufreq_exit(struct cpufreq_policy *policy) >> { >> struct scmi_data *priv = policy->driver_data; >> >> + policy->fast_switch_possible = false; > > You don't need this. > OK, dropped now. >> cpufreq_cooling_unregister(priv->cdev); >> dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &policy->freq_table); >> kfree(priv); >> @@ -226,6 +241,7 @@ static struct cpufreq_driver scmi_cpufreq_driver = { >> .verify = cpufreq_generic_frequency_table_verify, >> .attr = cpufreq_generic_attr, >> .target_index = scmi_cpufreq_set_target, >> + .fast_switch = scmi_cpufreq_fast_switch, >> .get = scmi_cpufreq_get_rate, >> .init = scmi_cpufreq_init, >> .exit = scmi_cpufreq_exit, > > Apart from that. > > Acked-by: Viresh Kumar <viresh.kumar@linaro.org> > Thanks
On Friday, November 3, 2017 3:47:57 PM CET Sudeep Holla wrote: > The cpufreq core provides option for drivers to implement fast_switch > callback which is invoked for frequency switching from interrupt context. > > This patch adds support for fast_switch callback in SCMI cpufreq driver > by making use of polling based SCMI transfer. It also sets the flag > fast_switch_possible. > > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> > Cc: Viresh Kumar <viresh.kumar@linaro.org> > Cc: linux-pm@vger.kernel.org > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> I'm assuming that this material will go in along with the rest of the series through a different tree. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/11/17 00:24, Rafael J. Wysocki wrote: > On Friday, November 3, 2017 3:47:57 PM CET Sudeep Holla wrote: >> The cpufreq core provides option for drivers to implement fast_switch >> callback which is invoked for frequency switching from interrupt context. >> >> This patch adds support for fast_switch callback in SCMI cpufreq driver >> by making use of polling based SCMI transfer. It also sets the flag >> fast_switch_possible. >> >> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> >> Cc: Viresh Kumar <viresh.kumar@linaro.org> >> Cc: linux-pm@vger.kernel.org >> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> > > I'm assuming that this material will go in along with the rest of the series > through a different tree. > Indeed, I will ask ARM-SoC guys to take it via their tree when ready. I assume you are fine with that, please provide ack if that's still the case.
On Wed, Nov 8, 2017 at 11:42 AM, Sudeep Holla <sudeep.holla@arm.com> wrote: > > > On 08/11/17 00:24, Rafael J. Wysocki wrote: >> On Friday, November 3, 2017 3:47:57 PM CET Sudeep Holla wrote: >>> The cpufreq core provides option for drivers to implement fast_switch >>> callback which is invoked for frequency switching from interrupt context. >>> >>> This patch adds support for fast_switch callback in SCMI cpufreq driver >>> by making use of polling based SCMI transfer. It also sets the flag >>> fast_switch_possible. >>> >>> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> >>> Cc: Viresh Kumar <viresh.kumar@linaro.org> >>> Cc: linux-pm@vger.kernel.org >>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> >> >> I'm assuming that this material will go in along with the rest of the series >> through a different tree. >> > > Indeed, I will ask ARM-SoC guys to take it via their tree when ready. I > assume you are fine with that, please provide ack if that's still the case. Yes, that makes sense. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 8, 2017 at 11:42 AM, Sudeep Holla <sudeep.holla@arm.com> wrote: > > > On 08/11/17 00:24, Rafael J. Wysocki wrote: >> On Friday, November 3, 2017 3:47:57 PM CET Sudeep Holla wrote: >>> The cpufreq core provides option for drivers to implement fast_switch >>> callback which is invoked for frequency switching from interrupt context. >>> >>> This patch adds support for fast_switch callback in SCMI cpufreq driver >>> by making use of polling based SCMI transfer. It also sets the flag >>> fast_switch_possible. >>> >>> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> >>> Cc: Viresh Kumar <viresh.kumar@linaro.org> >>> Cc: linux-pm@vger.kernel.org >>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> >> >> I'm assuming that this material will go in along with the rest of the series >> through a different tree. >> > > Indeed, I will ask ARM-SoC guys to take it via their tree when ready. I > assume you are fine with that, please provide ack if that's still the case. OK Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> as long as the changes are fine by Viresh. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/11/17 11:05, Arnd Bergmann wrote: > On Wed, Nov 8, 2017 at 11:42 AM, Sudeep Holla <sudeep.holla@arm.com> wrote: >> >> >> On 08/11/17 00:24, Rafael J. Wysocki wrote: >>> On Friday, November 3, 2017 3:47:57 PM CET Sudeep Holla wrote: >>>> The cpufreq core provides option for drivers to implement fast_switch >>>> callback which is invoked for frequency switching from interrupt context. >>>> >>>> This patch adds support for fast_switch callback in SCMI cpufreq driver >>>> by making use of polling based SCMI transfer. It also sets the flag >>>> fast_switch_possible. >>>> >>>> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> >>>> Cc: Viresh Kumar <viresh.kumar@linaro.org> >>>> Cc: linux-pm@vger.kernel.org >>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> >>> >>> I'm assuming that this material will go in along with the rest of the series >>> through a different tree. >>> >> >> Indeed, I will ask ARM-SoC guys to take it via their tree when ready. I >> assume you are fine with that, please provide ack if that's still the case. > > Yes, that makes sense. > Thanks Arnd. Thanks Rafael for the ack.
Hi Jassi, On 04/11/17 11:51, Jassi Brar wrote: > On Fri, Nov 3, 2017 at 8:17 PM, Sudeep Holla <sudeep.holla@arm.com> wrote: > > ..... > >> +int scmi_do_xfer(const struct scmi_handle *handle, struct scmi_xfer *xfer) >> +{ >> + int ret; >> + int timeout; >> + struct scmi_info *info = handle_to_scmi_info(handle); >> + struct device *dev = info->dev; >> + >> + ret = mbox_send_message(info->tx_chan, xfer); >> ^^^^^^^^ > The call still remains unchanged and broken. > https://lkml.org/lkml/2017/7/24/502 > Yes, since you are in favor of abstraction on top of mailbox while Arnd, Bjorn, and me prefer to deal with that in mailbox framework itself, I thought I will keep that discussion separate and get the remaining parts of SCMI reviewed. I have not forgotten about it, just trying to keep it separate. Sorry, I could have been more specific.
Hi Arnd, On 03/11/17 14:47, Sudeep Holla wrote: > The SCMI specification encompasses various protocols. However, not every > protocol has to be present on a given platform/implementation as not > every protocol is relevant for it. > > Furthermore, the platform chooses which protocols it exposes to a given > agent. The only protocol that must be implemented is the base protocol. > The base protocol is used by an agent to discover which protocols are > available to it. > > In order to enumerate the discovered implemented protocols, this patch > adds support for a separate scmi protocol bus. It also adds mechanism to > register support for different protocols. > > Cc: Arnd Bergmann <arnd@arndb.de> Extremely sorry to both during merge window, but just wanted to check if you can spare sometime reviewing these SCMI patches. I know it's too early for v4.16 but with holiday period ahead, thought of checking so that I won't miss v4.16
Hi all, ARM System Control and Management Interface(SCMI) is more flexible and easily extensible than any of the existing interfaces. Many vendors were involved in the making of this formal specification and is now published[1]. There is a strong trend in the industry to provide micro-controllers in systems to abstract various power, or other system management tasks. These controllers usually have similar interfaces, both in terms of the functions that are provided by them, and in terms of how requests are communicated to them. This specification is to standardise and avoid (any further) fragmentation in the design of such interface by various vendors. This patch set is intended to get feedback on the design and structure of the code. This is not complete and not fully tested due to non-availability of firmware with full feature set at this time. It currently doesn't support notification, asynchronous/delayed response, perf/power statistics region and sensor register region to name a few. I have borrowed some of the ideas of message allocation/management from TI SCI. Changes: v3[5]->v4: - Added SCMI protocol bus to enumerate supported protocols as suggested by Arnd - Dropped the abstraction to mailbox as it may be optional v2[4]->v3: - Addressed various comments recieved so far(clock, hwmon and cpufreq drivers along with scmi drivers) - Hwmon driver now uses core layer to create and manage sysfs attributes - Added a shim layer to abstract the mailbox interface to support any custom adaptation required by the controller driver - Simple ARM MHU shim layer using newly added abstraction v1[3]->v2[4]: - Additional support for polling based DVFS and per protocol channels - Dependent drivers(clock, hwmon, cpufreq and power domains) - Various other review comments and issued found during testing addressed - Explicit binding for method dropped as even SMC based method are adviertised as mailbox RFC[2]->v1[3]: - Add generic mailbox binding for shared memory(Rob H) - Dropped compatibles per protocol(Suggested by Matt S) - Dropped lot of unnecessary pointer casting(Arnd B) - Dropped packing of structures(Arnd B) - Few other changes/additions based initial testing with firmware providing SCMI interface to OSPM -- Regards, Sudeep [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html [2] https://marc.info/?l=linux-kernel&m=149685193627620&w=2 [3] https://marc.info/?l=linux-arm-kernel&m=149849482623492&w=2 [4] https://marc.info/?l=devicetree&m=150185763105926&w=2 [5] https://marc.info/?l=devicetree&m=150660452015351&w=2 Sudeep Holla (20): dt-bindings: mailbox: add support for mailbox client shared memory dt-bindings: arm: add support for ARM System Control and Management Interface(SCMI) protocol firmware: arm_scmi: add basic driver infrastructure for SCMI firmware: arm_scmi: add common infrastructure and support for base protocol firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices firmware: arm_scmi: add initial support for performance protocol firmware: arm_scmi: add initial support for clock protocol firmware: arm_scmi: add initial support for power protocol firmware: arm_scmi: add initial support for sensor protocol firmware: arm_scmi: probe and initialise all the supported protocols firmware: arm_scmi: add support for polling based SCMI transfers firmware: arm_scmi: add option for polling based performance domain operations firmware: arm_scmi: refactor in preparation to support per-protocol channels firmware: arm_scmi: add per-protocol channels support using idr objects firmware: arm_scmi: add device power domain support using genpd clk: add support for clocks provided by SCMI hwmon: (core) Add hwmon_max to hwmon_sensor_types enumeration hwmon: add support for sensors exported via ARM SCMI cpufreq: add support for CPU DVFS based on SCMI message protocol cpufreq: scmi: add support for fast frequency switching Documentation/devicetree/bindings/arm/arm,scmi.txt | 179 +++++ .../devicetree/bindings/mailbox/mailbox.txt | 28 + MAINTAINERS | 11 +- drivers/clk/Kconfig | 10 + drivers/clk/Makefile | 1 + drivers/clk/clk-scmi.c | 213 +++++ drivers/cpufreq/Kconfig.arm | 11 + drivers/cpufreq/Makefile | 1 + drivers/cpufreq/scmi-cpufreq.c | 290 +++++++ drivers/firmware/Kconfig | 34 + drivers/firmware/Makefile | 1 + drivers/firmware/arm_scmi/Makefile | 5 + drivers/firmware/arm_scmi/base.c | 293 +++++++ drivers/firmware/arm_scmi/bus.c | 232 ++++++ drivers/firmware/arm_scmi/clock.c | 353 ++++++++ drivers/firmware/arm_scmi/common.h | 116 +++ drivers/firmware/arm_scmi/driver.c | 895 +++++++++++++++++++++ drivers/firmware/arm_scmi/perf.c | 530 ++++++++++++ drivers/firmware/arm_scmi/power.c | 255 ++++++ drivers/firmware/arm_scmi/scmi_pm_domain.c | 140 ++++ drivers/firmware/arm_scmi/sensors.c | 302 +++++++ drivers/hwmon/Kconfig | 12 + drivers/hwmon/Makefile | 1 + drivers/hwmon/scmi-hwmon.c | 233 ++++++ include/linux/hwmon.h | 1 + include/linux/scmi_protocol.h | 272 +++++++ 26 files changed, 4414 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/arm,scmi.txt create mode 100644 drivers/clk/clk-scmi.c create mode 100644 drivers/cpufreq/scmi-cpufreq.c create mode 100644 drivers/firmware/arm_scmi/Makefile create mode 100644 drivers/firmware/arm_scmi/base.c create mode 100644 drivers/firmware/arm_scmi/bus.c create mode 100644 drivers/firmware/arm_scmi/clock.c create mode 100644 drivers/firmware/arm_scmi/common.h create mode 100644 drivers/firmware/arm_scmi/driver.c create mode 100644 drivers/firmware/arm_scmi/perf.c create mode 100644 drivers/firmware/arm_scmi/power.c create mode 100644 drivers/firmware/arm_scmi/scmi_pm_domain.c create mode 100644 drivers/firmware/arm_scmi/sensors.c create mode 100644 drivers/hwmon/scmi-hwmon.c create mode 100644 include/linux/scmi_protocol.h