Skip to content

L
linux
Switch branch/tag
  1. 03 Sep, 2019 3 commits
  3. 23 Aug, 2019 3 commits
  5. 19 Aug, 2019 2 commits
  7. 16 Aug, 2019 1 commit
  9. 15 Aug, 2019 13 commits
  11. 14 Aug, 2019 7 commits
  13. 13 Aug, 2019 1 commit
  15. 12 Aug, 2019 10 commits
    • Sudeep Holla's avatar
      reset: Add support for resets provided by SCMI · c8ae9c2d
      Sudeep Holla authored 
      On some ARM based systems, a separate Cortex-M based System Control
Processor(SCP) provides the overall power, clock, reset and system
control. System Control and Management Interface(SCMI) Message Protocol
is defined for the communication between the Application Cores(AP)
and the SCP.

Adds support for the resets provided using SCMI protocol for performing
reset management of various devices present on the SoC. Various reset
functionalities are achieved by the means of different ARM SCMI device
operations provided by the ARM SCMI framework.
Reviewed-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      c8ae9c2d
    • Sudeep Holla's avatar
      firmware: arm_scmi: Add RESET protocol in SCMI v2.0 · 95a15d80
      Sudeep Holla authored 
      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: default avatarPeng Fan <peng.fan@nxp.com>
Reviewed-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      95a15d80
    • Sudeep Holla's avatar
      dt-bindings: arm: Extend SCMI to support new reset protocol · ae39913c
      Sudeep Holla authored 
      SCMIv2.0 adds a new Reset Management Protocol to manage various reset
states a given device or domain can enter. Extend the existing SCMI
bindings to add reset protocol support by re-using the reset bindings
for both reset providers and consumers.

Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      ae39913c
    • Sudeep Holla's avatar
      firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocol · 82383957
      Sudeep Holla authored 
      SCMI v2.0 adds support for "FastChannel" which do not use a message
header as they are specialized for a single message.

Only PERFORMANCE_LIMITS_{SET,GET} and PERFORMANCE_LEVEL_{SET,GET}
commands are supported over fastchannels. As they are optional, they
need to be discovered by PERFORMANCE_DESCRIBE_FASTCHANNEL command.
Further {LIMIT,LEVEL}_SET commands can have optional doorbell support.

Add support for making use of these fastchannels.

Cc: Ionela Voinescu <Ionela.Voinescu@arm.com>
Cc: Chris Redpath <Chris.Redpath@arm.com>
Cc: Quentin Perret <Quentin.Perret@arm.com>
Reviewed-by: default avatarPeng Fan <peng.fan@nxp.com>
Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      82383957
    • Sudeep Holla's avatar
      firmware: arm_scmi: Add discovery of SCMI v2.0 performance fastchannels · ac8aaf34
      Sudeep Holla authored 
      SCMI v2.0 adds support for "FastChannel", a lightweight unidirectional
channel that is dedicated to a single SCMI message type for controlling
a specific platform resource. They do not use a message header as they
are specialized for a single message.

Only PERFORMANCE_LIMITS_{SET,GET} and PERFORMANCE_LEVEL_{SET,GET}
commands are supported over fastchannels. As they are optional, they
need to be discovered by PERFORMANCE_DESCRIBE_FASTCHANNEL command.
Further {LIMIT,LEVEL}_SET commands can have optional doorbell support.

Add support for discovery of these fastchannels.

Cc: Ionela Voinescu <Ionela.Voinescu@arm.com>
Cc: Chris Redpath <Chris.Redpath@arm.com>
Cc: Quentin Perret <Quentin.Perret@arm.com>
Reviewed-by: default avatarPeng Fan <peng.fan@nxp.com>
Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      ac8aaf34
    • Sudeep Holla's avatar
      firmware: arm_scmi: Use {get,put}_unaligned_le{32,64} accessors · aa90ac45
      Sudeep Holla authored 
      Instead of type-casting the {tx,rx}.buf all over the place while
accessing them to read/write __le{32,64} from/to the firmware, let's
use the existing {get,put}_unaligned_le{32,64} accessors to hide all
the type cast ugliness.
Suggested-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      aa90ac45
    • Sudeep Holla's avatar
      firmware: arm_scmi: Use asynchronous CLOCK_RATE_SET when possible · 2bc06ffa
      Sudeep Holla authored 
      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.

Tracking the current count of pending asynchronous clock set rate
requests, we can decide if the incoming/new request for clock set rate
can be handled asynchronously or not until the maximum limit is
reached.

Cc: linux-clk@vger.kernel.org
Reviewed-by: default avatarStephen Boyd <sboyd@kernel.org>
Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      2bc06ffa
    • Sudeep Holla's avatar
      firmware: arm_scmi: Drop config flag in clk_ops->rate_set · d0aba116
      Sudeep Holla authored 
      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: default avatarStephen Boyd <sboyd@kernel.org>
Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      d0aba116
    • Sudeep Holla's avatar
      firmware: arm_scmi: Add asynchronous sensor read if it supports · d09aac0e
      Sudeep Holla authored 
      SENSOR_DESCRIPTION_GET provides attributes to indicate if the sensor
supports asynchronous read. We can read that flag and use asynchronous
reads for any sensors with that attribute set.

Let's use the new scmi_do_xfer_with_response to support asynchronous
sensor reads.
Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      d09aac0e
    • Sudeep Holla's avatar
      firmware: arm_scmi: Drop async flag in sensor_ops->reading_get · 6a55331c
      Sudeep Holla authored 
      SENSOR_DESCRIPTION_GET provides attributes to indicate if the sensor
supports asynchronous read. Ideally we should be able to read that flag
and use asynchronous reads for any sensors with that attribute set.

In order to add that support, let's drop the async flag passed to
sensor_ops->reading_get and dynamically switch between sync and async
flags based on the attributes as provided by the firmware.

Cc: linux-hwmon@vger.kernel.org
Acked-by: default avatarGuenter Roeck <linux@roeck-us.net>
Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      6a55331c
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7