1. 14 9月, 2012 1 次提交
    • Z
      dmaengine: mmp-pdma support · c8acd6aa
      Zhangfei Gao 提交于
      1. virtual channel vs. physical channel
      Virtual channel is managed by dmaengine
      Physical channel handling resource, such as irq
      Physical channel is alloced dynamically as descending priority,
      freed immediately when irq done.
      The availble highest priority physically channel will alwayes be alloced
      
      Issue pending list -> alloc highest dma physically channel available -> dma done -> free physically channel
      
      2. list: running list & pending list
      submit: desc list -> pending list
      issue_pending_list: if (IDLE) pending list -> running list; free pending list (RUN)
      irq: free running list (IDLE)
           check pendlist -> pending list -> running list; free pending list (RUN)
      
      3. irq:
      Each list generate one irq, calling callback
      One list may contain several desc chain, in such case, make sure only the last desc list generate irq.
      
      4. async
      Submit will add desc chain to pending list, which can be multi-called
      If multi desc chain is submitted, only the last desc would generate irq -> call back
      If IDLE, issue_pending_list start pending_list, transforming pendlist to running list
      If RUN, irq will start pending list
      
      5. test
      5.1 pxa3xx_nand on pxa910
      5.2 insmod dmatest.ko (threads_per_chan=y)
      By default drivers/dma/dmatest.c test every channel and test memcpy with 1 threads per channel
      Signed-off-by: NZhangfei Gao <zhangfei.gao@marvell.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>
      c8acd6aa
  2. 01 9月, 2012 4 次提交
  3. 31 8月, 2012 2 次提交
  4. 22 8月, 2012 2 次提交
    • J
      drivers/dma/amba-pl08x.c: fix error return code · 983d7beb
      Julia Lawall 提交于
      Convert a 0 error return code to a negative one, as returned elsewhere in the
      function.
      
      A simplified version of the semantic match that finds this problem is as
      follows: (http://coccinelle.lip6.fr/)
      
      // <smpl>
      @@
      identifier ret;
      expression e,e1,e2,e3,e4,x;
      @@
      
      (
      if (\(ret != 0\|ret < 0\) || ...) { ... return ...; }
      |
      ret = 0
      )
      ... when != ret = e1
      *x = \(kmalloc\|kzalloc\|kcalloc\|devm_kzalloc\|ioremap\|ioremap_nocache\|devm_ioremap\|devm_ioremap_nocache\)(...);
      ... when != x = e2
          when != ret = e3
      *if (x == NULL || ...)
      {
        ... when != ret = e4
      *  return ret;
      }
      // </smpl>
      Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
      Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>
      983d7beb
    • J
      drivers/dma/sirf-dma.c: fix usage of devm functions · 94d3901c
      Julia Lawall 提交于
      Fix some problems with the use of devm_ functions.
      
      devm_kzalloc: devm_kfree is not needed
      
      devm_ioremap: iounmap should not be used, no free is needed
      
      devm_request_irq: the devm_free_irq is followed by irq_dispose_mapping.  I
      don't know if it is safe to move the freeing of the irq in this case, so I
      have just un-devm'd this function, since the implicit freeing is never
      taken advantage of.
      
      In the original code failure of of_address_to_resource jumped to free_mem,
      but should have jumped to irq_dispose, since irq_of_parse_and_map has
      completed at this point.
      
      In the original code unmap_mem was after irq_dispose, but it should have
      been before, again since irq_of_parse_and_map has completed at this point.
      
      One of these problems was found using the following semantic match:
      (http://coccinelle.lip6.fr/)
      
      // <smpl>
      @@
      expression x;
      @@
      
      *x = devm_ioremap(...)
      ...
      iounmap(x);
      // </smpl>
      Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
      Acked-by: NBarry Song <Baohua.Song@csr.com>
      Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>
      94d3901c
  5. 02 8月, 2012 4 次提交
  6. 01 8月, 2012 21 次提交
  7. 31 7月, 2012 6 次提交
    • A
      vfio: Add PCI device driver · 89e1f7d4
      Alex Williamson 提交于
      Add PCI device support for VFIO.  PCI devices expose regions
      for accessing config space, I/O port space, and MMIO areas
      of the device.  PCI config access is virtualized in the kernel,
      allowing us to ensure the integrity of the system, by preventing
      various accesses while reducing duplicate support across various
      userspace drivers.  I/O port supports read/write access while
      MMIO also supports mmap of sufficiently sized regions.  Support
      for INTx, MSI, and MSI-X interrupts are provided using eventfds to
      userspace.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      89e1f7d4
    • A
      vfio: Type1 IOMMU implementation · 73fa0d10
      Alex Williamson 提交于
      This VFIO IOMMU backend is designed primarily for AMD-Vi and Intel
      VT-d hardware, but is potentially usable by anything supporting
      similar mapping functionality.  We arbitrarily call this a Type1
      backend for lack of a better name.  This backend has no IOVA
      or host memory mapping restrictions for the user and is optimized
      for relatively static mappings.  Mapped areas are pinned into system
      memory.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      73fa0d10
    • A
      vfio: VFIO core · cba3345c
      Alex Williamson 提交于
      VFIO is a secure user level driver for use with both virtual machines
      and user level drivers.  VFIO makes use of IOMMU groups to ensure the
      isolation of devices in use, allowing unprivileged user access.  It's
      intended that VFIO will replace KVM device assignment and UIO drivers
      (in cases where the target platform includes a sufficiently capable
      IOMMU).
      
      New in this version of VFIO is support for IOMMU groups managed
      through the IOMMU core as well as a rework of the API, removing the
      group merge interface.  We now go back to a model more similar to
      original VFIO with UIOMMU support where the file descriptor obtained
      from /dev/vfio/vfio allows access to the IOMMU, but only after a
      group is added, avoiding the previous privilege issues with this type
      of model.  IOMMU support is also now fully modular as IOMMUs have
      vastly different interface requirements on different platforms.  VFIO
      users are able to query and initialize the IOMMU model of their
      choice.
      
      Please see the follow-on Documentation commit for further description
      and usage example.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      cba3345c
    • A
      thermal: Constify 'type' argument for the registration routine · 4b1bf587
      Anton Vorontsov 提交于
      thermal_zone_device_register() does not modify 'type' argument, so it is
      safe to declare it as const. Otherwise, if we pass a const string, we are
      getting the ugly warning:
      
      CC drivers/power/power_supply_core.o
      drivers/power/power_supply_core.c: In function 'psy_register_thermal':
      drivers/power/power_supply_core.c:204:6: warning: passing argument 1 of 'thermal_zone_device_register' discards 'const' qualifier from pointer target type [enabled by default]
      include/linux/thermal.h:140:29: note: expected 'char *' but argument is of type 'const char *'
      Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
      Acked-by: NJean Delvare <khali@linux-fr.org>
      4b1bf587
    • K
      ARM: 7464/1: mmc: omap_hsmmc: ensure probe returns error if DMA channel request fails · 04e8c7bc
      Kevin Hilman 提交于
      If dma_request_channel() fails (e.g. because DMA enine is not built
      into the kernel), the return value from probe is zero causing the
      driver to be bound to the device even though probe failed.
      
      To fix, ensure that probe returns an error value when a DMA channel
      request fail.
      Signed-off-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      04e8c7bc
    • R
      mtd: omap2: remove private DMA API implementation · 2df41d05
      Russell King 提交于
      Remove the private DMA API implementation from nand/omap2.c
      making it use entirely the DMA engine API.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2df41d05