1. 14 Jul, 2017 1 commit
  2. 03 Oct, 2016 1 commit
  3. 16 Jun, 2015 1 commit
  4. 18 Sep, 2012 1 commit
    • Fernando Guzman Lugo's avatar
      remoteproc: add rproc_report_crash function to notify rproc crashes · 8afd519c
      Fernando Guzman Lugo authored
      Allow low-level remoteproc drivers to report rproc crashes by exporting
      a new rproc_report_crash() function (invoking this from non-rproc drivers
      is probably wrong, and should be carefully scrutinized if ever needed).
      
      rproc_report_crash() can be called from any context; it offloads the
      tasks of handling the crash to a separate thread.
      
      Handling the crash from a separate thread is helpful because:
      - Ability to call invoke rproc_report_crash() from atomic context, due to
        the fact that many crashes trigger an interrupt, so this function can be
        called directly from ISR context.
      - Avoiding deadlocks which could happen if rproc_report_crash() is called
        from a function which indirectly holds the rproc lock.
      
      Handling the crash might involve:
      - Remoteproc register dump
      - Remoteproc stack dump
      - Remoteproc core dump
      - Saving Remoteproc traces so they can be read after the crash
      - Reseting the remoteproc in order to make it functional again (hard recovery)
      
      Right now, we only print the crash type which was detected, and only the
      mmufault type is supported. Remoteproc low-level drivers can add more types
      when needed.
      Signed-off-by: 's avatarFernando Guzman Lugo <fernando.lugo@ti.com>
      [ohad: some commentary, white space and commit log changes]
      Signed-off-by: 's avatarOhad Ben-Cohen <ohad@wizery.com>
      8afd519c
  5. 05 Jul, 2012 3 commits
    • Ohad Ben-Cohen's avatar
      remoteproc: adopt the driver core's alloc/add/del/put naming · 160e7c84
      Ohad Ben-Cohen authored
      To make remoteproc's API more intuitive for developers, we adopt
      the driver core's naming, i.e. alloc -> add -> del -> put. We'll also
      add register/unregister when their first user shows up.
      
      Otherwise - there's no functional change here.
      
      Suggested by Russell King <linux@arm.linux.org.uk>.
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
      Cc: Sjur Brændeland <sjur.brandeland@stericsson.com>
      Reviewed-by: 's avatarLinus Walleij <linus.walleij@linaro.org>
      Acked-by: 's avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: 's avatarOhad Ben-Cohen <ohad@wizery.com>
      160e7c84
    • Ohad Ben-Cohen's avatar
      remoteproc: remove the get_by_name/put API · 40e575b1
      Ohad Ben-Cohen authored
      Remove rproc_get_by_name() and rproc_put(), and the associated
      remoteproc infrastructure that supports it (i.e. klist and friends),
      because:
      
      1. No one uses them
      2. Using them is highly discouraged, and any potential user
         will be deeply scrutinized and encouraged to move.
      
      If a user, that absolutely can't live with the direct boot/shutdown
      model, does show up one day, then bringing this functionality back
      is going to be trivial.
      
      At this point though, keeping this functionality around is way too
      much of a maintenance burden.
      
      Cc: Sjur Brændeland <sjur.brandeland@stericsson.com>
      Cc: Loic Pallardy <loic.pallardy@stericsson.com>
      Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
      Cc: Suman Anna <s-anna@ti.com>
      Cc: Mark Grosen <mgrosen@ti.com>
      Acked-by: 's avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: 's avatarOhad Ben-Cohen <ohad@wizery.com>
      40e575b1
    • Ohad Ben-Cohen's avatar
      remoteproc: simplify unregister/free interfaces · c6b5a276
      Ohad Ben-Cohen authored
      Simplify the unregister/free interfaces, and make them easier
      to understand and use, by moving to a symmetric and consistent
      alloc() -> register() -> unregister() -> free() flow.
      
      To create and register an rproc instance, one needed to invoke
      rproc_alloc() followed by rproc_register().
      
      To unregister and free an rproc instance, one now needs to invoke
      rproc_unregister() followed by rproc_free().
      
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: 's avatarOhad Ben-Cohen <ohad@wizery.com>
      c6b5a276
  6. 06 Mar, 2012 2 commits
    • Ohad Ben-Cohen's avatar
      remoteproc: remove the single rpmsg vdev limitation · 7a186941
      Ohad Ben-Cohen authored
      Now that the resource table supports publishing a virtio device
      in a single resource entry, firmware images can start supporting
      more than a single vdev.
      
      This patch removes the single vdev limitation of the remoteproc
      framework so multi-vdev firmwares can be leveraged: VDEV resource
      entries are parsed when the rproc is registered, and as a result
      their vrings are set up and the virtio devices are registered
      (and they go away when the rproc goes away).
      
      Moreover, we no longer only support VIRTIO_ID_RPMSG vdevs; any
      virtio device type goes now. As a result, there's no more any
      rpmsg-specific APIs or code in remoteproc: it all becomes generic
      virtio handling.
      Signed-off-by: 's avatarOhad Ben-Cohen <ohad@wizery.com>
      Cc: Brian Swetland <swetland@google.com>
      Cc: Iliyan Malchev <malchev@google.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Mark Grosen <mgrosen@ti.com>
      Cc: John Williams <john.williams@petalogix.com>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
      Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
      Cc: Omar Ramirez Luna <omar.luna@linaro.org>
      Cc: Guzman Lugo Fernando <fernando.lugo@ti.com>
      Cc: Anna Suman <s-anna@ti.com>
      Cc: Clark Rob <rob@ti.com>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Saravana Kannan <skannan@codeaurora.org>
      Cc: David Brown <davidb@codeaurora.org>
      Cc: Kieran Bingham <kieranbingham@gmail.com>
      Cc: Tony Lindgren <tony@atomide.com>
      7a186941
    • Ohad Ben-Cohen's avatar
      remoteproc: resource table overhaul · fd2c15ec
      Ohad Ben-Cohen authored
      The resource table is an array of 'struct fw_resource' members, where
      each resource entry is expressed as a single member of that array.
      
      This approach got us this far, but it has a few drawbacks:
      
      1. Different resource entries end up overloading the same members of 'struct
         fw_resource' with different meanings. The resulting code is error prone
         and hard to read and maintain.
      
      2. It's impossible to extend 'struct fw_resource' without breaking the
         existing firmware images (and we already want to: we can't introduce the
         new virito device resource entry with the current scheme).
      
      3. It doesn't scale: 'struct fw_resource' must be as big as the largest
         resource entry type. As a result, smaller resource entries end up
         utilizing only small part of it.
      
      This is fixed by defining a dedicated structure for every resource type,
      and then converting the resource table to a list of type-value members.
      Instead of a rigid array of homogeneous structs, the resource table
      is turned into a collection of heterogeneous structures.
      
      This way:
      1. Resource entries consume exactly the amount of bytes they need.
      2. It's easy to extend: just create a new resource entry structure, and assign
         it a new type.
      3. The code is easier to read and maintain: the structures' members names are
         meaningful.
      
      While we're at it, this patch has several other resource table changes:
      1. The resource table gains a simple header which contains the
         number of entries in the table and their offsets within the table. This
         makes the parsing code simpler and easier to read.
      2. A version member is added to the resource table. Should we change the
         format again, we'll bump up this version to prevent breakage with
         existing firmware images.
      3. The VRING and VIRTIO_DEV resource entries are combined to a single
         VDEV entry. This paves the way to supporting multiple VDEV entries.
      4. Since we don't really support 64-bit rprocs yet, convert two stray u64
         members to u32.
      Signed-off-by: 's avatarOhad Ben-Cohen <ohad@wizery.com>
      Cc: Brian Swetland <swetland@google.com>
      Cc: Iliyan Malchev <malchev@google.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Mark Grosen <mgrosen@ti.com>
      Cc: John Williams <john.williams@petalogix.com>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
      Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
      Cc: Omar Ramirez Luna <omar.luna@linaro.org>
      Cc: Guzman Lugo Fernando <fernando.lugo@ti.com>
      Cc: Anna Suman <s-anna@ti.com>
      Cc: Clark Rob <rob@ti.com>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Saravana Kannan <skannan@codeaurora.org>
      Cc: David Brown <davidb@codeaurora.org>
      Cc: Kieran Bingham <kieranbingham@gmail.com>
      Cc: Tony Lindgren <tony@atomide.com>
      fd2c15ec
  7. 08 Feb, 2012 1 commit
    • Ohad Ben-Cohen's avatar
      remoteproc: add framework for controlling remote processors · 400e64df
      Ohad Ben-Cohen authored
      Modern SoCs typically employ a central symmetric multiprocessing (SMP)
      application processor running Linux, with several other asymmetric
      multiprocessing (AMP) heterogeneous processors running different instances
      of operating system, whether Linux or any other flavor of real-time OS.
      
      Booting a remote processor in an AMP configuration typically involves:
      - Loading a firmware which contains the OS image
      - Allocating and providing it required system resources (e.g. memory)
      - Programming an IOMMU (when relevant)
      - Powering on the device
      
      This patch introduces a generic framework that allows drivers to do
      that. In the future, this framework will also include runtime power
      management and error recovery.
      
      Based on (but now quite far from) work done by Fernando Guzman Lugo
      <fernando.lugo@ti.com>.
      
      ELF loader was written by Mark Grosen <mgrosen@ti.com>, based on
      msm's Peripheral Image Loader (PIL) by Stephen Boyd <sboyd@codeaurora.org>.
      
      Designed with Brian Swetland <swetland@google.com>.
      Signed-off-by: 's avatarOhad Ben-Cohen <ohad@wizery.com>
      Acked-by: 's avatarGrant Likely <grant.likely@secretlab.ca>
      Cc: Brian Swetland <swetland@google.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Greg KH <greg@kroah.com>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      400e64df