1. 20 8月, 2012 1 次提交
  2. 13 8月, 2012 1 次提交
  3. 20 7月, 2012 1 次提交
  4. 16 6月, 2012 2 次提交
  5. 02 6月, 2012 1 次提交
  6. 17 5月, 2012 1 次提交
  7. 01 5月, 2012 1 次提交
  8. 24 4月, 2012 1 次提交
  9. 26 3月, 2012 1 次提交
  10. 21 3月, 2012 1 次提交
  11. 07 3月, 2012 1 次提交
  12. 13 2月, 2012 2 次提交
    • J
      drm/radeon: add support for evergreen/ni tiling informations v11 · 285484e2
      Jerome Glisse 提交于
      evergreen and northern island gpu needs more informations for 2D tiling
      than previous r6xx/r7xx. Add field to tiling ioctl to allow userspace
      to provide those.
      
      The v8 cs checking change to track color view on r6xx/r7xx doesn't
      affect old userspace as old userspace always emited 0 for this register.
      
      v2 fix r6xx/r7xx 2D tiling computation
      v3 fix r6xx/r7xx height align for untiled surface & add support for
         tile split on evergreen and newer
      v4 improve tiling debugging output
      v5 fix tile split code for evergreen and newer
      v6 set proper tile split for crtc register
      v7 fix tile split limit value
      v8 add COLOR_VIEW checking to r6xx/r7xx checker, add evergreen cs
         checking, update safe reg for r600, evergreen and cayman.
         Evergreen checking need some work around for stencil alignment
         issues
      v9 fix tile split value range, fix compressed texture handling and
         mipmap calculation, allow evergreen check to be silencious in
         front of current broken userspace (depth/stencil alignment issue)
      v10 fix eg 3d texture and compressed texture, fix r600 depth array,
          fix r600 color view computation, add support for evergreen stencil
          split
      v11 more verbose debugging in some case
      Signed-off-by: NJerome Glisse <jglisse@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      285484e2
    • M
      drm/radeon/kms: add support for streamout v7 · dd220a00
      Marek Olšák 提交于
      v2: agd5f: add strmout CS checking, copy_dw register checking
      
      v3: agd5f: don't use cs_check_reg() for copy_dw checking as it
      will incorrectly patch the command stream for certain regs.
      
      v4: agd5f: add warning if safe reg check fails for copy_dw
      
      v5: agd5f: add stricter checking for 6xx/7xx
      
      v6: agd5f: add range checking for copy_dw on eg+,
      add sx_surface_sync to safe reg list for 7xx.
      
      v7: agd5f: add stricter checking for eg+
      Signed-off-by: NMarek Olšák <maraeo@gmail.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      dd220a00
  13. 21 12月, 2011 1 次提交
  14. 18 10月, 2011 1 次提交
  15. 07 7月, 2011 1 次提交
  16. 02 6月, 2011 1 次提交
  17. 23 2月, 2011 1 次提交
  18. 14 2月, 2011 1 次提交
  19. 07 1月, 2011 1 次提交
  20. 22 11月, 2010 1 次提交
  21. 18 11月, 2010 1 次提交
  22. 15 11月, 2010 1 次提交
  23. 06 10月, 2010 1 次提交
  24. 02 8月, 2010 3 次提交
  25. 31 3月, 2010 1 次提交
  26. 11 2月, 2010 1 次提交
    • J
      drm/radeon/kms: r600/r700 command stream checker · 961fb597
      Jerome Glisse 提交于
      This patch add cs checker to r600/r700 hw. Command stream checking
      will rewrite some of the cs value in order to restrict GPU access
      to BO size. This doesn't break old userspace but just enforce safe
      value. It should break any things that was using the r600/r700 cs
      ioctl to do forbidden things (malicious software), though we are
      not aware of such things.
      
      Here is the list of thing we check :
      - enforcing resource size
      - enforcing color buffer slice tile max, will restrict cb access
      - enforcing db buffer slice tile max, will restrict db access
      
      We don't check for shader bigger than the BO in which they are
      supposed to be, such use would lead to GPU lockup and is harmless
      from security POV, as far as we can tell (note that even checking
      for this wouldn't prevent someone to write bogus shader that lead
      to lockup).
      
      This patch has received as much testing as humanly possible with
      old userspace to check that it didn't break such configuration.
      However not all the applications out there were tested, thus it
      might broke some odd, rare applications.
      
      [airlied: fix rules for cs checker for parallel builds]
      Signed-off-by: NJerome Glisse <jglisse@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      961fb597
  27. 21 1月, 2010 1 次提交
    • J
      drm/radeon: r6xx/r7xx possible security issue, system ram access · c8c15ff1
      Jerome Glisse 提交于
      This patch workaround a possible security issue which can allow
      user to abuse drm on r6xx/r7xx hw to access any system ram memory.
      This patch doesn't break userspace, it detect "valid" old use of
      CB_COLOR[0-7]_FRAG & CB_COLOR[0-7]_TILE registers and overwritte
      the address these registers are pointing to with the one of the
      last color buffer. This workaround will work for old mesa &
      xf86-video-ati and any old user which did use similar register
      programming pattern as those (we expect that there is no others
      user of those ioctl except possibly a malicious one). This patch
      add a warning if it detects such usage, warning encourage people
      to update their mesa & xf86-video-ati. New userspace will submit
      proper relocation.
      
      Fix for xf86-video-ati / mesa (this kernel patch is enough to
      prevent abuse, fix for userspace are to set proper cs stream and
      avoid kernel warning) :
      http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=95d63e408cc88b6934bec84a0b1ef94dfe8bee7b
      http://cgit.freedesktop.org/mesa/mesa/commit/?id=46dc6fd3ed5ef96cda53641a97bc68c3bc104a9f
      
      Abusing this register to perform system ram memory is not easy,
      here is outline on how it could be achieve. First attacker must
      have access to the drm device and be able to submit command stream
      throught cs ioctl. Then attacker must build a proper command stream
      for r6xx/r7xx hw which will abuse the FRAG or TILE buffer to
      overwrite the GPU GART which is in VRAM. To achieve so attacker
      as to setup CB_COLOR[0-7]_FRAG or CB_COLOR[0-7]_TILE to point
      to the GPU GART, then it has to find a way to write predictable
      value into those buffer (with little cleverness i believe this
      can be done but this is an hard task). Once attacker have such
      program it can overwritte GPU GART to program GPU gart to point
      anywhere in system memory. It then can reusse same method as he
      used to reprogram GART to overwritte the system ram through the
      GART mapping. In the process the attacker has to be carefull to
      not overwritte any sensitive area of the GART table, like ring
      or IB gart entry as it will more then likely lead to GPU lockup.
      Bottom line is that i think it's very hard to use this flaw
      to get system ram access but in theory one can achieve so.
      
      Side note: I am not aware of anyone ever using the GPU as an
      attack vector, nevertheless we take great care in the opensource
      driver to try to detect and forbid malicious use of GPU. I don't
      think the closed source driver are as cautious as we are.
      Signed-off-by: NJerome Glisse <jglisse@redhat.com>
      Signed-off-by: NDave Airlie <airlied@linux.ie>
      c8c15ff1
  28. 08 12月, 2009 1 次提交
  29. 02 12月, 2009 2 次提交
    • A
      drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3) · d8f60cfc
      Alex Deucher 提交于
      This enables the use of interrupts on r6xx/r7xx hardware.
      Interrupts are implemented via a ring buffer.  The GPU adds
      interrupts vectors to the ring and the host reads them off
      in the interrupt handler.  The interrupt controller requires
      firmware like the CP.  This firmware must be installed and
      accessble to the firmware loader for interrupts to function.
      
      MSIs don't seem to work on my RS780.  They work fine on all
      my discrete cards.  I'm not sure about other RS780s or
      RS880s.  I've disabled MSIs on RS780 and RS880, but it would
      probably be worth checking on some other systems.
      
      v2 - fix some checkpatch.pl problems;
           re-read the disp int status reg if we restart the ih;
      
      v3 - remove the irq handler if r600_irq_init() fails;
           remove spinlock in r600_ih_ring_fini();
           move ih rb overflow check to r600_get_ih_wptr();
           move irq ack to separate function;
      Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      d8f60cfc
    • D
      drm/radeon/kms: add HDP flushing for all GPUs. · 23956dfa
      Dave Airlie 提交于
      rendercheck under kms on r600s was failing due to HDP flushing not happening.
      
      This adds HDP flushing to the object wait function for r100->r700 families.
      
      rendercheck passes basic tests on r600 with this change.
      Acked-by: NAlex Deucher <alexdeucher@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      23956dfa
  30. 10 11月, 2009 1 次提交
  31. 26 10月, 2009 1 次提交
  32. 08 10月, 2009 1 次提交
  33. 21 9月, 2009 1 次提交
    • D
      drm/vgaarb: add VGA arbitration support to the drm and kms. · 28d52043
      Dave Airlie 提交于
      VGA arb requires DRM support for non-kms drivers, to turn on/off
      irqs when disabling the mem/io regions.
      
      VGA arb requires KMS support for GPUs where we can turn off VGA
      decoding. Currently we know how to do this for intel and radeon
      kms drivers, which allows them to be removed from the arbiter.
      
      This patch comes from Fedora rawhide kernel.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      28d52043
  34. 08 9月, 2009 1 次提交
    • J
      drm/radeon/kms: add r600 KMS support · 3ce0a23d
      Jerome Glisse 提交于
      This adds the r600 KMS + CS support to the Linux kernel.
      
      The r600 TTM support is quite basic and still needs more
      work esp around using interrupts, but the polled fencing
      should work okay for now.
      
      Also currently TTM is using memcpy to do VRAM moves,
      the code is here to use a 3D blit to do this, but
      isn't fully debugged yet.
      
      Authors:
      Alex Deucher <alexdeucher@gmail.com>
      Dave Airlie <airlied@redhat.com>
      Jerome Glisse <jglisse@redhat.com>
      Signed-off-by: NJerome Glisse <jglisse@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      3ce0a23d