Now that all the SCMI driver users have been migrated to the new interface
remove the legacy interface and all the transient code.

Link: https://lore.kernel.org/r/20210316124903.35011-31-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->voltage_ops still
around to ease transition.

Remove handle->voltage_priv now unused.

Link: https://lore.kernel.org/r/20210316124903.35011-29-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations.

Remove handle->system_priv now unused.

Link: https://lore.kernel.org/r/20210316124903.35011-28-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Now that all the SCMI driver users have been migrated to the new interface
remove the legacy interface and all the transient code.

Link: https://lore.kernel.org/r/20210316124903.35011-27-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->sensor_ops still
around to ease transition.

Remove handle->sensor_priv now unused.

Link: https://lore.kernel.org/r/20210316124903.35011-24-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Now that all the SCMI driver users have been migrated to the new interface
remove the legacy interface and all the transient code.

Link: https://lore.kernel.org/r/20210316124903.35011-23-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->reset_ops still
around to ease transition.

Remove handle->reset_priv now unused.

Link: https://lore.kernel.org/r/20210316124903.35011-21-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Now that all the SCMI driver users have been migrated to the new interface
remove the legacy interface and all the transient code.

Link: https://lore.kernel.org/r/20210316124903.35011-20-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->clk_ops still
around to ease transition.

Remove handle->clock_priv now unused.

Link: https://lore.kernel.org/r/20210316124903.35011-18-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Now that all the SCMI driver users have been migrated to the new interface
remove the legacy interface and all the transient code.

Link: https://lore.kernel.org/r/20210316124903.35011-17-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->power_ops still
around to ease transition.

Remove handle->power_priv now unused.

Link: https://lore.kernel.org/r/20210316124903.35011-15-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Now that all the SCMI driver users have been migrated to the new interface
remove the legacy interface and all the transient code.

Link: https://lore.kernel.org/r/20210316124903.35011-14-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->perf_ops still
around to ease transition.

Remove handle->perf_priv now unused.

Link: https://lore.kernel.org/r/20210316124903.35011-12-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Expose to the SCMI drivers a new alternative devres managed notifications
API based on protocol handles.

All drivers still keep using the old API, no functional change.

Link: https://lore.kernel.org/r/20210316124903.35011-6-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Expose to the SCMI drivers a new devres managed common protocols API
based on generic get/put methods and protocol handles.

All drivers still keep using the old API, no functional change.

Link: https://lore.kernel.org/r/20210316124903.35011-4-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Extend common protocol registration routines and provide some new generic
protocols get/put helpers that can track protocols usage and automatically
perform the proper initialization and de-initialization on demand when
required.

Convert all standard protocols to use this new registration scheme while
keeping them all still using the usual initialization logic bound to SCMI
devices probing.

Link: https://lore.kernel.org/r/20210316124903.35011-2-cristian.marussi@arm.comTested-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Add a new interface to the existing perf_ops and export the information
about the power values scale.

This would be used by the cpufreq driver and Energy Model framework to
set the performance domains scale: milli-Watts or abstract scale.
Suggested-by: NMorten Rasmussen <morten.rasmussen@arm.com>
Reviewed-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NLukasz Luba <lukasz.luba@arm.com>
Acked-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>

Add support for new SCMI v3.0 SENSOR_UPDATE notification.

Link: https://lore.kernel.org/r/20201119174906.43862-7-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Add SCMI v3.0 sensor support for CONFIG_GET/CONFIG_SET commands.

Link: https://lore.kernel.org/r/20201119174906.43862-6-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Add new .reading_get_timestamped() method to sensor_ops to support SCMI v3.0
timestamped reads.

Link: https://lore.kernel.org/r/20201119174906.43862-5-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

SCMI v3.0 introduces voltage domain protocol which provides commands to:
 - Discover the voltage levels supported by a domain
 - Get the configuration and voltage level of a domain
 - Set the configuration and voltage level of a domain

Let us add support for the same.

Link: https://lore.kernel.org/r/20201119191051.46363-2-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Add support for new SCMI v3.0 Sensors extensions related to new sensors'
features, like multiple axis and update intervals, while keeping
compatibility with SCMI v2.0 features.

While at that, refactor and simplify all the internal helpers macros and
move struct scmi_sensor_info to use only non-fixed-size typing.

Link: https://lore.kernel.org/r/20201119174906.43862-3-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

SCMI v2.0 provides a big list of sensor type enumeration from the
sensorUnits enumeration table of Distributed Management Task Force(DMTF)
specification number DSP 0248 (Platform Level Data Model for Platform
Monitoring and Control Specification). It is however not an exact
replica of the sensorUnits enumeration table.

Let us just update the table as per SCMI v2.0 specification.

Link: https://lore.kernel.org/r/20201119174906.43862-3-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Now, with all the plumbing in place to enable building scmi as a module
instead of built-in modules, let us enable the same.

Link: https://lore.kernel.org/r/20200907195046.56615-5-sudeep.holla@arm.comTested-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Add bare protocol support for SCMI system power protocol as needed by
an OSPM agent: basic initialization and SYSTEM_POWER_STATE_NOTIFIER
core notification support.

