1. 04 Aug, 2016 1 commit
    • Krzysztof Kozlowski's avatar
      dma-mapping: use unsigned long for dma_attrs · 00085f1e
      Krzysztof Kozlowski authored
      The dma-mapping core and the implementations do not change the DMA
      attributes passed by pointer.  Thus the pointer can point to const data.
      However the attributes do not have to be a bitfield.  Instead unsigned
      long will do fine:
      
      1. This is just simpler.  Both in terms of reading the code and setting
         attributes.  Instead of initializing local attributes on the stack
         and passing pointer to it to dma_set_attr(), just set the bits.
      
      2. It brings safeness and checking for const correctness because the
         attributes are passed by value.
      
      Semantic patches for this change (at least most of them):
      
          virtual patch
          virtual context
      
          @r@
          identifier f, attrs;
      
          @@
          f(...,
          - struct dma_attrs *attrs
          + unsigned long attrs
          , ...)
          {
          ...
          }
      
          @@
          identifier r.f;
          @@
          f(...,
          - NULL
          + 0
           )
      
      and
      
          // Options: --all-includes
          virtual patch
          virtual context
      
          @r@
          identifier f, attrs;
          type t;
      
          @@
          t f(..., struct dma_attrs *attrs);
      
          @@
          identifier r.f;
          @@
          f(...,
          - NULL
          + 0
           )
      
      Link: http://lkml.kernel.org/r/1468399300-5399-2-git-send-email-k.kozlowski@samsung.comSigned-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Acked-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Acked-by: default avatarRobin Murphy <robin.murphy@arm.com>
      Acked-by: default avatarHans-Christian Noren Egtvedt <egtvedt@samfundet.no>
      Acked-by: Mark Salter <msalter@redhat.com> [c6x]
      Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> [cris]
      Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> [drm]
      Reviewed-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
      Acked-by: Fabien Dessenne <fabien.dessenne@st.com> [bdisp]
      Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> [vb2-core]
      Acked-by: David Vrabel <david.vrabel@citrix.com> [xen]
      Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> [xen swiotlb]
      Acked-by: Joerg Roedel <jroedel@suse.de> [iommu]
      Acked-by: Richard Kuo <rkuo@codeaurora.org> [hexagon]
      Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
      Acked-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> [s390]
      Acked-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> [avr32]
      Acked-by: Vineet Gupta <vgupta@synopsys.com> [arc]
      Acked-by: Robin Murphy <robin.murphy@arm.com> [arm64 and dma-iommu]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      00085f1e
  2. 14 Jul, 2016 2 commits
  3. 13 Jul, 2016 1 commit
  4. 14 Jun, 2016 1 commit
    • Dave Gerlach's avatar
      remoteproc: Fix potential race condition in rproc_add · d2e12e66
      Dave Gerlach authored
      rproc_add adds the newly created remoteproc to a list for use by
      rproc_get_by_phandle and then does some additional processing to finish
      adding the remoteproc. This leaves a small window of time in which the
      rproc is available in the list but not yet fully initialized, so if
      another driver comes along and gets a handle to the rproc, it will be
      invalid. Rearrange the code in rproc_add to make sure the rproc is added
      to the list only after it has been successfuly initialized.
      
      Fixes: fec47d86 ("remoteproc: introduce rproc_get_by_phandle API")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDave Gerlach <d-gerlach@ti.com>
      Signed-off-by: default avatarBjorn Andersson <bjorn.andersson@linaro.org>
      d2e12e66
  5. 12 May, 2016 2 commits
  6. 06 May, 2016 1 commit
  7. 28 Mar, 2016 1 commit
  8. 29 Jan, 2016 5 commits
  9. 12 Jan, 2016 1 commit
  10. 26 Nov, 2015 2 commits
    • Suman Anna's avatar
      remoteproc: fix memory leak of remoteproc ida cache layers · f42f79af
      Suman Anna authored
      The remoteproc core uses a static ida named rproc_dev_index for
      assigning an automatic index number to a registered remoteproc.
      The ida core may allocate some internal idr cache layers and ida
      bitmap upon any ida allocation, and all these layers are truely
      freed only upon the ida destruction. The rproc_dev_index ida is
      not destroyed at present, leading to a memory leak when using the
      remoteproc core as a module and atleast one rproc device is
      registered and unregistered.
      
      Fix this by invoking ida_destroy() in the remoteproc core module
      exit.
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      f42f79af
    • Arnd Bergmann's avatar
      remoteproc: avoid stack overflow in debugfs file · 92792e48
      Arnd Bergmann authored
      Recent gcc versions warn about reading from a negative offset of
      an on-stack array:
      
      drivers/remoteproc/remoteproc_debugfs.c: In function 'rproc_recovery_write':
      drivers/remoteproc/remoteproc_debugfs.c:167:9: warning: 'buf[4294967295u]' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      I don't see anything in sys_write() that prevents us from
      being called with a zero 'count' argument, so we should
      add an extra check in rproc_recovery_write() to prevent the
      access and avoid the warning.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 2e37abb8 ("remoteproc: create a 'recovery' debugfs entry")
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      92792e48
  11. 18 Jun, 2015 1 commit
  12. 17 Jun, 2015 2 commits
    • Dave Gerlach's avatar
      remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3 · a01bc0d5
      Dave Gerlach authored
      Add a remoteproc driver to load the firmware and boot a small
      Wakeup M3 processor present on TI AM33xx and AM43xx SoCs. This
      Wakeup M3 remote processor is an integrated Cortex M3 that allows
      the SoC to enter the lowest possible power state by taking control
      from the MPU after it has gone into its own low power state and
      shutting off any additional peripherals.
      
      The Wakeup M3 processor has two internal memory regions - 16 kB of
      unified instruction memory called UMEM used to store executable
      code, and 8 kB of data memory called DMEM used for all data sections.
      The Wakeup M3 processor executes its code entirely from within the
      UMEM and uses the DMEM for any data. It does not use any external
      memory or any other external resources. The device address view has
      the UMEM at address 0x0 and DMEM at address 0x80000, and these are
      computed automatically within the driver based on relative address
      calculation from the corresponding device tree IOMEM resources.
      These device addresses are used to aid the core remoteproc ELF
      loader code to properly translate and load the firmware segments
      through the .rproc_da_to_va ops.
      Signed-off-by: default avatarDave Gerlach <d-gerlach@ti.com>
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      a01bc0d5
    • Suman Anna's avatar
      remoteproc: add a rproc ops for performing address translation · a01f7cd6
      Suman Anna authored
      The rproc_da_to_va API is currently used to perform any device to
      kernel address translations to meet the different needs of the remoteproc
      core/drivers (eg: loading). The functionality is achieved within the
      remoteproc core, and is limited only for carveouts allocated within the
      core.
      
      A new rproc ops, da_to_va, is added to provide flexibility to platform
      implementations to perform the address translation themselves when the
      above conditions cannot be met by the implementations. The rproc_da_to_va()
      API is extended to invoke this ops if present, and fallback to regular
      processing if the platform implementation cannot provide the translation.
      This will allow any remoteproc implementations to translate addresses for
      dedicated memories like internal memories.
      
      While at this, also update the rproc_da_to_va() documentation since it
      is an exported function.
      Signed-off-by: default avatarSuman Anna <s-anna@ti.com>
      Signed-off-by: default avatarDave Gerlach <d-gerlach@ti.com>
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      a01f7cd6
  13. 16 Jun, 2015 1 commit
  14. 02 May, 2015 3 commits
  15. 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>
      315491e5
  16. 09 Dec, 2014 4 commits
  17. 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>
      8841a66a
  18. 20 Oct, 2014 1 commit
  19. 17 Jun, 2014 1 commit
    • Arnd Bergmann's avatar
      remoteproc: da8xx: don't select CMA on no-MMU · 8c094524
      Arnd Bergmann authored
      We can only use CMA on systems that have an MMU, because of
      the requirement to use memory migration. NOMMU systems are
      rather constrained to start with, but it seems reasonable
      to assume that DMA allocations can still succeed in the
      constrained case for remoteproc on NOMMU, so this patch
      changes the da8xx implementation to not rely on CMA when
      the MMU is disabled.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Ohad Ben-Cohen <ohad@wizery.com>
      Cc: Robert Tivy <rtivy@ti.com>
      8c094524
  20. 24 Feb, 2014 3 commits
    • Jingoo Han's avatar
      remoteproc/ste_modem: staticize local symbols · bd88acba
      Jingoo Han authored
      These local symbols are used only in this file.
      Fix the following sparse warnings:
      
      drivers/remoteproc/ste_modem_rproc.c:167:27: warning: symbol 'sproc_fw_ops' was not declared. Should it be static?
      drivers/remoteproc/ste_modem_rproc.c:196:25: warning: symbol 'sproc_dev_cb' was not declared. Should it be static?
      Signed-off-by: default avatarJingoo Han <jg1.han@samsung.com>
      [standartize patch title]
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      bd88acba
    • Julia Lawall's avatar
      remoteproc/davinci: simplify use of devm_ioremap_resource · 0ddc5ec1
      Julia Lawall authored
      Remove unneeded error handling on the result of a call to
      platform_get_resource when the value is passed to devm_ioremap_resource.
      
      Move the call to platform_get_resource adjacent to the call to
      devm_ioremap_resource to make the connection between them more clear.
      
      A simplified version of the semantic patch that makes this change is as
      follows: (http://coccinelle.lip6.fr/)
      
      // <smpl>
      @@
      expression pdev,res,n,e,e1;
      expression ret != 0;
      identifier l;
      @@
      
      - res = platform_get_resource(pdev, IORESOURCE_MEM, n);
        ... when != res
      - if (res == NULL) { ... \(goto l;\|return ret;\) }
        ... when != res
      + res = platform_get_resource(pdev, IORESOURCE_MEM, n);
        e = devm_ioremap_resource(e1, res);
      // </smpl>
      Signed-off-by: default avatarJulia Lawall <Julia.Lawall@lip6.fr>
      [simplify patch title]
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      0ddc5ec1
    • Uwe Kleine-König's avatar
      remoteproc/davinci: drop needless devm_clk_put · 5d658bfd
      Uwe Kleine-König authored
      The comment above disable_irq says that it is needed to ensure that the
      "devm subsystem might end up releasing things before freeing the irq,
      thus allowing an interrupt to sneak in while the device is being
      removed." disable_irq is enough for this purpose and there is no need to
      manually free the reference to the clock.
      
      Cc: Robert Tivy <rtivy@ti.com>
      Signed-off-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      [moved the Cc line into the commit message]
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      5d658bfd
  21. 28 Oct, 2013 1 commit
  22. 14 Jul, 2013 1 commit
  23. 01 Jul, 2013 2 commits
  24. 30 Jun, 2013 1 commit