Hi Dave,
So I heard that proper pull requests have a revert on top ;-) So here we go with my usual mid-merge-window pile of fixes.
Big fix is the duct-tape for ring init on g4x platforms, we seem to have found the magic again to make those machines as happy as before (not perfect though unfortunately, but that was never the case).
Otherwise fixes all over: - tune down some overzealous debug output - VDD power sequencing fix after resume - bunch of dsi fixes for baytrail among them hw state checker de-noising - bunch of error state capture fixes for bdw - misc tiny fixes/workarounds for various platforms
Last minute rebase was to kick out two patches that shouldn't have been in here - they're for the state checker, so 0 functional code affected.
Jani's back from vacation, so he'll take over -fixes from here.
Cc'ing Linus since you're travelling in case you want him to pick this up directly.
Cheers, Daniel
The following changes since commit a91576d7916f6cce76d30303e60e1ac47cf4a76d:
drm/ttm: Pass GFP flags in order to avoid deadlock. (2014-08-05 10:54:19 +1000)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-08-08
for you to fetch changes up to be71eabebaf9f142612d34d42292b454e984dcb5:
Revert "drm/i915: Enable semaphores on BDW" (2014-08-08 16:22:19 +0200)
---------------------------------------------------------------- Daniel Vetter (4): drm/i915: Update DRIVER_DATE to 20140725 drm/i915: Don't require dev->struct_mutex in psr_match_conditions drm/i915: Tune done rc6 enabling output drm/i915: Tune down MCH_SSKPD values warning
Deepak S (1): drm/i915: Bring GPU Freq to min while suspending.
Imre Deak (2): drm/i915: factor out intel_edp_panel_vdd_sanitize drm/i915: fix VDD state tracking after system resume
Jiri Kosina (1): drm/i915: read HEAD register back in init_ring_common() to enforce ordering
Kenneth Graunke (2): drm/i915: Refactor Broadwell PIPE_CONTROL emission into a helper. drm/i915: Add the WaCsStallBeforeStateCacheInvalidate:bdw workaround.
Mika Kuoppala (1): drm/i915: Don't accumulate hangcheck score on forward progress
Pavel Machek (1): drm/i915: work around warning in i915_gem_gtt
Rafael Barbalho (1): drm/i915: Fix crash when failing to parse MIPI VBT
Rodrigo Vivi (4): drm/i915: Fix error state collecting drm/i915: Collect gtier properly on HSW. drm/i915: Fix DEIER and GTIER collecting for BDW. Revert "drm/i915: Enable semaphores on BDW"
Shobhit Kumar (2): drm/i915: wait for all DSI FIFOs to be empty drm/i915: Add correct hw/sw config check for DSI encoder
Ville Syrjälä (1): drm/i915: Fix threshold for choosing 32 vs. 64 precisions for VLV DDL values
Zhenyu Wang (1): drm/i915: Fix drain latency precision multipler for VLV
drivers/gpu/drm/i915/i915_drv.c | 4 ++ drivers/gpu/drm/i915/i915_drv.h | 3 +- drivers/gpu/drm/i915/i915_gem.c | 2 +- drivers/gpu/drm/i915/i915_gem_gtt.c | 11 +++-- drivers/gpu/drm/i915/i915_gpu_error.c | 35 +++++++++----- drivers/gpu/drm/i915/i915_irq.c | 15 ++++-- drivers/gpu/drm/i915/i915_reg.h | 50 ++++++++++---------- drivers/gpu/drm/i915/intel_bios.c | 2 +- drivers/gpu/drm/i915/intel_display.c | 4 ++ drivers/gpu/drm/i915/intel_dp.c | 67 +++++++++++++++++++-------- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_dsi.c | 29 +++++++++++- drivers/gpu/drm/i915/intel_dsi.h | 1 + drivers/gpu/drm/i915/intel_dsi_cmd.c | 16 +++++++ drivers/gpu/drm/i915/intel_dsi_cmd.h | 1 + drivers/gpu/drm/i915/intel_dsi_pll.c | 81 +++++++++++++++++++++++++++++++++ drivers/gpu/drm/i915/intel_pm.c | 41 ++++++++--------- drivers/gpu/drm/i915/intel_ringbuffer.c | 47 +++++++++++++------ drivers/gpu/drm/i915/intel_ringbuffer.h | 2 + 19 files changed, 310 insertions(+), 102 deletions(-)
On Fri, Aug 8, 2014 at 7:34 AM, Daniel Vetter daniel.vetter@ffwll.ch wrote:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-08-08
Hmm. My laptop no longer resumes properly.
Or rather, I suspect it resumes, but the screen is black.
I will bisect, and I *will* revert if I find the offending commit. I need that laptop for travel next week.
Linus
On Fri, Aug 8, 2014 at 12:19 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Fri, Aug 8, 2014 at 7:34 AM, Daniel Vetter daniel.vetter@ffwll.ch wrote:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-08-08
Hmm. My laptop no longer resumes properly.
The problem seems to exist already with just the plain drm pull from Dave. I thought I had tested that, but apparently not.
Linus
On Fri, Aug 8, 2014 at 12:37 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
The problem seems to exist already with just the plain drm pull from Dave. I thought I had tested that, but apparently not.
Still busy bisecting (and it's going into the i915 part of Dave's drm pull, so the bisect looks sane so far), but in case some i915 person is trying to think about what it might be, it doesn't seem to be the backlight per se.
Sometimes it resumes with the backlight on and something showing on the screen, but no reaction to mouse or keyboard. And in fact, I have now gotten an X lockup twice *without* doing resume/suspend, so it seems like the whole resume/suspend thing is just a way to trigger it, not the fundamental problem.
The machine is alive (the printscreen button takes a screenshot, for example - I can tell by the sound), but the graphics side is hung.
This is a Sony Vaio Pro 11, so it's bog-standard intel graphics (Haswell ULT).
Linus
On Fri, Aug 8, 2014 at 10:30 AM, Linus Torvalds torvalds@linux-foundation.org wrote:
This is a Sony Vaio Pro 11, so it's bog-standard intel graphics (Haswell ULT).
Got this while bisecting. I'm not sure it's related, the behavior was a bit different from the other cases. So I'll try to continue bisecting, but am a bit worried that there are two possibly unrelated problems here..
------------[ cut here ]------------ WARNING: CPU: 0 PID: 1074 at drivers/gpu/drm/i915/intel_display.c:1234 intel_enable_pipe+0x3f/0x200 [i915]() cursor on pipe A assertion failure (expected off, current on) Modules linked in: rfcomm fuse ccm ip6t_rpfilter ip6t_REJECT xt_conntrack mmc_block ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat n$ snd_pcm media btusb bluetooth hid_multitouch iwlwifi snd_timer rtsx_pci i2c_i801 cfg80211 lpc_ich mfd_core mei_me snd mei shpchp soundcore sony_laptop rfkill dm_cr$ CPU: 0 PID: 1074 Comm: Xorg Not tainted 3.16.0-rc4-00378-g4dac3edfe68e #15 Hardware name: Sony Corporation SVP11213CXB/VAIO, BIOS R0270V7 05/17/2013 Call Trace: ? dump_stack+0x41/0x51 ? warn_slowpath_common+0x6d/0x90 ? warn_slowpath_fmt+0x47/0x50 ? intel_enable_pipe+0x3f/0x200 [i915] ? haswell_crtc_enable+0x425/0xa70 [i915] ? intel_crtc_update_dpms+0x5e/0x70 [i915] ? intel_connector_dpms+0x39/0x70 [i915] ? drm_mode_obj_set_property_ioctl+0x396/0x3b0 [drm] ? drm_mode_connector_property_set_ioctl+0x29/0x30 [drm] ? drm_ioctl+0x178/0x580 [drm] ? do_vfs_ioctl+0x2cf/0x4b0 ? file_has_perm+0x86/0xa0 ? __audit_syscall_exit+0x151/0x2a0 ? SyS_ioctl+0x79/0x90 ? __audit_syscall_exit+0x1f6/0x2a0 ? system_call_fastpath+0x16/0x1b ---[ end trace 86461bbc6e1418cd ]---
Does that make sense to anybody?
Linus
On Fri, Aug 8, 2014 at 1:52 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
Got this while bisecting. I'm not sure it's related
It's not.
The actual bug was panel self refresh. It's still broken, and doesn't work. So enabling it by default was a big mistake (commit b6d547791fd3: "drm/i915: Enable PSR by default.")
I've reverted that commit, you guys can try again with PSR for the next kernel release if somebody figures out how to get the damn thing *out* of panel self-refresh (because that's what I'm assuming is going on: the graphics may still work fine, but nothing updates on the panel any more).
Linus
On Sat, Aug 9, 2014 at 12:07 AM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Fri, Aug 8, 2014 at 1:52 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
Got this while bisecting. I'm not sure it's related
It's not.
Iirc it was an intermediate merge issue between two patch series. If you still see this on your tip, please scream. The warning is just one of our modeset sequence asserts firing.
The actual bug was panel self refresh. It's still broken, and doesn't work. So enabling it by default was a big mistake (commit b6d547791fd3: "drm/i915: Enable PSR by default.")
I've reverted that commit, you guys can try again with PSR for the next kernel release if somebody figures out how to get the damn thing *out* of panel self-refresh (because that's what I'm assuming is going on: the graphics may still work fine, but nothing updates on the panel any more).
A bit surprising since the only psr issue I was aware of was that we failed to entire psr (and that is likely a fumble in the tracking of cursor updates). Otoh PSR isn't enabled on baytrail because it's hang-happy there and the testcase we have for all the corner-cases in psr tracking turned out to be completely broken and no on fixed this yet. Anyway thanks for digging this up and pushing the revert yesterday - I was already in w/e mode ;-)
Cheers, Daniel
On Fri, 8 Aug 2014, Daniel Vetter wrote:
Big fix is the duct-tape for ring init on g4x platforms, we seem to have found the magic again to make those machines as happy as before (not perfect though unfortunately, but that was never the case).
I unfortunately don't agree with the last part; there are older kernels (such as 3.7) where I have never ever seen this ring initialization failure, despite it being excercised very heavily (hundreds of suspend/resume cycles on the machine I am debugging this problem on).
As I said in the bugzilla already, the affected machine will be physically present in my bag at the Kernel Summit, in case it helps you guys from Intel to debug it.
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Jiri Kosina -
Linus Torvalds