Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 20 5月, 2009 1 次提交
    • B
      drm: Round size of SHM maps to PAGE_SIZE · b6741377
      由 Benjamin Herrenschmidt 提交于 
      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
place.

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: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b6741377
  3. 13 3月, 2009 4 次提交
    • D
      drm: Preserve SHMLBA bits in hash key for _DRM_SHM mappings. · f1a2a9b6
      由 David Miller 提交于 
      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: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      f1a2a9b6
    • B
      drm: Make drm_local_map use a resource_size_t offset · 41c2e75e
      由 Benjamin Herrenschmidt 提交于 
      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: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NDave Airlie <airlied@linux.ie>
      41c2e75e
    • B
      drm: Split drm_map and drm_local_map · f77d390c
      由 Benjamin Herrenschmidt 提交于 
      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: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@linux.ie>
      f77d390c
    • B
      drm: Use resource_size_t for drm_get_resource_{start, len} · d883f7f1
      由 Benjamin Herrenschmidt 提交于 
      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
space.

This fixes them, along with a few occurences of unsigned long used
to store such a resource in drivers.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NDave Airlie <airlied@linux.ie>
      d883f7f1
  5. 03 3月, 2009 1 次提交
  7. 29 12月, 2008 3 次提交
  9. 14 7月, 2008 1 次提交
    • D
      drm: reorganise drm tree to be more future proof. · c0e09200
      由 Dave Airlie 提交于 
      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: NDave Airlie <airlied@redhat.com>
      c0e09200
  11. 07 2月, 2008 3 次提交
  13. 20 10月, 2007 1 次提交
  15. 15 10月, 2007 2 次提交
  17. 25 8月, 2007 1 次提交
  19. 23 7月, 2007 1 次提交
  21. 12 7月, 2007 1 次提交
  23. 11 7月, 2007 6 次提交
  25. 11 3月, 2007 1 次提交
  27. 08 2月, 2007 3 次提交
  29. 07 12月, 2006 1 次提交
  31. 26 10月, 2006 1 次提交
  33. 22 9月, 2006 6 次提交
  35. 23 4月, 2006 1 次提交
    • D
      drm: possible cleanups · 5d23fafb
      由 Dave Airlie 提交于 
      This patch contains the following possible cleanups:
- make the following needlessly global function static:
 - drm_bufs.c: drm_addbufs_fb()
- remove the following unused EXPORT_SYMBOL's:
 - drm_agpsupport.c: drm_agp_bind_memory
 - drm_bufs.c: drm_rmmap_locked
 - drm_bufs.c: drm_rmmap
 - drm_stub.c: drm_get_dev
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NDave Airlie <airlied@linux.ie>
      5d23fafb
  37. 19 3月, 2006 1 次提交
  39. 02 2月, 2006 1 次提交