1. 11 Jun, 2009 1 commit
  2. 05 Jun, 2009 1 commit
  3. 03 Jun, 2009 1 commit
  4. 19 May, 2009 1 commit
    • Benjamin Herrenschmidt's avatar
      drm: Round size of SHM maps to PAGE_SIZE · b6741377
      Benjamin Herrenschmidt authored
      Currently, userspace can fail to obtain the SAREA mapping (among other
      reasons) if it passes SAREA_MAX to drmAddMap without aligning it to the
      page size. This breaks for example on PowerPC with 64K pages and radeon
      despite the kernel radeon actually doing the right rouding in the first
      The way SAREA_MAX is defined with a bunch of ifdef's and duplicated
      between libdrm and the X server is gross, ultimately it should be
      retrieved by userspace from the kernel, but in the meantime, we have
      plenty of existing userspace built with bad values that need to work.
      This patch works around broken userspace by rounding the requested size
      in drm_addmap_core() of any SHM map to the page size. Since the backing
      memory for SHM maps is also allocated within addmap_core, there is no
      danger of adjacent memory being exposed due to the increased map size.
      The only side effect is that drivers that previously tried to create or
      access SHM maps using a size < PAGE_SIZE and failed (getting -EINVAL),
      will now succeed at the cost of a little bit more memory used if that
      happens to be when the map is created.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
  5. 12 Mar, 2009 4 commits
    • David Miller's avatar
      drm: Preserve SHMLBA bits in hash key for _DRM_SHM mappings. · f1a2a9b6
      David Miller authored
      Platforms such as sparc64 have D-cache aliasing issues.  We
      cannot allow virtual mappings in different contexts to be such
      that two cache lines can be loaded for the same backing data.
      Updates to one cache line won't be seen by accesses to the other
      cache line.
      Code in sparc64 and other architectures solve this problem by
      making sure that all userland mappings of MAP_SHARED objects have
      the same virtual address base.  They implement this by keying
      off of the page offset, and using that to choose a suitably
      consistent virtual address for mmap() requests.
      Making things even worse, getting this wrong on sparc64 can result
      in hangs during DRM lock acquisition.  This is because, at least on
      UltraSPARC-III, normal loads consult the D-cache but atomics such
      as 'cas' (which is what cmpxchg() is implement using) only consult
      the L2 cache.  So if a D-cache alias is inserted, the load can
      see different data than the atomic, and we'll loop forever because
      the atomic compare-and-exchange will never complete successfully.
      So to make this all work properly, we need to make sure that the
      hash address computed by drm_map_handle() preserves the SHMLBA
      relevant bits, and that's what this patch does for _DRM_SHM mappings.
      As a historical note, many years ago this bug didn't exist because we
      used to just use the low 32-bits of the address as the hash and just
      hope for the best.  This preserved the SHMLBA bits properly.  But when
      the hashtab code was added to DRM, this was no longer the case.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
    • Benjamin Herrenschmidt's avatar
      drm: Make drm_local_map use a resource_size_t offset · 41c2e75e
      Benjamin Herrenschmidt authored
      This changes drm_local_map to use a resource_size for its "offset"
      member instead of an unsigned long, thus allowing 32-bit machines
      with a >32-bit physical address space to be able to store there
      their register or framebuffer addresses when those are above 4G,
      such as when using a PCI video card on a recent AMCC 440 SoC.
      This patch isn't as "trivial" as it sounds: A few functions needed
      to have some unsigned long/int changed to resource_size_t and a few
      printk's had to be adjusted.
      But also, because userspace isn't capable of passing such offsets,
      I had to modify drm_find_matching_map() to ignore the offset passed
      in for maps of type _DRM_FRAMEBUFFER or _DRM_REGISTERS.
      If we ever support multiple _DRM_FRAMEBUFFER or _DRM_REGISTERS maps
      for a given device, we might have to change that trick, but I don't
      think that happens on any current driver.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarDave Airlie <airlied@linux.ie>
    • Benjamin Herrenschmidt's avatar
      drm: Split drm_map and drm_local_map · f77d390c
      Benjamin Herrenschmidt authored
      Once upon a time, the DRM made the distinction between the drm_map
      data structure exchanged with user space and the drm_local_map used
      in the kernel.
      For some reasons, while the BSD port still has that "feature", the
      linux part abused drm_map for kernel internal usage as the local
      map only existed as a typedef of the struct drm_map.
      This patch fixes it by declaring struct drm_local_map separately
      (though its content is currently identical to the userspace variant),
      and changing the kernel code to only use that, except when it's a
      user<->kernel interface (ie. ioctl).
      This allows subsequent changes to the in-kernel format
      I've also replaced the use of drm_local_map_t with struct drm_local_map
      in a couple of places. Mostly by accident but they are the same (the
      former is a typedef of the later) and I have some remote plans and
      half finished patch to completely kill the drm_local_map_t typedef
      so I left those bits in.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: default avatarEric Anholt <eric@anholt.net>
      Signed-off-by: default avatarDave Airlie <airlied@linux.ie>
    • Benjamin Herrenschmidt's avatar
      drm: Use resource_size_t for drm_get_resource_{start, len} · d883f7f1
      Benjamin Herrenschmidt authored
      The DRM uses its own wrappers to obtain resources from PCI devices,
      which currently convert the resource_size_t into an unsigned long.
      This is broken on 32-bit platforms with >32-bit physical address
      This fixes them, along with a few occurences of unsigned long used
      to store such a resource in drivers.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarDave Airlie <airlied@linux.ie>
  6. 02 Mar, 2009 1 commit
  7. 29 Dec, 2008 3 commits
  8. 13 Jul, 2008 1 commit
    • Dave Airlie's avatar
      drm: reorganise drm tree to be more future proof. · c0e09200
      Dave Airlie authored
      With the coming of kernel based modesetting and the memory manager stuff,
      the everything in one directory approach was getting very ugly and
      starting to be unmanageable.
      This restructures the drm along the lines of other kernel components.
      It creates a drivers/gpu/drm directory and moves the hw drivers into
      subdirectores. It moves the includes into an include/drm, and
      sets up the unifdef for the userspace headers we should be exporting.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
  9. 06 Feb, 2008 3 commits
  10. 19 Oct, 2007 1 commit
  11. 14 Oct, 2007 2 commits
  12. 25 Aug, 2007 1 commit
  13. 23 Jul, 2007 1 commit
  14. 11 Jul, 2007 4 commits
  15. 10 Jul, 2007 3 commits
  16. 10 Mar, 2007 1 commit
  17. 07 Feb, 2007 3 commits
  18. 06 Dec, 2006 1 commit
  19. 25 Oct, 2006 1 commit
  20. 21 Sep, 2006 6 commits