Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 02 11月, 2011 1 次提交
  3. 28 10月, 2011 1 次提交
  5. 18 10月, 2011 5 次提交
  7. 10 10月, 2011 1 次提交
    • M
      DRM: bug: RADEON_DEBUGFS_MAX_{NUM_FILES => COMPONENTS} · c245cb9e
      由 Michael Witten 提交于 
      The value of RADEON_DEBUGFS_MAX_NUM_FILES has been used to
specify the size of an array, each element of which looks
like this:

  struct radeon_debugfs {
          struct drm_info_list    *files;
          unsigned                num_files;
  };

Consequently, the number of debugfs files may be much greater
than RADEON_DEBUGFS_MAX_NUM_FILES, something that the current
code ignores:

  if ((_radeon_debugfs_count + nfiles) > RADEON_DEBUGFS_MAX_NUM_FILES) {
          DRM_ERROR("Reached maximum number of debugfs files.\n");
          DRM_ERROR("Report so we increase RADEON_DEBUGFS_MAX_NUM_FILES.\n");
          return -EINVAL;
  }

This commit fixes this make, and accordingly renames:

  RADEON_DEBUGFS_MAX_NUM_FILES

to:

  RADEON_DEBUGFS_MAX_COMPONENTS
Signed-off-by: NMichael Witten <mfwitten@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      c245cb9e
  9. 19 9月, 2011 1 次提交
  11. 01 9月, 2011 1 次提交
  13. 27 7月, 2011 1 次提交
  15. 25 7月, 2011 1 次提交
  17. 18 7月, 2011 1 次提交
  19. 24 6月, 2011 1 次提交
  21. 09 6月, 2011 1 次提交
  23. 13 4月, 2011 2 次提交
  25. 31 3月, 2011 1 次提交
  27. 14 3月, 2011 1 次提交
    • D
      drm/radeon: fix problem with changing active VRAM size. (v2) · 53595338
      由 Dave Airlie 提交于 
      So we used to use lpfn directly to restrict VRAM when we couldn't
access the unmappable area, however this was removed in
93225b0d as it also restricted
the gtt placements. However it was only later noticed that this
broke on some hw.

This removes the active_vram_size, and just explicitly sets it
when it changes, TTM/drm_mm will always use the real_vram_size,
and the active vram size will change the TTM size used for lpfn
setting.

We should re-work the fpfn/lpfn to per-placement at some point
I suspect, but that is too late for this kernel.

Hopefully this addresses:
https://bugs.freedesktop.org/show_bug.cgi?id=35254

v2: fix reported useful VRAM size to userspace to be correct.
Signed-off-by: NDave Airlie <airlied@redhat.com>
      53595338
  29. 03 3月, 2011 3 次提交
  31. 23 2月, 2011 5 次提交
  33. 19 2月, 2011 1 次提交
  35. 07 2月, 2011 1 次提交
    • D
      drm: dumb scanout create/mmap for intel/radeon (v3) · ff72145b
      由 Dave Airlie 提交于 
      This is just an idea that might or might not be a good idea,
it basically adds two ioctls to create a dumb and map a dumb buffer
suitable for scanout. The handle can be passed to the KMS ioctls to create
a framebuffer.

It looks to me like it would be useful in the following cases:
a) in development drivers - we can always provide a shadowfb fallback.
b) libkms users - we can clean up libkms a lot and avoid linking
to libdrm_*.
c) plymouth via libkms is a lot easier.

Userspace bits would be just calls + mmaps. We could probably
mark these handles somehow as not being suitable for acceleartion
so as top stop people who are dumber than dumb.
Signed-off-by: NDave Airlie <airlied@redhat.com>
      ff72145b
  37. 04 2月, 2011 1 次提交
  39. 02 2月, 2011 1 次提交
  41. 17 1月, 2011 1 次提交
  43. 07 1月, 2011 8 次提交