1. 15 7月, 2012 4 次提交
  2. 06 7月, 2012 6 次提交
    • O
      remoteproc: adopt the driver core's alloc/add/del/put naming · 160e7c84
      Ohad Ben-Cohen 提交于
      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: NLinus Walleij <linus.walleij@linaro.org>
      Acked-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      160e7c84
    • O
      remoteproc: remove the get_by_name/put API · 40e575b1
      Ohad Ben-Cohen 提交于
      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: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      40e575b1
    • O
      remoteproc: support non-iommu carveout assignment · 0e49b72c
      Ohad Ben-Cohen 提交于
      Publish carveout addresses on non-iommu setups too.
      Reported-and-acked-by: NSjur Brændeland <sjur.brandeland@stericsson.com>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      0e49b72c
    • O
      remoteproc: simplify unregister/free interfaces · c6b5a276
      Ohad Ben-Cohen 提交于
      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: NOhad Ben-Cohen <ohad@wizery.com>
      c6b5a276
    • O
      remoteproc: remove the now-redundant kref · 7183a2a7
      Ohad Ben-Cohen 提交于
      Now that every rproc instance contains a device, we don't need a
      kref anymore to maintain the refcount of the rproc instances:
      that's what device are good with!
      
      This patch removes the now-redundant kref, and switches to
      {get, put}_device instead of kref_{get, put}.
      
      We also don't need the kref's release function anymore, and instead,
      we just utilize the class's release handler (which is now responsible
      for all memory de-allocations).
      
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      7183a2a7
    • O
      remoteproc: maintain a generic child device for each rproc · b5ab5e24
      Ohad Ben-Cohen 提交于
      For each registered rproc, maintain a generic remoteproc device whose
      parent is the low level platform-specific device (commonly a pdev, but
      it may certainly be any other type of device too).
      
      With this in hand, the resulting device hierarchy might then look like:
      
      omap-rproc.0
       |
       - remoteproc0  <---- new !
          |
          - virtio0
          |
          - virtio1
             |
             - rpmsg0
             |
             - rpmsg1
             |
             - rpmsg2
      
      Where:
      - omap-rproc.0 is the low level device that's bound to the
        driver which invokes rproc_register()
      - remoteproc0 is the result of this patch, and will be added by the
        remoteproc framework when rproc_register() is invoked
      - virtio0 and virtio1 are vdevs that are registered by remoteproc
        when it realizes that they are supported by the firmware
        of the physical remote processor represented by omap-rproc.0
      - rpmsg0, rpmsg1 and rpmsg2 are rpmsg devices that represent rpmsg
        channels, and are registerd by the rpmsg bus when it gets notified
        about their existence
      
      Technically, this patch:
      - changes 'struct rproc' to contain this generic remoteproc.x device
      - creates a new "remoteproc" type, to which this new generic remoteproc.x
        device belong to.
      - adds a super simple enumeration method for the indices of the
        remoteproc.x devices
      - updates all dev_* messaging to use the generic remoteproc.x device
        instead of the low level platform-specific device
      - updates all dma_* allocations to use the parent of remoteproc.x (where
        the platform-specific memory pools, most commonly CMA, are to be found)
      
      Adding this generic device has several merits:
      - we can now add remoteproc runtime PM support simply by hooking onto the
        new "remoteproc" type
      - all remoteproc log messages will now carry a common name prefix
        instead of having a platform-specific one
      - having a device as part of the rproc struct makes it possible to simplify
        refcounting (see subsequent patch)
      
      Thanks to Stephen Boyd <sboyd@codeaurora.org> for suggesting and
      discussing these ideas in one of the remoteproc review threads and
      to Fernando Guzman Lugo <fernando.lugo@ti.com> for trying them out
      with the (upcoming) runtime PM support for remoteproc.
      
      Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
      Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      b5ab5e24
  3. 04 7月, 2012 1 次提交
    • O
      remoteproc: allocate vrings on demand, free when not needed · 6db20ea8
      Ohad Ben-Cohen 提交于
      Dynamically allocate the vrings' DMA when the remote processor
      is about to be powered on (i.e. when ->find_vqs() is invoked),
      and release them as soon as it is powered off (i.e. when ->del_vqs()
      is invoked).
      
      The obvious and immediate benefit is better memory utilization, since
      memory for the vrings is now only allocated when the relevant remote
      processor is used.
      
      Additionally, this approach also makes recovery of a (crashing)
      remote processor easier: one just needs to remove the relevant
      vdevs, and the entire vrings cleanup takes place automagically.
      Tested-by: NFernando Guzman Lugo <fernando.lugo@ti.com>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      6db20ea8
  4. 10 6月, 2012 2 次提交
  5. 23 5月, 2012 1 次提交
    • O
      iommu/core: pass a user-provided token to fault handlers · 77ca2332
      Ohad Ben-Cohen 提交于
      Sometimes a single IOMMU user may have to deal with several
      different IOMMU devices (e.g. remoteproc).
      
      When an IOMMU fault happens, such users have to regain their
      context in order to deal with the fault.
      
      Users can't use the private fields of neither the iommu_domain nor
      the IOMMU device, because those are already used by the IOMMU core
      and low level driver (respectively).
      
      This patch just simply allows users to pass a private token (most
      notably their own context pointer) to iommu_set_fault_handler(),
      and then makes sure it is provided back to the users whenever
      an IOMMU fault happens.
      
      The patch also adopts remoteproc to the new fault handling
      interface, but the real functionality using this (recovery of
      remote processors) will only be added later in a subsequent patch
      set.
      
      Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      77ca2332
  6. 14 5月, 2012 1 次提交
  7. 30 4月, 2012 1 次提交
  8. 07 3月, 2012 4 次提交
    • O
      remoteproc: cleanup resource table parsing paths · 1e3e2c7c
      Ohad Ben-Cohen 提交于
      rproc_handle_resources() looks for the resource table and then
      invokes a resource handler function which it took as a parameter.
      
      This works, but it's a bit unintuitive to follow.
      
      Instead of passing around function pointers, this patch changes
      rproc_handle_resource() to just find and return the resource table,
      and then the calling sites of rproc_handle_resource() invoke their
      resource handlers directly.
      Signed-off-by: NOhad 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>
      1e3e2c7c
    • O
      remoteproc: remove the hardcoded vring alignment · 63140e0e
      Ohad Ben-Cohen 提交于
      Remove the hardcoded vring alignment of 4096 bytes,
      and instead utilize tha vring alignment as specified in
      the resource table.
      
      This is needed for remote processors that have rigid
      memory requirement, and which have found the alignment of
      4096 bytes to be excessively big.
      Signed-off-by: NOhad 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>
      63140e0e
    • O
      remoteproc: remove the single rpmsg vdev limitation · 7a186941
      Ohad Ben-Cohen 提交于
      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: NOhad 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
    • O
      remoteproc: resource table overhaul · fd2c15ec
      Ohad Ben-Cohen 提交于
      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: NOhad 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
  9. 29 2月, 2012 1 次提交
    • O
      remoteproc: make sure we're parsing a 32bit firmware · 40b78b2c
      Ohad Ben-Cohen 提交于
      Make sure we're parsing a 32bit image, since we only support
      the ELF32 binary format at this point.
      
      This should prevent unexpected behavior with non 32bit binaries.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Mark Grosen <mgrosen@ti.com>
      Cc: Suman Anna <s-anna@ti.com>
      Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
      Cc: Rob Clark <rob@ti.com>
      Cc: Ludovic BARRE <ludovic.barre@stericsson.com>
      Cc: Loic PALLARDY <loic.pallardy@stericsson.com>
      Cc: Omar Ramirez Luna <omar.luna@linaro.org>
      40b78b2c
  10. 23 2月, 2012 3 次提交
  11. 09 2月, 2012 4 次提交
    • O
      remoteproc: look for truncated firmware images · 9bc91231
      Ohad Ben-Cohen 提交于
      Make sure firmware isn't truncated before accessing its data.
      Reported-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      9bc91231
    • M
      remoteproc: avoid registering a virtio device if not supported · 7d2d3956
      Mark Grosen 提交于
      Let remoteproc know when the firmware doesn't support any virtio
      functionality, so registering a virtio device can be avoided.
      
      This is needed for remote processors that doesn't require any
      virtio-based communications, but are still controlled via remoteproc.
      
      [ohad@wizery.com: write commit log]
      Signed-off-by: NMark Grosen <mgrosen@ti.com>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      7d2d3956
    • M
      remoteproc: do not require an iommu · 0798e1da
      Mark Grosen 提交于
      Not all remote processors employ an IOMMU, so do not error out
      on !iommu_present().
      
      Note: we currently still use iommu_present() to tell whether we need
      to configure an IOMMU or not. That works for simple cases, but will
      easily fail with more complicated ones (e.g. where an IOMMU exists,
      but not all remote processors use it). When those use cases show up,
      we will solve them by introducing something like remoteproc hw
      capabilities.
      
      [ohad@wizery.com: write commit log]
      Signed-off-by: NMark Grosen <mgrosen@ti.com>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      0798e1da
    • O
      remoteproc: add framework for controlling remote processors · 400e64df
      Ohad Ben-Cohen 提交于
      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: NOhad Ben-Cohen <ohad@wizery.com>
      Acked-by: NGrant 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