Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 04 9月, 2019 4 次提交
  3. 23 8月, 2019 3 次提交
  5. 19 8月, 2019 2 次提交
  7. 17 8月, 2019 1 次提交
  9. 16 8月, 2019 12 次提交
  11. 15 8月, 2019 2 次提交
    • A
      Merge tag 'tee-optee-for-5.4' of... · 157eed91
      由 Arnd Bergmann 提交于 
      Merge tag 'tee-optee-for-5.4' of git://git.linaro.org/people/jens.wiklander/linux-tee into arm/drivers

Add might_sleep() in OP-TEE RPC requests

* tag 'tee-optee-for-5.4' of git://git.linaro.org/people/jens.wiklander/linux-tee:
  tee: optee: add might_sleep for RPC requests

Link: https://lore.kernel.org/r/20190815065659.GA13498@jaxSigned-off-by: NArnd Bergmann <arnd@arndb.de>
      157eed91
    • A
      Merge tag 'scmi-updates-5.4' of... · 738590a3
      由 Arnd Bergmann 提交于 
      Merge tag 'scmi-updates-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/drivers

ARM SCMI updates/fixes for v5.4

Handful of fixes/updates including:
1. SCMI v2.0(recently released) support for:
	- Performance protocol fast channels
	- Reset Management Protocol
2. SCMI infrastructure/core support for recieve(Rx) channels,
   asynchronous commands and delayed response
3. Usage of asynchronous commands for clock rate setting and sensor
   reading based on the attributes read from the firmware
4. Miscellaneous cleanups(typos, naming alignment with specification,
   and SPDX License identifier)
5. Couple of fixes: removal of extra check for invalid length and
   additional check to ensure platform/firmware has released shared
   memory before using it in OSPM

* tag 'scmi-updates-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: (22 commits)
  reset: Add support for resets provided by SCMI
  firmware: arm_scmi: Add RESET protocol in SCMI v2.0
  dt-bindings: arm: Extend SCMI to support new reset protocol
  firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocol
  firmware: arm_scmi: Add discovery of SCMI v2.0 performance fastchannels
  firmware: arm_scmi: Use {get,put}_unaligned_le{32,64} accessors
  firmware: arm_scmi: Use asynchronous CLOCK_RATE_SET when possible
  firmware: arm_scmi: Drop config flag in clk_ops->rate_set
  firmware: arm_scmi: Add asynchronous sensor read if it supports
  firmware: arm_scmi: Drop async flag in sensor_ops->reading_get
  firmware: arm_scmi: Add support for asynchronous commands and delayed response
  firmware: arm_scmi: Add mechanism to unpack message headers
  firmware: arm_scmi: Separate out tx buffer handling and prepare to add rx
  firmware: arm_scmi: Add receive channel support for notifications
  firmware: arm_scmi: Segregate tx channel handling and prepare to add rx
  firmware: arm_scmi: Reorder some functions to avoid forward declarations
  firmware: arm_scmi: Check if platform has released shmem before using
  firmware: arm_scmi: Use the term 'message' instead of 'command'
  firmware: arm_scmi: Fix few trivial typos in comments
  firmware: arm_scmi: Remove extra check for invalid length message responses
  ...

Link: https://lore.kernel.org/r/20190814172454.26191-1-sudeep.holla@arm.comSigned-off-by: NArnd Bergmann <arnd@arndb.de>
      738590a3
  13. 14 8月, 2019 6 次提交
  15. 13 8月, 2019 1 次提交
  17. 12 8月, 2019 9 次提交
    • S
      reset: Add support for resets provided by SCMI · c8ae9c2d
      由 Sudeep Holla 提交于 
      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: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
      c8ae9c2d
    • S
      firmware: arm_scmi: Add RESET protocol in SCMI v2.0 · 95a15d80
      由 Sudeep Holla 提交于 
      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>
      95a15d80
    • S
      dt-bindings: arm: Extend SCMI to support new reset protocol · ae39913c
      由 Sudeep Holla 提交于 
      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: NSudeep Holla <sudeep.holla@arm.com>
      ae39913c
    • S
      firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocol · 82383957
      由 Sudeep Holla 提交于 
      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: NPeng Fan <peng.fan@nxp.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
      82383957
    • S
      firmware: arm_scmi: Add discovery of SCMI v2.0 performance fastchannels · ac8aaf34
      由 Sudeep Holla 提交于 
      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: NPeng Fan <peng.fan@nxp.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
      ac8aaf34
    • S
      firmware: arm_scmi: Use {get,put}_unaligned_le{32,64} accessors · aa90ac45
      由 Sudeep Holla 提交于 
      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: NPhilipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
      aa90ac45
    • S
      firmware: arm_scmi: Use asynchronous CLOCK_RATE_SET when possible · 2bc06ffa
      由 Sudeep Holla 提交于 
      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: NStephen Boyd <sboyd@kernel.org>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
      2bc06ffa
    • S
      firmware: arm_scmi: Drop config flag in clk_ops->rate_set · d0aba116
      由 Sudeep Holla 提交于 
      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>
      d0aba116
    • S
      firmware: arm_scmi: Add asynchronous sensor read if it supports · d09aac0e
      由 Sudeep Holla 提交于 
      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: NSudeep Holla <sudeep.holla@arm.com>
      d09aac0e