1. 08 5月, 2016 5 次提交
  2. 16 1月, 2016 1 次提交
  3. 15 8月, 2015 1 次提交
  4. 30 7月, 2015 1 次提交
  5. 12 6月, 2015 2 次提交
  6. 14 5月, 2015 1 次提交
  7. 02 4月, 2015 1 次提交
    • R
      drm/msm: add support for "stolen" mem · 072f1f91
      Rob Clark 提交于
      Add support to use the VRAM carveout (if specified in dtb) for fbdev
      scanout buffer.  This allows drm/msm to take over a bootloader splash-
      screen, and avoids corruption on screen that results if the kernel uses
      memory that is still being scanned out for itself.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      072f1f91
  8. 17 12月, 2014 1 次提交
  9. 17 11月, 2014 3 次提交
  10. 04 8月, 2014 1 次提交
  11. 08 7月, 2014 1 次提交
    • D
      drm/gem: remove misleading gfp parameter to get_pages() · 0cdbe8ac
      David Herrmann 提交于
      drm_gem_get_pages() currently allows passing a 'gfp' parameter that is
      passed to shmem combined with mapping_gfp_mask(). Given that the default
      mapping_gfp_mask() is GFP_HIGHUSER, it is _very_ unlikely that anyone will
      ever make use of that parameter. In fact, all drivers currently pass
      redundant flags or 0.
      
      This patch removes the 'gfp' parameter. The only reason to keep it is to
      remove flags like __GFP_WAIT. But in its current form, it can only be used
      to add flags. So to remove __GFP_WAIT, you'd have to drop it from the
      mapping_gfp_mask, which again is stupid as this mask is used by shmem-core
      for other allocations, too.
      
      If any driver ever requires that parameter, we can introduce a new helper
      that takes the raw 'gfp' parameter. The caller'd be responsible to combine
      it with mapping_gfp_mask() in a suitable way. The current
      drm_gem_get_pages() helper would then simply use mapping_gfp_mask() and
      call the new helper. This is what shmem_read_mapping_pages{_gfp,} does
      right now.
      
      Moreover, the gfp-zone flag-usage is not obvious: If you pass a modified
      zone, shmem core will WARN() or even BUG(). In other words, the following
      must be true for 'gfp' passed to shmem_read_mapping_pages_gfp():
          gfp_zone(mapping_gfp_mask(mapping)) == gfp_zone(gfp)
      Add a comment to drm_gem_read_pages() explaining that constraint.
      Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
      0cdbe8ac
  12. 22 6月, 2014 1 次提交
  13. 25 4月, 2014 1 次提交
  14. 06 2月, 2014 1 次提交
  15. 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
  16. 02 11月, 2013 3 次提交
  17. 28 9月, 2013 1 次提交
  18. 16 9月, 2013 1 次提交
  19. 12 9月, 2013 2 次提交
  20. 11 9月, 2013 1 次提交
    • R
      drm/msm: handle read vs write fences · bf6811f3
      Rob Clark 提交于
      The userspace API already had everything needed to handle read vs write
      synchronization.  This patch actually bothers to hook it up properly, so
      that we don't need to (for example) stall on userspace read access to a
      buffer that gpu is also still reading.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      bf6811f3
  21. 25 8月, 2013 2 次提交
    • R
      drm/msm: add a3xx gpu support · 7198e6b0
      Rob Clark 提交于
      Add initial support for a3xx 3d core.
      
      So far, with hardware that I've seen to date, we can have:
       + zero, one, or two z180 2d cores
       + a3xx or a2xx 3d core, which share a common CP (the firmware
         for the CP seems to implement some different PM4 packet types
         but the basics of cmdstream submission are the same)
      
      Which means that the eventual complete "class" hierarchy, once
      support for all past and present hw is in place, becomes:
       + msm_gpu
         + adreno_gpu
           + a3xx_gpu
           + a2xx_gpu
         + z180_gpu
      
      This commit splits out the parts that will eventually be common
      between a2xx/a3xx into adreno_gpu, and the parts that are even
      common to z180 into msm_gpu.
      
      Note that there is no cmdstream validation required.  All memory access
      from the GPU is via IOMMU/MMU.  So as long as you don't map silly things
      to the GPU, there isn't much damage that the GPU can do.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      7198e6b0
    • R
      drm/msm: basic KMS driver for snapdragon · c8afe684
      Rob Clark 提交于
      The snapdragon chips have multiple different display controllers,
      depending on which chip variant/version.  (As far as I can tell, current
      devices have either MDP3 or MDP4, and upcoming devices have MDSS.)  And
      then external to the display controller are HDMI, DSI, etc. blocks which
      may be shared across devices which have different display controller
      blocks.
      
      To more easily add support for different display controller blocks, the
      display controller specific bits are split out into a "kms" module,
      which provides the kms plane/crtc/encoder objects.
      
      The external HDMI, DSI, etc. blocks are part encoder, and part connector
      currently.  But I think I will pull in the drm_bridge patches from
      chromeos tree, and split them into a bridge+connector, with the
      registers that need to be set in modeset handled by the bridge.  This
      would remove the 'msm_connector' base class.  But some things need to be
      double checked to make sure I could get the correct ON/OFF sequencing..
      
      This patch adds support for mdp4 crtc (including hw cursor), dtv encoder
      (part of MDP4 block), and hdmi.
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      c8afe684