1. 02 10月, 2017 1 次提交
  2. 28 9月, 2017 1 次提交
  3. 22 9月, 2017 1 次提交
  4. 07 9月, 2017 2 次提交
  5. 06 9月, 2017 1 次提交
  6. 23 8月, 2017 1 次提交
    • R
      drm/i915/cfl: Coffee Lake works on Kaby Lake PCH. · eb371933
      Rodrigo Vivi 提交于
      Coffee Lake CPU on Kaby Lake PCH is possible.
      It does exist, and it does work.
      
      The only missed case was this warning here noticed
      by Wendy who could get one system with this configuration
      and reported the issue for us:
      
      Hardware Configuration
      Board ID KBL S DDR4 UDIMM EV CRB
      Processor    Intel® Processor code named Coffee Lake S, (6+2), 6 cores 12 threads, GT2, A0 (Internal) (QNJ4)
      
      [ 3.220585] WARNING: CPU: 10 PID: 206 at drivers/gpu/drm/i915/i915_drv.c:340 i915_driver_load+0x1210/0x1660 [i915]
      [ 3.221312] Modules linked in: hid_generic usbhid i915 i2c_algo_bit drm_kms_helper e1000e syscopyarea sysfillrect sysimgblt nvme fb_sys_fops ptp ahci i2c_hid drm pps_core nvme_core libahci wmi hid video
      [ 3.222050] CPU: 10 PID: 206 Comm: systemd-udevd Not tainted 4.13.0-rc5-intel-next+ #1
      [ 3.222706] Hardware name: Intel Corporation Kabylake Client platform/KBL S DDR4 UDIMM EV CRB, BIOS KBLSE2R1.R00.X089.P00.1705051000 05/05/2017
      
      Cc: Wendy Wang <wendy.wang@intel.com>
      Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170821235056.9015-1-rodrigo.vivi@intel.com
      eb371933
  7. 15 8月, 2017 1 次提交
  8. 08 8月, 2017 1 次提交
  9. 04 8月, 2017 2 次提交
  10. 27 7月, 2017 4 次提交
  11. 21 7月, 2017 1 次提交
  12. 19 7月, 2017 3 次提交
  13. 06 7月, 2017 1 次提交
  14. 03 7月, 2017 1 次提交
    • V
      drm/i915: Disable MSI for all pre-gen5 · ce3f7163
      Ville Syrjälä 提交于
      We have pretty clear evidence that MSIs are getting lost on g4x and
      somehow the interrupt logic doesn't seem to recover from that state
      even if we try hard to clear the IIR.
      
      Disabling IER around the normal IIR clearing in the irq handler isn't
      sufficient to avoid this, so the problem really seems to be further
      up the interrupt chain. This should guarantee that there's always
      an edge if any IIR bits are set after the interrupt handler is done,
      which should normally guarantee that the CPU interrupt is generated.
      That approach seems to work perfectly on VLV/CHV, but apparently
      not on g4x.
      
      MSI is documented to be broken on 965gm at least. The chipset spec
      says MSI is defeatured because interrupts can be delayed or lost,
      which fits well with what we're seeing on g4x. Previously we've
      already disabled GMBUS interrupts on g4x because somehow GMBUS
      manages to raise legacy interrupts even when MSI is enabled.
      
      Since there's such widespread MSI breakahge all over in the pre-gen5
      land let's just give up on MSI on these platforms.
      
      Seqno reporting might be negatively affected by this since the legcy
      interrupts aren't guaranteed to be ordered with the seqno writes,
      whereas MSI interrupts may be? But an occasioanlly missed seqno
      seems like a small price to pay for generally working interrupts.
      
      Cc: stable@vger.kernel.org
      Cc: Diego Viola <diego.viola@gmail.com>
      Tested-by: NDiego Viola <diego.viola@gmail.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101261Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170626203051.28480-1-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      (cherry picked from commit e38c2da0)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      ce3f7163
  15. 27 6月, 2017 1 次提交
    • V
      drm/i915: Disable MSI for all pre-gen5 · e38c2da0
      Ville Syrjälä 提交于
      We have pretty clear evidence that MSIs are getting lost on g4x and
      somehow the interrupt logic doesn't seem to recover from that state
      even if we try hard to clear the IIR.
      
      Disabling IER around the normal IIR clearing in the irq handler isn't
      sufficient to avoid this, so the problem really seems to be further
      up the interrupt chain. This should guarantee that there's always
      an edge if any IIR bits are set after the interrupt handler is done,
      which should normally guarantee that the CPU interrupt is generated.
      That approach seems to work perfectly on VLV/CHV, but apparently
      not on g4x.
      
      MSI is documented to be broken on 965gm at least. The chipset spec
      says MSI is defeatured because interrupts can be delayed or lost,
      which fits well with what we're seeing on g4x. Previously we've
      already disabled GMBUS interrupts on g4x because somehow GMBUS
      manages to raise legacy interrupts even when MSI is enabled.
      
      Since there's such widespread MSI breakahge all over in the pre-gen5
      land let's just give up on MSI on these platforms.
      
      Seqno reporting might be negatively affected by this since the legcy
      interrupts aren't guaranteed to be ordered with the seqno writes,
      whereas MSI interrupts may be? But an occasioanlly missed seqno
      seems like a small price to pay for generally working interrupts.
      
      Cc: stable@vger.kernel.org
      Cc: Diego Viola <diego.viola@gmail.com>
      Tested-by: NDiego Viola <diego.viola@gmail.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101261Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170626203051.28480-1-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e38c2da0
  16. 26 6月, 2017 1 次提交
  17. 23 6月, 2017 4 次提交
  18. 21 6月, 2017 5 次提交
  19. 20 6月, 2017 1 次提交
  20. 17 6月, 2017 1 次提交
  21. 16 6月, 2017 2 次提交
  22. 15 6月, 2017 2 次提交
  23. 09 6月, 2017 1 次提交
  24. 07 6月, 2017 1 次提交