1. 18 Sep, 2019 1 commit
  2. 12 Aug, 2019 19 commits
    • 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: Sudeep Holla's avatarSudeep Holla <sudeep.holla@arm.com>
      95a15d80
    • 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: Sudeep Holla's 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: Sudeep Holla's 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: Sudeep Holla's 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: Sudeep Holla's 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: Sudeep Holla's 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: Sudeep Holla's 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: Sudeep Holla's avatarSudeep Holla <sudeep.holla@arm.com>
      6a55331c
    • Sudeep Holla's avatar
      firmware: arm_scmi: Add support for asynchronous commands and delayed response · 58ecdf03
      Sudeep Holla authored
      
      
      Messages that are sent to platform, also known as commands and can be:
      
      1. Synchronous commands that block the channel until the requested work
      has been completed. The platform responds to these commands over the
      same channel and hence can't be used to send another command until the
      previous command has completed.
      
      2. Asynchronous commands on the other hand, the platform schedules the
      requested work to complete later in time and returns almost immediately
      freeing the channel for new commands. The response indicates the success
      or failure in the ability to schedule the requested work. When the work
      has completed, the platform sends an additional delayed response message.
      
      Using the same transmit buffer used for sending the asynchronous command
      even for the delayed response corresponding to it simplifies handling of
      the delayed response. It's the caller of asynchronous command that is
      responsible for allocating the completion flag that scmi driver can
      complete to indicate the arrival of delayed response.
      
      Signed-off-by: Sudeep Holla's avatarSudeep Holla <sudeep.holla@arm.com>
      58ecdf03
    • Sudeep Holla's avatar
      firmware: arm_scmi: Add mechanism to unpack message headers · 22d1f761
      Sudeep Holla authored
      
      
      In order to identify the message type when a response arrives, we need
      a mechanism to unpack the message header similar to packing. Let's
      add one.
      
      Signed-off-by: Sudeep Holla's avatarSudeep Holla <sudeep.holla@arm.com>
      22d1f761
    • Sudeep Holla's avatar
      firmware: arm_scmi: Separate out tx buffer handling and prepare to add rx · 38c927fb
      Sudeep Holla authored
      
      
      Currently we pre-allocate transmit buffers only and use the first free
      slot in that pre-allocated buffer for transmitting any new message that
      are generally originated from OS to the platform firmware.
      
      Notifications or the delayed responses on the other hand are originated
      from the platform firmware and consumes by the OS. It's better to have
      separate and dedicated pre-allocated buffers to handle the notifications.
      We can still use the transmit buffers for the delayed responses.
      
      In addition, let's prepare existing scmi_xfer_{get,put} for acquiring
      and releasing a slot to identify the right(tx/rx) buffers.
      
      Signed-off-by: Sudeep Holla's avatarSudeep Holla <sudeep.holla@arm.com>
      38c927fb
    • Sudeep Holla's avatar
      firmware: arm_scmi: Add receive channel support for notifications · 46cc7c28
      Sudeep Holla authored
      
      
      With scmi_mbox_chan_setup enabled to identify and setup both Tx and Rx,
      let's consolidate setting up of both the channels under the function
      scmi_mbox_txrx_setup.
      
      Since some platforms may opt not to support notifications or delayed
      response, they may not need support for Rx. Hence Rx is optional and
      failure of setting one up is not considered fatal.
      
      Signed-off-by: Sudeep Holla's avatarSudeep Holla <sudeep.holla@arm.com>
      46cc7c28
    • Sudeep Holla's avatar
      firmware: arm_scmi: Segregate tx channel handling and prepare to add rx · 3748daf7
      Sudeep Holla authored
      
      
      The transmit(Tx) channels are specified as the first entry and the
      receive(Rx) channels are the second entry as per the device tree
      bindings. Since we currently just support Tx, index 0 is hardcoded at
      all required callsites.
      
      In order to prepare for adding Rx support, let's remove those hardcoded
      index and add boolean parameter to identify Tx/Rx channels when setting
      them up.
      
      Signed-off-by: Sudeep Holla's avatarSudeep Holla <sudeep.holla@arm.com>
      3748daf7
    • Sudeep Holla's avatar
      firmware: arm_scmi: Reorder some functions to avoid forward declarations · 2747a967
      Sudeep Holla authored
      
      
      Re-shuffling few functions to keep definitions and their usages close.
      This is also needed to avoid too many unnecessary forward declarations
      while adding new features(delayed response and notifications).
      
      Keeping this separate to avoid mixing up of these trivial change that
      doesn't affect functionality into the ones that does.
      
      Signed-off-by: Sudeep Holla's avatarSudeep Holla <sudeep.holla@arm.com>
      2747a967
    • Sudeep Holla's avatar
      firmware: arm_scmi: Check if platform has released shmem before using · 9dc34d63
      Sudeep Holla authored
      
      
      Sometimes platfom may take too long to respond to the command and OS
      might timeout before platform transfer the ownership of the shared
      memory region to the OS with the response.
      
      Since the mailbox channel associated with the channel is freed and new
      commands are dispatch on the same channel, OS needs to wait until it
      gets back the ownership. If not, either OS may end up overwriting the
      platform response for the last command(which is fine as OS timed out
      that command) or platform might overwrite the payload for the next
      command with the response for the old.
      
      The latter is problematic as platform may end up interpretting the
      response as the payload. In order to avoid such race, let's wait until
      the OS gets back the ownership before we prepare the shared memory with
      the payload for the next command.
      
      Reported-by: default avatarJim Quinlan <james.quinlan@broadcom.com>
      Signed-off-by: Sudeep Holla's avatarSudeep Holla <sudeep.holla@arm.com>
      9dc34d63
    • Sudeep Holla's avatar
      firmware: arm_scmi: Use the term 'message' instead of 'command' · 5b65af8f
      Sudeep Holla authored
      
      
      In preparation to adding support for other two types of messages that
      SCMI specification mentions, let's replace the term 'command' with the
      correct term 'message'.
      
      As per the specification the messages are of 3 types:
      commands(synchronous or asynchronous), delayed responses and notifications.
      
      Signed-off-by: Sudeep Holla's avatarSudeep Holla <sudeep.holla@arm.com>
      5b65af8f
    • Sudeep Holla's avatar
      firmware: arm_scmi: Fix few trivial typos in comments · c29a6289
      Sudeep Holla authored
      
      
      While adding new comments found couple of typos that are better fixed.
      
      s/informfation/information/
      s/statues/status/
      
      Signed-off-by: Sudeep Holla's avatarSudeep Holla <sudeep.holla@arm.com>
      c29a6289
    • Sudeep Holla's avatar
      firmware: arm_scmi: Remove extra check for invalid length message responses · 37bbffcb
      Sudeep Holla authored
      
      
      scmi_xfer_get_init ensures both transmit and receive buffer lengths are
      within the maximum limits. If receive buffer length is not supplied by
      the caller, it's set to the maximum limit value. Receive buffer length
      is never modified after that. So there's no need for the extra check
      when receive transmit completion for a command essage.
      
      Further, if the response header length is greater than the prescribed
      receive buffer length, the response buffer is truncated to the latter.
      
      Reported-by: default avatarJim Quinlan <james.quinlan@broadcom.com>
      Signed-off-by: Sudeep Holla's avatarSudeep Holla <sudeep.holla@arm.com>
      37bbffcb
    • Sudeep Holla's avatar
      firmware: arm_scmi: Align few names in sensors protocol with SCMI specification · 9eefa43a
      Sudeep Holla authored
      
      
      Looks like more code developed during the draft versions of the
      specification slipped through and they don't match the final
      released version. This seem to have happened only with sensor
      protocol.
      
      Renaming few command and function names here to match exactly with
      the released version of SCMI specification for ease of maintenance.
      
      Signed-off-by: Sudeep Holla's avatarSudeep Holla <sudeep.holla@arm.com>
      9eefa43a
  3. 19 Jun, 2019 1 commit
  4. 12 Jun, 2019 3 commits
  5. 21 May, 2019 1 commit
  6. 12 Apr, 2019 2 commits
  7. 30 Jan, 2019 1 commit
    • Sudeep Holla's avatar
      firmware: arm_scmi: provide the mandatory device release callback · 46edb8d1
      Sudeep Holla authored
      The device/driver model clearly mandates that bus driver that discover
      and allocate the device must set the release callback. This callback
      will be used to free the device after all references have gone away.
      
      scmi bus driver is missing the obvious callback which will result in
      the following warning if the device is unregistered:
      
      Device 'scmi_dev.1' does not have a release() function, it is broken and
      must be fixed. See Documentation/kobject.txt.
      WARNING at drivers/base/core.c:922 device_release+0x8c/0xa0
      Hardware name: ARM LTD Juno Development Platform BIOS EDK II Jan 21 2019
      Workqueue: events deferred_probe_work_func
      pstate: 60000005 (nZCv daif -PAN -UAO)
      pc : device_release+0x8c/0xa0
      lr : device_release+0x8c/0xa0
      Call trace:
       device_release+0x8c/0xa0
       kobject_put+0x8c/0x208
       device_unregister+0x30/0x78
       scmi_device_destroy+0x28/0x50
       scmi_probe+0x354/0x5b0
       platform_drv_probe+0x58/0xa8
       really_probe+0x2c4/0x3e8
       driver_probe_device+0x12c/0x148
       __device_attach_driver+0xac/0x150
       bus_for_each_drv+0x78/0xd8
       __device_attach+0xe0/0x168
       device_initial_probe+0x24/0x30
       bus_probe_device+0xa0/0xa8
       deferred_probe_work_func+0x8c/0xe0
       process_one_work+0x1f0/0x478
       worker_thread+0x22c/0x450
       kthread+0x134/0x138
       ret_from_fork+0x10/0x1c
      ---[ end trace 420bdb7f6af50937 ]---
      
      Fix the issue by providing scmi_device_release callback. We have
      everything required for device release already in scmi_device_destroy,
      so we just need to move freeing of the device to scmi_device_release.
      
      Fixes: 933c5044
      
       ("firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices")
      Signed-off-by: Sudeep Holla's avatarSudeep Holla <sudeep.holla@arm.com>
      Cc: stable@vger.kernel.org # 4.17+
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      46edb8d1
  8. 10 Sep, 2018 2 commits
  9. 06 Sep, 2018 1 commit
  10. 09 Jul, 2018 1 commit
  11. 10 May, 2018 6 commits
  12. 09 May, 2018 2 commits