Skip to content
Snippets Groups Projects
  1. Jul 27, 2019
    • Lokesh Vutla's avatar
      armv7R: K3: j721e: Add support for boot device detection · 0a704924
      Lokesh Vutla authored and Tom Rini's avatar Tom Rini committed
      
      J721E allows for booting from primary or backup boot media.
      Both media can be chosen individually based on switch settings.
      ROM looks for a valid image in primary boot media, if not found
      then looks in backup boot media. In order to pass this boot media
      information to boot loader, ROM stores a value at a particular
      address. Add support for reading this information and determining
      the boot media correctly.
      
      Signed-off-by: Lokesh Vutla's avatarLokesh Vutla <lokeshvutla@ti.com>
      Signed-off-by: default avatarAndreas Dannenberg <dannenberg@ti.com>
      Signed-off-by: default avatarFaiz Abbas <faiz_abbas@ti.com>
      0a704924
    • Lokesh Vutla's avatar
      arm: K3: j721e: Add basic support for J721E SoC definition · c2562d7c
      Lokesh Vutla authored and Tom Rini's avatar Tom Rini committed
      The J721E SoC belongs to the K3 Multicore SoC architecture platform,
      providing advanced system integration to enable lower system costs
      of automotive applications such as infotainment, cluster, premium
      Audio, Gateway, industrial and a range of broad market applications.
      This SoC is designed around reducing the system cost by eliminating
      the need of an external system MCU and is targeted towards ASIL-B/C
      certification/requirements in addition to allowing complex software
      and system use-cases.
      
      Some highlights of this SoC are:
      * Dual Cortex-A72s in a single cluster, three clusters of lockstep
        capable dual Cortex-R5F MCUs, Deep-learning Matrix Multiply Accelerator(MMA),
        C7x floating point Vector DSP, Two C66x floating point DSPs.
      * 3D GPU PowerVR Rogue 8XE GE8430
      * Vision Processing Accelerator (VPAC) with image signal processor and Depth
        and Motion Processing Accelerator (DMPAC)
      * Two Gigabit Industrial Communication Subsystems (ICSSG), each with dual
        PRUs and dual RTUs
      * Two CSI2.0 4L RX plus one CSI2.0 4L TX, one eDP/DP, One DSI Tx, and
        up to two DPI interfaces.
      * Integrated Ethernet switch supporting up to a total of 8 external ports in
        addition to legacy Ethernet switch of up to 2 ports.
      * System MMU (SMMU) Version 3.0 and advanced virtualisation
        capabilities.
      * Upto 4 PCIe-GEN3 controllers, 2 USB3.0 Dual-role device subsystems,
        16 MCANs, 12 McASP, eMMC and SD, UFS, OSPI/HyperBus memory controller, QSPI,
        I3C and I2C, eCAP/eQEP, eHRPWM, MLB among other peripherals.
      * Two hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
        management.
      * Configurable L3 Cache and IO-coherent architecture with high data throughput
        capable distributed DMA architecture under NAVSS
      * Centralized System Controller for Security, Power, and Resource
        Management (DMSC)
      
      See J721E Technical Reference Manual (SPRUIL1, May 2019)
      for further details: http://www.ti.com/lit/pdf/spruil1
      
      
      
      Add base support for J721E SoC
      
      Signed-off-by: Lokesh Vutla's avatarLokesh Vutla <lokeshvutla@ti.com>
      Signed-off-by: default avatarAndreas Dannenberg <dannenberg@ti.com>
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      c2562d7c
    • Lokesh Vutla's avatar
      remoteproc: k3_rproc: Rename to ti_k3_arm64_rproc · 54e4311f
      Lokesh Vutla authored and Tom Rini's avatar Tom Rini committed
      
      k3_rproc driver is specifically meant for controlling an arm64
      core using TISCI protocol. So rename the driver, Kconfig symbol,
      compatible and functions accordingly.
      
      While at it drop this remoteproc selection for a53 defconfig.
      
      Signed-off-by: Lokesh Vutla's avatarLokesh Vutla <lokeshvutla@ti.com>
      54e4311f
    • Lokesh Vutla's avatar
      remoteproc: k3_rproc: Update the driver to use ti_sci_proc helpers · 44de37a0
      Lokesh Vutla authored and Tom Rini's avatar Tom Rini committed
      
      Update the k3_rproc driver to use the generic ti_sci_proc helper
      apis which simplifies the driver a bit.
      
      Signed-off-by: Lokesh Vutla's avatarLokesh Vutla <lokeshvutla@ti.com>
      44de37a0
    • Lokesh Vutla's avatar
      remoteproc: tisci: add TI-SCI processor control helper functions · 4fa23ebe
      Lokesh Vutla authored and Tom Rini's avatar Tom Rini committed
      
      Texas Instruments' K3 generation SoCs has specific modules/register
      spaces used for configuring the various aspects of a remote processor.
      These include power, reset, boot vector and other configuration features
      specific to each compute processor present on the SoC. These registers
      are managed by the System Controller such as DMSC on K3 AM65x SoCs.
      
      The Texas Instrument's System Control Interface (TI-SCI) Message Protocol
      is used to communicate to the System Controller from various compute
      processors to invoke specific services provided by the firmware running
      on the System Controller.
      
      Add a common processor control interface header file that can be used by
      multiple remoteproc drivers. The helper functions within this header file
      abstract the various TI SCI protocol ops for the remoteproc drivers, and
      allow them to request the System Controller to be able to program and
      manage various remote processors on the SoC. The common macros required
      by the R5 remoteproc driver were also added. The remoteproc drivers are
      expected to manage the life-cycle of their ti_sci_proc_dev local
      structures.
      
      Signed-off-by: Lokesh Vutla's avatarLokesh Vutla <lokeshvutla@ti.com>
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
      4fa23ebe
    • Lokesh Vutla's avatar
      cmd: remoteproc: Allow list command to print the probed devices · 96f41f9c
      Lokesh Vutla authored and Tom Rini's avatar Tom Rini committed
      
      'rproc list' is currently allowed only after probing all the
      available remoteproc devices. Given that 'rproc init' is updated
      to probe and initialize devices individually, allow the 'rproc list'
      command to print all probed devices at any point.
      
      Signed-off-by: Lokesh Vutla's avatarLokesh Vutla <lokeshvutla@ti.com>
      96f41f9c
    • Lokesh Vutla's avatar
      cmd: remoteproc: Add support for initializing devices individually · 75a11cc7
      Lokesh Vutla authored and Tom Rini's avatar Tom Rini committed
      
      'rproc init' does the probe and initialization of all the available
      remoteproc devices in the system. This doesn't allow the flexibility
      to initialize the remote cores needed as per use case. In order
      to provide flexibility, update 'rproc init' command to accept one
      more parameter with rproc id which when passed initializes only
      that specific core. If no id is passed, command will initializes
      all the cores which is compatible with the existing behaviour.
      
      Signed-off-by: Lokesh Vutla's avatarLokesh Vutla <lokeshvutla@ti.com>
      75a11cc7
    • Lokesh Vutla's avatar
      arm: dts: k3-am654: Update power-domains property for each node · 355be915
      Lokesh Vutla authored and Tom Rini's avatar Tom Rini committed
      
      Update the power-domain-cells to 2 and add the permissions
      to each node. Mark the following nodes accessed by r5 as shared:
      - DDR node
      - main uart 0
      
      Signed-off-by: Lokesh Vutla's avatarLokesh Vutla <lokeshvutla@ti.com>
      355be915
    • Lokesh Vutla's avatar
      power: domain: ti_sci_power_domains: Add support for exclusive and shared access · cd041c80
      Lokesh Vutla authored and Tom Rini's avatar Tom Rini committed
      
      TISCI protocol supports for enabling the device either with exclusive
      permissions for the requesting host or with sharing across the hosts.
      There are certain devices which are exclusive to Linux context and
      there are certain devices that are shared across different host contexts.
      So add support for getting this information from DT by increasing
      the power-domain cells to 2.
      
      For keeping the DT backward compatibility intact, defaulting the
      device permissions to set the exclusive flag set. In this case the
      power-domain-cells is 1.
      
      Signed-off-by: Lokesh Vutla's avatarLokesh Vutla <lokeshvutla@ti.com>
      cd041c80
    • Lokesh Vutla's avatar
      dt-bindings: ti_sci_pm_domains: Add support for exclusive and shared access · c163af6c
      Lokesh Vutla authored and Tom Rini's avatar Tom Rini committed
      
      TISCI protocol supports for enabling the device either with exclusive
      permissions for the requesting host or with sharing across the hosts.
      There are certain devices which are exclusive to Linux context and
      there are certain devices that are shared across different host contexts.
      So add support for getting this information from DT by increasing
      the power-domain cells to 2.
      
      Signed-off-by: Lokesh Vutla's avatarLokesh Vutla <lokeshvutla@ti.com>
      c163af6c
    • Lokesh Vutla's avatar
      power-domain: Add private data to power domain · fd4e7be5
      Lokesh Vutla authored and Tom Rini's avatar Tom Rini committed
      
      Certain drivers want to attach private data corresponding to each
      power domain. This data might be specific be to the drvier. So add
      a priv entry into the power_domain structure.
      
      Signed-off-by: Lokesh Vutla's avatarLokesh Vutla <lokeshvutla@ti.com>
      fd4e7be5
    • Lokesh Vutla's avatar
      armv7R: k3: Release all the exclusive devices · c0669d28
      Lokesh Vutla authored and Tom Rini's avatar Tom Rini committed
      
      Release all the exclusive devices held by SPL.
      
      Signed-off-by: Lokesh Vutla's avatarLokesh Vutla <lokeshvutla@ti.com>
      c0669d28
    • Andreas Dannenberg's avatar
      armv7R: K3: am654: Shut down R5 core after ATF startup on A53 · f9380a73
      Andreas Dannenberg authored and Tom Rini's avatar Tom Rini committed
      
      Rather than simply parking the R5 core in WFE after starting up ATF
      on A53 instead use SYSFW API to properly shut down the R5 CPU cores
      as well as associated timer resources that were pre-allocated. This
      allows software further downstream to properly and gracefully bring
      the R5 cores back online if desired.
      
      Signed-off-by: default avatarAndreas Dannenberg <dannenberg@ti.com>
      Signed-off-by: Lokesh Vutla's avatarLokesh Vutla <lokeshvutla@ti.com>
      f9380a73
    • Lokesh Vutla's avatar
      firmware: ti_sci: Add a command for releasing all exclusive devices · 9566b777
      Lokesh Vutla authored and Tom Rini's avatar Tom Rini committed
      
      Any host while requesting for a device can request for its exclusive
      access. If an exclusive permission is obtained then it is the host's
      responsibility to release the device before the software entity on
      the host completes its execution. Else any other host's request for
      the device will be nacked. So add a command that releases all the
      exclusive devices that is acquired by the current host. This should
      be used with utmost care and can be called only at the end of the
      execution.
      
      Signed-off-by: Lokesh Vutla's avatarLokesh Vutla <lokeshvutla@ti.com>
      9566b777
    • Andreas Dannenberg's avatar
      firmware: ti_sci: Add processor shutdown API method · 410adcc9
      Andreas Dannenberg authored and Tom Rini's avatar Tom Rini committed
      
      Add and expose a new processor shutdown API that wraps the two TISCI
      messages involved in initiating a core shutdown. The API will first
      queue a message to have the DMSC wait for a certain processor boot
      status to happen followed by a message to trigger the actual shutdown-
      with both messages being sent without waiting or requesting for a
      response. Note that the processor shutdown API call will need to be
      followed up by user software placing the respective core into either
      WFE or WFI mode.
      
      Signed-off-by: default avatarAndreas Dannenberg <dannenberg@ti.com>
      410adcc9
    • Lokesh Vutla's avatar
      firmware: ti_sci: Allow for device shared and exclusive requests · ae0b8a2b
      Lokesh Vutla authored and Tom Rini's avatar Tom Rini committed
      
      Sysfw provides an option for requesting exclusive access for a
      device using the flags MSG_FLAG_DEVICE_EXCLUSIVE. If this flag is
      not used, the device is meant to be shared across hosts. Once a device
      is requested from a host with this flag set, any request to this
      device from a different host will be nacked by sysfw. Current tisci
      driver enables this flag for every device requests. But this may not
      be true for all the devices. So provide a separate commands in driver
      for exclusive and shared device requests.
      
      Signed-off-by: Lokesh Vutla's avatarLokesh Vutla <lokeshvutla@ti.com>
      ae0b8a2b
  2. Jul 25, 2019
Loading