1. 09 7月, 2015 3 次提交
    • G
      drm/radeon: fix HDP flushing · 54e03986
      Grigori Goronzy 提交于
      This was regressed by commit 39e7f6f8, although I don't know of any
      actual issues caused by it.
      
      The storage domain is read without TTM locking now, but the lock
      never helped to prevent any races.
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NGrigori Goronzy <greg@chown.ath.cx>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      54e03986
    • G
      drm/radeon: use RCU query for GEM_BUSY syscall · 828202a3
      Grigori Goronzy 提交于
      We don't need to call the (expensive) radeon_bo_wait, checking the
      fences via RCU is much faster. The reservation done by radeon_bo_wait
      does not save us from any race conditions.
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NGrigori Goronzy <greg@chown.ath.cx>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      828202a3
    • M
      drm/radeon: Handle irqs only based on irq ring, not irq status regs. · 07f18f0b
      Mario Kleiner 提交于
      Trying to resolve issues with missed vblanks and impossible
      values inside delivered kms pageflip completion events showed
      that radeon's irq handling sometimes doesn't handle valid irqs,
      but silently skips them. This was observed for vblank interrupts.
      
      Although those irqs have corresponding events queued in the gpu's
      irq ring at time of interrupt, and therefore the corresponding
      handling code gets triggered by these events, the handling code
      sometimes silently skipped processing the irq. The reason for those
      skips is that the handling code double-checks for each irq event if
      the corresponding irq status bits in the irq status registers
      are set. Sometimes those bits are not set at time of check
      for valid irqs, maybe due to some hardware race on some setups?
      
      The problem only seems to happen on some machine + card combos
      sometimes, e.g., never happened during my testing of different PC
      cards of the DCE-2/3/4 generation a year ago, but happens consistently
      now on two different Apple Mac cards (RV730, DCE-3, Apple iMac and
      Evergreen JUNIPER, DCE-4 in a Apple MacPro). It also doesn't happen
      at each interrupt but only occassionally every couple of
      hundred or thousand vblank interrupts.
      
      This results in XOrg warning messages like
      
      "[  7084.472] (WW) RADEON(0): radeon_dri2_flip_event_handler:
      Pageflip completion event has impossible msc 420120 < target_msc 420121"
      
      as well as skipped frames and problems for applications that
      use kms pageflip events or vblank events, e.g., users of DRI2 and
      DRI3/Present, Waylands Weston compositor, etc. See also
      
      https://bugs.freedesktop.org/show_bug.cgi?id=85203
      
      After some talking to Alex and Michel, we decided to fix this
      by turning the double-check for asserted irq status bits into a
      warning. Whenever a irq event is queued in the IH ring, always
      execute the corresponding interrupt handler. Still check the irq
      status bits, but only to log a DRM_DEBUG message on a mismatch.
      
      This fixed the problems reliably on both previously failing
      cards, RV-730 dual-head tested on both crtcs (pipes D1 and D2)
      and a triple-output Juniper HD-5770 card tested on all three
      available crtcs (D1/D2/D3). The r600 and evergreen irq handling
      is therefore tested, but the cik an si handling is only compile
      tested due to lack of hw.
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
      CC: Michel Dänzer <michel.daenzer@amd.com>
      CC: Alex Deucher <alexander.deucher@amd.com>
      CC: <stable@vger.kernel.org> # v3.16+
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      07f18f0b
  2. 30 6月, 2015 2 次提交
  3. 29 6月, 2015 4 次提交
  4. 19 6月, 2015 2 次提交
  5. 16 6月, 2015 1 次提交
  6. 11 6月, 2015 4 次提交
  7. 03 6月, 2015 2 次提交
  8. 02 6月, 2015 1 次提交
  9. 29 5月, 2015 1 次提交
    • D
      radeon: Deinline indirect register accessor functions · 9e5acbc2
      Denys Vlasenko 提交于
      This patch deinlines indirect register accessor functions.
      
      These functions perform two mmio accesses, framed by spin lock/unlock.
      Spin lock/unlock by itself takes more than 50 cycles in ideal case
      (if lock is exclusively cached on current CPU).
      
      With this .config: http://busybox.net/~vda/kernel_config,
      after uninlining these functions have sizes and callsite counts
      as follows:
      
      r600_uvd_ctx_rreg: 111 bytes, 4 callsites
      r600_uvd_ctx_wreg: 113 bytes, 5 callsites
      eg_pif_phy0_rreg: 106 bytes, 13 callsites
      eg_pif_phy0_wreg: 108 bytes, 13 callsites
      eg_pif_phy1_rreg: 107 bytes, 13 callsites
      eg_pif_phy1_wreg: 108 bytes, 13 callsites
      rv370_pcie_rreg: 111 bytes, 21 callsites
      rv370_pcie_wreg: 113 bytes, 24 callsites
      r600_rcu_rreg: 111 bytes, 16 callsites
      r600_rcu_wreg: 113 bytes, 25 callsites
      cik_didt_rreg: 106 bytes, 10 callsites
      cik_didt_wreg: 107 bytes, 10 callsites
      tn_smc_rreg: 106 bytes, 126 callsites
      tn_smc_wreg: 107 bytes, 116 callsites
      eg_cg_rreg: 107 bytes, 20 callsites
      eg_cg_wreg: 108 bytes, 52 callsites
      
      Functions r100_mm_rreg() and r100_mm_rreg() have a fast path and
      a locked (slow) path. This patch deinlines only slow path.
      
      r100_mm_rreg_slow: 78 bytes, 2083 callsites
      r100_mm_wreg_slow: 81 bytes, 3570 callsites
      
      Reduction in code size is more than 65,000 bytes:
      
          text     data      bss       dec     hex filename
      85740176 22294680 20627456 128662312 7ab3b28 vmlinux.before
      85674192 22294776 20627456 128598664 7aa4288 vmlinux
      Signed-off-by: NDenys Vlasenko <dvlasenk@redhat.com>
      Cc: Christian König <christian.koenig@amd.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      9e5acbc2
  10. 28 5月, 2015 6 次提交
  11. 27 5月, 2015 1 次提交
  12. 26 5月, 2015 13 次提交