Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 17 2月, 2012 1 次提交
    • D
      drm: move pci bus master enable into driver. · 466e69b8
      由 Dave Airlie 提交于 
      The current enabling of bus mastering in the drm midlayer allows a large
race condition under kexec. When a kexec'ed kernel re-enables bus mastering
for the GPU, previously setup dma blocks may cause writes to random pieces
of memory. On radeon the writeback mechanism can cause these sorts of issues.

This patch doesn't fix the problem, but it moves the bus master enable under
the individual drivers control so they can move enabling it until later in
their load cycle and close the race.

Fix for radeon kms driver will be in a follow-up patch.
Signed-off-by: NDave Airlie <airlied@redhat.com>
      466e69b8
  3. 01 11月, 2011 1 次提交
  5. 13 7月, 2011 1 次提交
  7. 31 3月, 2011 1 次提交
  9. 07 2月, 2011 1 次提交
  11. 01 6月, 2010 1 次提交
  13. 23 4月, 2010 1 次提交
  15. 06 4月, 2010 1 次提交
  17. 01 3月, 2010 1 次提交
    • D
      drm/radeon: r100/r200 ums: block ability for userspace app to trash 0 page and beyond · 566d84d1
      由 Dave Airlie 提交于 
      radeon's have a special ability to passthrough writes in their internal
memory space directly to PCI, this ability means that if some of the internal
surfaces like the depth buffer point at 0x0, any writes to these will
go directly to RAM at 0x0 via PCI busmastering.

Now mesa used to always emit clears after emitting state, since the
radeon mesa driver was refactored a year or more ago, it was found it
could generate a clear request without ever sending any setup state to the
card. So the clear would attempt to clear the depth buffer at 0x0, which
would overwrite main memory at this point. fs corruption ensues.

Also once one app did this correctly, it would never get set back to 0
making this messy to reproduce.

The kernel should block this from happening as mesa runs without privs,
though it does require the user be connected to the current running X session.

This patch implements a check to make sure the depth offset has been set
before a depth clear occurs and if it finds one it prints a warning and
ignores the depth clear request. There is also a mesa fix to avoid sending
the badness going into mesa.

This only affects r100/r200 GPUs in user modesetting mode.
Signed-off-by: NDave Airlie <airlied@redhat.com>
      566d84d1
  19. 07 1月, 2010 1 次提交
  21. 26 10月, 2009 1 次提交
  23. 21 9月, 2009 1 次提交
  25. 31 8月, 2009 1 次提交
    • B
      radeon: Use request_firmware() · 70967ab9
      由 Ben Hutchings 提交于 
      Loosely based on a patch by
Jaswinder Singh Rajput <jaswinderlinux@gmail.com>.

KMS support by Dave Airlie <airlied@redhat.com>.

For Radeon 100- to 500-series, firmware blobs look like:
    struct {
        __be32 datah;
        __be32 datal;
    } cp_ucode[256];

For Radeon 600-series, there are two separate firmware blobs:
    __be32 me_ucode[PM4_UCODE_SIZE * 3];
    __be32 pfp_ucode[PFP_UCODE_SIZE];

For Radeon 700-series, likewise:
    __be32 me_ucode[R700_PM4_UCODE_SIZE];
    __be32 pfp_ucode[R700_PFP_UCODE_SIZE];
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      70967ab9
  27. 21 8月, 2009 1 次提交
  29. 19 6月, 2009 1 次提交
  31. 11 6月, 2009 1 次提交
  33. 04 6月, 2009 1 次提交
  35. 29 3月, 2009 1 次提交
  37. 13 3月, 2009 11 次提交
  39. 20 2月, 2009 1 次提交
  41. 08 2月, 2009 1 次提交
  43. 29 12月, 2008 3 次提交
  45. 25 11月, 2008 1 次提交
  47. 11 11月, 2008 1 次提交
    • D
      drm/radeon: map registers at load time · 78538bf1
      由 Dave Airlie 提交于 
      Now that the radeon driver has suspend/resume functions, it needs to map its
registers at load time or it will likely crash if a suspend operation occurs
before the driver has been initialized.

This patch moves the register mapping code from firstopen to load and makes
the mapping into a _DRM_DRIVER one so that the core won't remove it at
lastclose time.

Fixes (at least partially) kernel bz #11891.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@linux.ie>
      78538bf1
  49. 28 10月, 2008 1 次提交
  51. 18 10月, 2008 3 次提交