1. 18 Jan, 2017 1 commit
    • Bhumika Goyal's avatar
      drivers: remoteproc: constify rproc_ops structures · c008fad2
      Bhumika Goyal authored
      Declare rproc_ops structures as const as they are only passed as an
      argument to the function rproc_alloc. This argument is of type const, so
      rproc_ops structures having this property can be declared const too.
      Done using Coccinelle:
      @r1 disable optional_qualifier @
      identifier i;
      position p;
      static struct rproc_ops i@p = {...};
      identifier r1.i;
      position p;
      position p!={r1.p,ok1.p};
      identifier r1.i;
      @depends on !bad disable optional_qualifier@
      identifier r1.i;
      struct rproc_ops i;
      File size details:
      Size of the file remoteproc/da8xx_remoteproc.o remains the same before and
      after applying the changes.
         text	   data	    bss	    dec	    hex	filename
         1312	    100	      4	   1416	    588 remoteproc/da8xx_remoteproc.o
         1312	    100	      4	   1416	    588 remoteproc/da8xx_remoteproc.o
          970	    240	      0	   1210	    4ba remoteproc/omap_remoteproc.o
         1002	    192	      0	   1194	    4aa remoteproc/omap_remoteproc.o
         1901	    240	      0	   2141	    85d remoteproc/st_remoteproc.o
         1933	    192	      0	   2125	    84d remoteproc/st_remoteproc.o
         1288	     96	      0	   1384	    568 remoteproc/st_slim_rproc.o
         1320	     64	      0	   1384	    568 remoteproc/st_slim_rproc.o
         2121	    240	      0	   2361	    939 remoteproc/wkup_m3_rproc.o
         2161	    192	      0	   2353	    931 remoteproc/wkup_m3_rproc.o
      Signed-off-by: default avatarBhumika Goyal <bhumirks@gmail.com>
      Signed-off-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
  2. 03 Oct, 2016 1 commit
  3. 13 Aug, 2016 2 commits
  4. 12 Mar, 2015 1 commit
    • Suman Anna's avatar
      remoteproc: add IOMMU hardware capability flag · 315491e5
      Suman Anna authored
      The remoteproc framework currently relies on iommu_present() on
      the bus the device is on, to perform MMU management. However, this
      logic doesn't scale for multi-arch, especially for processors that
      do not have an IOMMU. Replace this logic instead by using a h/w
      capability flag for the presence of IOMMU in the rproc structure.
      This issue is seen on OMAP platforms when trying to add a remoteproc
      driver for a small Cortex M3 called the WkupM3 used for suspend /
      resume management on TI AM335/AM437x SoCs. This processor does not
      have an MMU. Same is the case with another processor subsystem
      PRU-ICSS on AM335/AM437x. All these are platform devices, and the
      current iommu_present check will not scale for the same kernel image
      to support OMAP4/OMAP5 and AM335/AM437x.
      The existing platform implementation drivers - OMAP remoteproc, STE
      Modem remoteproc and DA8xx remoteproc, are updated as well to properly
      configure the newly added rproc field.
      Cc: Robert Tivy <rtivy@ti.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
      [small change in the commit title and in a single comment]
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
  5. 27 Nov, 2014 1 commit
    • Suman Anna's avatar
      mailbox/omap: adapt to the new mailbox framework · 8841a66a
      Suman Anna authored
      The OMAP mailbox driver and its existing clients (remoteproc
      for OMAP4+) are adapted to use the generic mailbox framework.
      The main changes for the adaptation are:
        - The tasklet used for Tx is replaced with the state machine from
          the generic mailbox framework. The workqueue used for processing
          the received messages stays intact for minimizing the effects on
          the OMAP mailbox clients.
        - The existing exported client API, omap_mbox_get, omap_mbox_put and
          omap_mbox_send_msg are deleted, as the framework provides equivalent
          functionality. A OMAP-specific omap_mbox_request_channel is added
          though to support non-DT way of requesting mailboxes.
        - The OMAP mailbox driver is integrated with the mailbox framework
          through the proper implementations of mbox_chan_ops, except for
          .last_tx_done and .peek_data. The OMAP mailbox driver does not need
          these ops, as it is completely interrupt driven.
        - The OMAP mailbox driver uses a custom of_xlate controller ops that
          allows phandles for the pargs specifier instead of indexing to avoid
          any channel registration order dependencies.
        - The new framework does not support multiple clients operating on a
          single channel, so the reference counting logic is simplified.
        - The remoteproc driver (current client) is adapted to use the new API.
          The notifier callbacks used within this client is replaced with the
          regular callbacks from the newer framework.
        - The exported OMAP mailbox API are limited to omap_mbox_save_ctx,
          omap_mbox_restore_ctx, omap_mbox_enable_irq & omap_mbox_disable_irq,
          with the signature modified to take in the new mbox_chan handle instead
          of the OMAP specific omap_mbox handle. The first 2 will be removed when
          the OMAP mailbox driver is adapted to runtime_pm. The other exported
          API omap_mbox_request_channel will be removed once existing legacy
          users are converted to DT.
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
      Cc: Ohad Ben-Cohen <ohad@wizery.com>
      Signed-off-by: default avatarJassi Brar <jaswinder.singh@linaro.org>
  6. 20 Oct, 2014 1 commit
  7. 11 Jun, 2013 1 commit
    • Suman Anna's avatar
      mailbox/omap: move the OMAP mailbox framework to drivers · c869c75c
      Suman Anna authored
      The mailbox hardware (in OMAP) uses a queued mailbox interrupt
      mechanism that provides a communication channel between processors
      through a set of registers and their associated interrupt signals
      by sending and receiving messages.
      The OMAP mailbox framework/driver code is moved to be under
      drivers/mailbox, in preparation for adapting to a common mailbox
      driver framework. This allows the build for OMAP mailbox to be
      enabled (it was disabled during the multi-platform support).
      As part of the migration from plat and mach code:
      - Kconfig symbols have been renamed to build OMAP1 or OMAP2+ drivers.
      - mailbox.h under plat-omap/plat/include has been split into a public
        and private header files. The public header has only the API related
        functions and types.
      - The module name mailbox.ko from plat-omap is changed to
      - The module name mailbox_mach.ko from mach-omapX is changed as
          mailbox_omap1.ko for OMAP1
          mailbox_omap2.ko for OMAP2+
      Cc: Tony Lindgren <tony@atomide.com>
      [gregkh@linuxfoundation.org: ack for staging part]
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarOmar Ramirez Luna <omar.ramirez@copitl.com>
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
  8. 03 Jan, 2013 1 commit
    • Greg Kroah-Hartman's avatar
      Drivers: misc: remove __dev* attributes. · 0fe763c5
      Greg Kroah-Hartman authored
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      This change removes the use of __devinit, __devexit_p, __devinitdata,
      __devinitconst, and __devexit from these drivers.
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  9. 19 Sep, 2012 1 commit
    • Arnd Bergmann's avatar
      ARM: omap: move platform_data definitions · 2203747c
      Arnd Bergmann authored
      Platform data for device drivers should be defined in
      include/linux/platform_data/*.h, not in the architecture
      and platform specific directories.
      This moves such data out of the omap include directories
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Cc: Kevin Hilman <khilman@ti.com>
      Cc: "Benoît Cousson" <b-cousson@ti.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Cc: Ohad Ben-Cohen <ohad@wizery.com>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
      Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
      Cc: Liam Girdwood <lrg@ti.com>
      Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Cc: Jean Pihet <j-pihet@ti.com>
      Cc: J Keerthy <j-keerthy@ti.com>
      Cc: linux-omap@vger.kernel.org
  10. 11 Sep, 2012 1 commit
    • Juan Gutierrez's avatar
      remoteproc/omap: set bootaddr support · 4980f465
      Juan Gutierrez authored
      Some remote processors (like OMAP4's DSP) require we explicitly
      set a boot address from which they'd start executing code when
      taken out of reset.
      Support for this is now being added to the omap-specific remoteproc
      driver through a set_bootaddr function in the platform data which,
      if needed, must be set according to the backend remote processor.
      For OMAP4's dsp we can use the following control function:
        .set_bootaddr  = omap_ctrl_write_dsp_boot_addr
      Signed-off-by: default avatarJuan Gutierrez <jgutierrez@ti.com>
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
      [ohad: slight changes to the commit log]
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
  11. 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: default avatarLinus Walleij <linus.walleij@linaro.org>
      Acked-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
    • 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: default avatarOhad Ben-Cohen <ohad@wizery.com>
    • Ohad Ben-Cohen's avatar
      remoteproc: maintain a generic child device for each rproc · b5ab5e24
      Ohad Ben-Cohen authored
      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:
       - remoteproc0  <---- new !
          - virtio0
          - virtio1
             - rpmsg0
             - rpmsg1
             - rpmsg2
      - 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: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
  12. 17 Jun, 2012 1 commit
  13. 06 Mar, 2012 1 commit
    • Ohad Ben-Cohen's avatar
      remoteproc/omap: remove the mbox_callback limitation · 55f34080
      Ohad Ben-Cohen authored
      Now that remoteproc supports any number of virtio devices,
      the previous sanity check in omap_rproc_mbox_callback
      doesn't make sense anymore.
      Remove that so we can start supporting multiple vdevs.
      Signed-off-by: default 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>
  14. 08 Feb, 2012 2 commits
    • Ohad Ben-Cohen's avatar
      remoteproc/omap: utilize module_platform_driver · 63d667bf
      Ohad Ben-Cohen authored
      Ditch some boilerplate code by employing the module_platform_driver
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
    • Ohad Ben-Cohen's avatar
      remoteproc/omap: add a remoteproc driver for OMAP4 · 34ed5a33
      Ohad Ben-Cohen authored
      Add a remoteproc driver for OMAP4, so we can boot the dual-M3 and
      and DSP subsystems.
      Use the omap_device_* API to control the hardware state, and utilize
      the OMAP mailbox to interrupt the remote processor when a new message
      is pending (the mailbox payload is used to tell it which virtqueue was
      the message placed in).
      Conversely, when an inbound mailbox message arrives, tell the remoteproc
      core which virtqueue is triggered.
      Later we will also use the mailbox payload to signal omap-specific
      events like remote crashes (which will be used to trigger remoteproc
      recovery) and power management transitions. At that point we will also
      extend the remoteproc core to support this.
      Based on (but now quite far from) work done by Fernando Guzman Lugo
      <fernando.lugo@ti.com> and Hari Kanigeri <h-kanigeri2@ti.com>.
      Designed with Brian Swetland <swetland@google.com>.
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Cc: Brian Swetland <swetland@google.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      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>