1. 07 2月, 2017 1 次提交
  2. 29 11月, 2016 1 次提交
    • R
      drm/msm: convert iova to 64b · 78babc16
      Rob Clark 提交于
      For a5xx the gpu is 64b so we need to change iova to 64b everywhere.  On
      the display side, iova is still 32b so it can ignore the upper bits.
      (Although all the armv8 devices have an iommu that can map 64b pa to 32b
      iova.)
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      78babc16
  3. 03 3月, 2016 1 次提交
  4. 04 8月, 2014 1 次提交
    • R
      drm/msm: use upstream iommu · 944fc36c
      Rob Clark 提交于
      Downstream kernel IOMMU had a non-standard way of dealing with multiple
      devices and multiple ports/contexts.  We don't need that on upstream
      kernel, so rip out the crazy.
      
      Note that we have to move the pinning of the ringbuffer to after the
      IOMMU is attached.  No idea how that managed to work properly on the
      downstream kernel.
      
      For now, I am leaving the IOMMU port name stuff in place, to simplify
      things for folks trying to backport latest drm/msm to device kernels.
      Once we no longer have to care about pre-DT kernels, we can drop this
      and instead backport upstream IOMMU driver.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      944fc36c
  5. 22 6月, 2014 1 次提交
  6. 10 1月, 2014 1 次提交
    • R
      drm/msm: add support for non-IOMMU systems · 871d812a
      Rob Clark 提交于
      Add a VRAM carveout that is used for systems which do not have an IOMMU.
      
      The VRAM carveout uses CMA.  The arch code must setup a CMA pool for the
      device (preferrably in highmem.. a 256m-512m VRAM pool in lowmem is not
      cool).  The user can configure the VRAM pool size using msm.vram module
      param.
      
      Technically, the abstraction of IOMMU behind msm_mmu is not strictly
      needed, but it simplifies the GEM code a bit, and will be useful later
      when I add support for a2xx devices with GPUMMU, so I decided to keep
      this part.
      
      It appears to be possible to configure the GPU to restrict access to
      addresses within the VRAM pool, but this is not done yet.  So for now
      the GPU will refuse to load if there is no sort of mmu.  Once address
      based limits are supported and tested to confirm that we aren't giving
      the GPU access to arbitrary memory, this restriction can be lifted
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      871d812a