No event-handling logic is attached to such notification..

Link: https://lore.kernel.org/r/20200907174657.32466-2-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

These are never modified, so make them const to allow drivers to make
them const.

Link: https://lore.kernel.org/r/20200906230452.33410-3-rikard.falkeborn@gmail.comSigned-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Event reports are used to convey information describing events to the
registered user-callbacks: they are necessarily derived from the underlying
raw SCMI events' messages but they are not meant to expose or directly
mirror any of those messages data layout, which belong to the protocol
layer.

Using fixed size types for report fields, mirroring messages structure,
is at odd with this: get rid of them using more generic, equivalent,
typing.

Substitute scmi_event_header fixed size fields with generic types too and
shuffle around fields definitions to minimize implicit padding while
adapting involved functions.

Link: https://lore.kernel.org/r/20200710133919.39792-3-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Substitute zero-length array defined in scmi_base_error_report with
a flexible length array definition.

Link: https://lore.kernel.org/r/20200710133919.39792-1-cristian.marussi@arm.comSigned-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Make SCMI base protocol register with the notification core.

Link: https://lore.kernel.org/r/20200701155348.52864-10-cristian.marussi@arm.comReviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Make SCMI reset protocol register with the notification core.

Link: https://lore.kernel.org/r/20200701155348.52864-9-cristian.marussi@arm.comReviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Make SCMI sensor protocol register with the notification core.

Link: https://lore.kernel.org/r/20200701155348.52864-8-cristian.marussi@arm.comReviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Make SCMI perf protocol register with the notification core.

Link: https://lore.kernel.org/r/20200701155348.52864-7-cristian.marussi@arm.comReviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Make SCMI power protocol register with the notification core.

Link: https://lore.kernel.org/r/20200701155348.52864-6-cristian.marussi@arm.comReviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Add the core SCMI notifications callbacks-registration support: allow
users to register their own callbacks against the desired events.

Whenever a registration request is issued against a still non existent
event, mark such request as pending for later processing, in order to
account for possible late initializations of SCMI Protocols associated
to loadable drivers.

Link: https://lore.kernel.org/r/20200701155348.52864-3-cristian.marussi@arm.comReviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Add the core SCMI notifications protocol-registration support: allow
protocols to register their own set of supported events, during their
initialization phase. Notification core can track multiple platform
instances by their handles.

Link: https://lore.kernel.org/r/20200701155348.52864-2-cristian.marussi@arm.comReviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Add a new fast_switch_possible interface to the existing perf_ops to
export the information of whether or not fast_switch is possible for a
given device.

This can be used by the cpufreq driver and framework to choose proper
mechanism for frequency change.

Link: https://lore.kernel.org/r/20200617094332.8391-1-nicola.mazzucato@arm.comSuggested-by: NLukasz Luba <lukasz.luba@arm.com>
Signed-off-by: NNicola Mazzucato <nicola.mazzucato@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

If this header is include twice, it will generate loads of compile
time error with the following below error pattern. It was reported by
0day kbuild robot on a branch pushed with double inclusion by accident.

 	error: conflicting types for ‘...’
 	note: previous declaration of ‘...’ was here
	error: redefinition of ‘...’

Add a header include guard just in case.

Link: https://lore.kernel.org/r/20200403171018.1230-1-sudeep.holla@arm.comReported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

Currently only one scmi device is created for each protocol enumerated.
However, there is requirement to make use of some procotols by multiple
kernel subsystems/frameworks. One such example is SCMI PERFORMANCE
protocol which can be used by both cpufreq and devfreq drivers.
Similarly, SENSOR protocol may be used by hwmon and iio subsystems,
and POWER protocol may be used by genpd and regulator drivers.

In order to achieve that, let us extend the scmi bus to match based
not only protocol id but also the scmi device name if one is available.
Reviewed-by: NCristian Marussi <cristian.marussi@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

SCMIv2.0 adds a new Reset Management Protocol to manage various reset
states a given device or domain can enter. Device(s) that can be
collectively reset through a common reset signal constitute a reset
domain for the firmware.

A reset domain can be reset autonomously or explicitly through assertion
and de-assertion of the signal. When autonomous reset is chosen, the
firmware is responsible for taking the necessary steps to reset the
domain and to subsequently bring it out of reset. When explicit reset is
chosen, the caller has to specifically assert and then de-assert the
reset signal by issuing two separate RESET commands.

Add the basic SCMI reset infrastructure that can be used by Linux
reset controller driver.
Reviewed-by: NPeng Fan <peng.fan@nxp.com>
Reviewed-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>

CLOCK_PROTOCOL_ATTRIBUTES provides attributes to indicate the maximum
number of pending asynchronous clock rate changes supported by the
platform. If it's non-zero, then we should be able to use asynchronous
clock rate set for any clocks until the maximum limit is reached.

In order to add that support, let's drop the config flag passed to
clk_ops->rate_set and handle the asynchronous requests dynamically.

Cc: Stephen Boyd <sboyd@kernel.org>
Cc: linux-clk@vger.kernel.org
Acked-by: NStephen Boyd <sboyd@kernel.org>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>