1. 14 Mar, 2016 1 commit
    • Nishanth Menon's avatar
      remoteproc: Add support for TI power processor · 42392849
      Nishanth Menon authored
      Many TI System on Chip (SoC) solutions do have a dedicated
      microcontroller for doing power management functionality. These include
      the AM335x, AM437x, Keystone K2G SoCs. The functionality provided by
      these microcontrollers and the communication mechanisms vary very
      widely. However, we are able to consolidate some basic functionality to
      be generic enough starting with K2G SoC family. Introduce a basic remote
      proc driver to support these microcontrollers. In fact, on SoCs starting
      with K2G, basic power management functions are primarily accessible for
      the High Level Operating Systems(HLOS) via these microcontroller solutions.
      
      Hence, having these started at a bootloader level is pretty much
      mandatory.
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      42392849
  2. 05 Dec, 2015 1 commit
    • Nishanth Menon's avatar
      drivers: remoteproc: rproc-uclass: Fix check for NULL pointers · 9cb05a8f
      Nishanth Menon authored
      Neither uc_pdata->name nor check_name are supposed to be NULL in
      _rproc_name_is_unique(). if uc_pdata->name is NULL, we are not
      intialized yet, however if check_data is NULL, we do not have
      proper data. Further, if either were NULL, strlen will crap out
      while attempting to derefence NULL.
      
      Instead, just check if either of these are NULL and bail out.
      
      This should also fix the following coverity scan warnings:
      *** CID 132281:  Null pointer dereferences  (FORWARD_NULL)
      /drivers/remoteproc/rproc-uclass.c: 73 in _rproc_name_is_unique()
      Reported-by: default avatarTom Rini <trini@konsulko.com>
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      9cb05a8f
  3. 22 Oct, 2015 2 commits
    • Nishanth Menon's avatar
      remoteproc: Introduce a sandbox dummy driver · 3df0b8b4
      Nishanth Menon authored
      Introduce a dummy driver for sandbox that allows us to verify basic
      functionality. This is not meant to do anything functional - but is
      more or less meant as a framework plumbing debug helper.
      
      The sandbox remoteproc driver maintains absolutey no states and is a
      simple driver which just is filled with empty hooks. Idea being to give
      an approximate idea to implement own remoteproc driver using this as a
      template.
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      3df0b8b4
    • Nishanth Menon's avatar
      drivers: Introduce a simplified remoteproc framework · ddf56bc7
      Nishanth Menon authored
      Many System on Chip(SoC) solutions are complex with multiple processors
      on the same die dedicated to either general purpose of specialized
      functions. Many examples do exist in today's SoCs from various vendors.
      Typical examples are micro controllers such as an ARM M3/M0 doing a
      offload of specific function such as event integration or power
      management or controlling camera etc.
      
      Traditionally, the responsibility of loading up such a processor with a
      firmware and communication has been with a High Level Operating
      System(HLOS) such as Linux. However, there exists classes of products
      where Linux would need to expect services from such a processor or the
      delay of Linux and operating system being able to load up such a
      firmware is unacceptable.
      
      To address these needs, we need some minimal capability to load such a
      system and ensure it is started prior to an Operating System(Linux or
      any other) is started up.
      
      NOTE: This is NOT meant to be a solve-all solution, instead, it tries to
      address certain class of SoCs and products that need such a solution.
      
      A very simple model is introduced here as part of the initial support
      that supports microcontrollers with internal memory (no MMU, no
      execution from external memory, or specific image format needs). This
      basic framework can then (hopefully) be extensible to other complex SoC
      processor support as need be.
      Reviewed-by: default avatarSimon Glass <sjg@chromium.org>
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Acked-by: default avatarSimon Glass <sjg@chromium.org>
      ddf56bc7