{"push_id":1438705574,"size":9,"distinct_size":0,"ref":"refs/heads/for-linux-next","head":"7a9e10253e9e52451bbe80ddb2874368dbd240a3","before":"cf30f5094adc028d5512f4fbb585f3592768f41d","commits":[{"sha":"ce1135c7de646bd608784657471b934d6e50195d","author":{"name":"Chris Wilson","email":"4181b934c2715a2bba60cdb3cc1b35b2777d1c23@chris-wilson.co.uk"},"message":"drm/i915: Complete requests in nop_submit_request\n\nSince the submit/execute split in commit d55ac5bf97c6 (\"drm/i915: Defer\ntransfer onto execution timeline to actual hw submission\") the\nglobal seqno advance was deferred until the submit_request callback.\nAfter wedging the GPU, we were installing a nop_submit_request handler\n(to avoid waking up the dead hw) but I had missed converting this over\nto the new scheme. Under the new scheme, we have to explicitly call\ni915_gem_submit_request() from the submit_request handler to mark the\nrequest as on the hardware. If we don't the request is always pending,\nand any waiter will continue to wait indefinitely and hangcheck will not\nbe able to resolve the lockup.\n\nReferences: https://bugs.freedesktop.org/show_bug.cgi?id=98748\nTestcase: igt/gem_eio/in-flight\nFixes: d55ac5bf97c6 (\"drm/i915: Defer transfer onto execution timeline to actual hw submission\")\nSigned-off-by: Chris Wilson <chris@chris-wilson.co.uk>\nCc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>\nReviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>\nLink: http://patchwork.freedesktop.org/patch/msgid/20161122144121.7379-3-chris@chris-wilson.co.uk\n(cherry picked from commit 3dcf93f7f23a61e867a5ccadaf651cb2d29229fd)\nSigned-off-by: Jani Nikula <jani.nikula@intel.com>","distinct":false,"url":"https://api.github.com/repos/freedesktop/drm-intel/commits/ce1135c7de646bd608784657471b934d6e50195d"},{"sha":"991015743272cd2836b1d1b94b6894e2269e241f","author":{"name":"Ville Syrjälä","email":"97bbb7c58ba09bd338b1646c9fa52af32290a230@linux.intel.com"},"message":"drm/i915: Make skl_write_{plane,cursor}_wm() static\n\nSomeone forgot to make skl_write_{plane,cursor}_wm() static when\nremoving the prototypes from the header. Sparse isn't pleased.\n\nCc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>\nCc: Lyude <cpaul@redhat.com>\nCc: Matt Roper <matthew.d.roper@intel.com>\nFixes: e62929b3f628 (\"drm/i915/gen9+: Program watermarks as a separate step during evasion, v3.\")\nSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nLink: http://patchwork.freedesktop.org/patch/msgid/1479846113-24745-1-git-send-email-ville.syrjala@linux.intel.com\nReviewed-by: Lyude <lyude@redhat.com>\nReviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>\n(cherry picked from commit d9348dec902ff36e0f1b25ccf1f4be25fc1ac409)\nSigned-off-by: Jani Nikula <jani.nikula@intel.com>","distinct":false,"url":"https://api.github.com/repos/freedesktop/drm-intel/commits/991015743272cd2836b1d1b94b6894e2269e241f"},{"sha":"14676ec6b1a6f2f7fa0bafd98ab42ce77be7a7d4","author":{"name":"Ville Syrjälä","email":"97bbb7c58ba09bd338b1646c9fa52af32290a230@linux.intel.com"},"message":"drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things\n\nWhen we end up not recomputing the cdclk, we need to populate\nintel_state->cdclk with the \"atomic_cdclk_freq\" instead of the\ncurrent cdclk_freq. When no pipes are active, the actual cdclk_freq\nmay be lower than what the configuration of the planes and\npipes would require from the point of view of the software state.\n\nThis fixes bogus WARNS from skl_max_scale() which is trying to check\nthe plane software state against the cdclk frequency. So any time\nit got called during DPMS off for instance, we might have tripped\nthe warn if the current mode would have required a higher than\nminimum cdclk.\n\nv2: Drop the dev_cdclk stuff (Maarten)\n\nCc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>\nCc: Mika Kahola <mika.kahola@intel.com>\nCc: bruno.pagani@ens-lyon.org\nCc: Daniel J Blueman <daniel.blueman@gmail.com>\nCc: Paul Bolle <pebolle@tiscali.nl>\nCc: Joseph Yasi <joe.yasi@gmail.com>\nTested-by: Paul Bolle <pebolle@tiscali.nl>\nTested-by: Joseph Yasi <joe.yasi@gmail.com> (v1)\nCc: <stable@vger.kernel.org> # v4.6+\nFixes: 1a617b77658e (\"drm/i915: Keep track of the cdclk as if all crtc's were active.\")\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98214\nSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nReviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>\nLink: http://patchwork.freedesktop.org/patch/msgid/1479141311-11904-2-git-send-email-ville.syrjala@linux.intel.com\n(cherry picked from commit e0ca7a6be38ce603d26df5707c22e53870a623e0)\nSigned-off-by: Jani Nikula <jani.nikula@intel.com>","distinct":false,"url":"https://api.github.com/repos/freedesktop/drm-intel/commits/14676ec6b1a6f2f7fa0bafd98ab42ce77be7a7d4"},{"sha":"1f3dc3e334c1192ebe2939ea17ba12f4776f90c3","author":{"name":"Ville Syrjälä","email":"97bbb7c58ba09bd338b1646c9fa52af32290a230@linux.intel.com"},"message":"drm/i915: Initialize dev_priv->atomic_cdclk_freq at init time\n\nLooks like we're only initializing dev_priv->atomic_cdclk_freq\nat resume and commit times, not at init time. Let's do that as\nwell.\n\nWe're now hitting the 'WARN_ON(intel_state->cdclk == 0)' in\nhsw_compute_linetime_wm() on account of populating\nintel_state->cdclk from dev_priv->atomic_cdclk_freq.\nPreviously we were mispopulating intel_state->cdclk with\ndev_priv->cdclk_freq which always had a proper value at init\ntime and hence the WARN_ON() didn't trigger.\n\nCc: <stable@vger.kernel.org> # 4.6+: 14676ec6b1a6 drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things\nCc: <stable@vger.kernel.org> # 4.6+\nCc: Matthew Auld <matthew.auld@intel.com>\nReported-by: Matthew Auld <matthew.auld@intel.com>\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98902\nFixes: 14676ec6b1a6 (\"drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things\")\nSigned-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nLink: http://patchwork.freedesktop.org/patch/msgid/1480428837-4207-1-git-send-email-ville.syrjala@linux.intel.com\nTested-by: Matthew Auld <matthew.auld@intel.com>\nReviewed-by: Matthew Auld <matthew.auld@intel.com>\n(cherry picked from commit 6a259b1f8a9e99b1ed114f8bf8b0cfccee130e54)\nSigned-off-by: Jani Nikula <jani.nikula@intel.com>","distinct":false,"url":"https://api.github.com/repos/freedesktop/drm-intel/commits/1f3dc3e334c1192ebe2939ea17ba12f4776f90c3"},{"sha":"6cef2f8477206fc0a6961358e8ef9d01a3201a5c","author":{"name":"Chris Wilson","email":"4181b934c2715a2bba60cdb3cc1b35b2777d1c23@chris-wilson.co.uk"},"message":"drm/i915/debugfs: Drop i915_hws_info\n\ni915_hws_info() has not been kept upto date (missing new engines) and so\nI consider it to be unused. HWS is included in the error state, which\nwould be an avenue to retrieving it if required in future (possibly via\ni915_engine_info). As it is currently oopsing with an rpm testcase, just\nremove it.\n\nFixes: 3b3f1650b1ca (\"drm/i915: Allocate intel_engine_cs structure only for the enabled engines\")\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98838\nSigned-off-by: Chris Wilson <chris@chris-wilson.co.uk>\nCc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>\nCc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>\nLink: http://patchwork.freedesktop.org/patch/msgid/20161124093401.18852-1-chris@chris-wilson.co.uk\nReviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>\n(cherry picked from commit 30576a2c462d9658508c3de67601aa565f973064)\nSigned-off-by: Jani Nikula <jani.nikula@intel.com>","distinct":false,"url":"https://api.github.com/repos/freedesktop/drm-intel/commits/6cef2f8477206fc0a6961358e8ef9d01a3201a5c"},{"sha":"3acd24017563e1ce333eb52d37b7e69480cd4100","author":{"name":"Chris Wilson","email":"4181b934c2715a2bba60cdb3cc1b35b2777d1c23@chris-wilson.co.uk"},"message":"drm/i915/debugfs: Increment return value of gt.next_seqno\n\nThe i915_next_seqno read value is to be the next seqno used by the\nkernel. However, in the conversion to atomics ops for gt.next_seqno, in\ncommit 28176ef4cfa5 (\"drm/i915: Reserve space in the global seqno during\nrequest allocation\"), this was changed from a post-increment to a\npre-increment. This increment was missed from the value reported by\ndebugfs, so in effect it was reporting the current seqno (last\nassigned), not the next seqno.\n\nFixes: 28176ef4cfa5 (\"drm/i915: Reserve space in the global seqno during request allocation\")\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81209\nSigned-off-by: Chris Wilson <chris@chris-wilson.co.uk>\nCc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>\nLink: http://patchwork.freedesktop.org/patch/msgid/20161124094752.19129-1-chris@chris-wilson.co.uk\nReviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>\n(cherry picked from commit 9607ae79710afb453173b90d5bf564788a6e09b1)\nSigned-off-by: Jani Nikula <jani.nikula@intel.com>","distinct":false,"url":"https://api.github.com/repos/freedesktop/drm-intel/commits/3acd24017563e1ce333eb52d37b7e69480cd4100"},{"sha":"b9f16ff2730c1be06ca89518d5c369b12ffbbc6c","author":{"name":"Libin Yang","email":"4936fb7317200ba64732f39287100143cc2bce17@intel.com"},"message":"drm/i915/audio: fix hdmi audio noise issue\n\nSome monitors will have noise or even no sound after\napplying the patch 6014ac12.\n\nIn patch 6014ac12, it will reset the cts value to 0 for HDMI.\nHowever, we need to disable Enable CTS or M Prog bit. This is\nthe initial setting after HW reset.\n\nFixes: 6014ac122ed0 (\"drm/i915/audio: set proper N/M in modeset\")\nSigned-off-by: Libin Yang <libin.yang@intel.com>\nSigned-off-by: Jani Nikula <jani.nikula@intel.com>\nLink: http://patchwork.freedesktop.org/patch/msgid/1478853988-139842-1-git-send-email-libin.yang@intel.com\n(cherry picked from commit 60abfbb86a8d51576f90c5adcbb4f547a2952782)\nSigned-off-by: Jani Nikula <jani.nikula@intel.com>","distinct":false,"url":"https://api.github.com/repos/freedesktop/drm-intel/commits/b9f16ff2730c1be06ca89518d5c369b12ffbbc6c"},{"sha":"0e932c080cdee38e873476df92d7dc02bdb023bc","author":{"name":"Chris Wilson","email":"4181b934c2715a2bba60cdb3cc1b35b2777d1c23@chris-wilson.co.uk"},"message":"drm/i915: Hold a reference on the request for its fence chain\n\nCurrently, we have an active reference for the request until it is\nretired. Though it cannot be retired before it has been executed by\nhardware, the request may be completed before we have finished\nprocessing the execute fence, i.e. we may continue to process that fence\nas we free the request.\n\nFixes: 5590af3e115a (\"drm/i915: Drive request submission through fence callbacks\")\nFixes: 23902e49c999 (\"drm/i915: Split request submit/execute phase into two\")\nSigned-off-by: Chris Wilson <chris@chris-wilson.co.uk>\nReviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>\nLink: http://patchwork.freedesktop.org/patch/msgid/20161125131718.20978-3-chris@chris-wilson.co.uk\n(cherry picked from commit 48bc2a4a427ad81578f887d71d45794619a77211)\nSigned-off-by: Jani Nikula <jani.nikula@intel.com>","distinct":false,"url":"https://api.github.com/repos/freedesktop/drm-intel/commits/0e932c080cdee38e873476df92d7dc02bdb023bc"},{"sha":"7a9e10253e9e52451bbe80ddb2874368dbd240a3","author":{"name":"Chris Wilson","email":"4181b934c2715a2bba60cdb3cc1b35b2777d1c23@chris-wilson.co.uk"},"message":"drm/i915: Move priority bumping for flips earlier\n\nDavid found another issue with priority bumping from mmioflips, where we\nare accessing the requests concurrently to them being retired and freed.\nWhilst we are skipping the dependency if has been submitted, that is not\nsufficient to stop the dependency from disappearing if another thread\nretires that request. To prevent we can either employ the struct_mutex (or a\nrequest mutex in the future) to serialise retiring before it is freed.\nAlternatively, we need to keep the dependencies alive using RCU whilst\nthey are being accessed via the DFS.\n\n[ 1746.698111] general protection fault: 0000 [#1] PREEMPT SMP\n[ 1746.698305] Modules linked in: snd_hda_intel snd_hda_codec snd_hwdep x86_pkg_temp_thermal snd_hda_core coretemp crct10dif_pclmul crc32_pclmul snd_pcm ghash_clmulni_intel mei_me mei i915 e1000e ptp pps_core i2c_hid\n[ 1746.698750] CPU: 1 PID: 6716 Comm: kworker/u8:2 Not tainted 4.9.0-rc6-CI-Nightly_816+ #1\n[ 1746.698871] Hardware name: GIGABYTE GB-BKi7A-7500/MFLP7AP-00, BIOS F1 07/27/2016\n[ 1746.699125] Workqueue: events_unbound intel_mmio_flip_work_func [i915]\n[ 1746.699266] task: ffff880260a5e800 task.stack: ffffc90000f6c000\n[ 1746.699361] RIP: 0010:[<ffffffffa006595d>]  [<ffffffffa006595d>] execlists_schedule+0x8d/0x300 [i915]\n[ 1746.699632] RSP: 0018:ffffc90000f6fcd8  EFLAGS: 00010206\n[ 1746.699724] RAX: dead0000000000f8 RBX: ffff8801f64b2bf0 RCX: ffff8801f64b2c10\n[ 1746.699842] RDX: dead000000000100 RSI: 0000000000000000 RDI: ffff8801f64b0458\n[ 1746.699972] RBP: ffffc90000f6fd68 R08: ffff88026488dc00 R09: 0000000000000002\n[ 1746.700090] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000400\n[ 1746.700195] R13: ffffc90000f6fcf0 R14: ffff88020955aa40 R15: ffff88020955aa68\n[ 1746.700307] FS:  0000000000000000(0000) GS:ffff88026dc80000(0000) knlGS:0000000000000000\n[ 1746.700435] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1746.700532] CR2: 0000000002a69e90 CR3: 0000000002c07000 CR4: 00000000003406e0\n[ 1746.700635] Stack:\n[ 1746.700682]  ffff880260a5e880 ffffc90000f6fd50 ffffffff810af69a ffffc90000f6fd28\n[ 1746.700827]  ffff88020955a628 ffff8801e1eaebf0 0000000000000020 0000000000000000\n[ 1746.700947]  00000196af1edc96 ffff88025dfa4000 ffff8801f0b030a8 ffffc90000f6fcf0\n[ 1746.701071] Call Trace:\n[ 1746.701117]  [<ffffffff810af69a>] ? dequeue_entity+0x25a/0xb50\n[ 1746.701260]  [<ffffffffa00516be>] fence_set_priority+0x7e/0x80 [i915]\n[ 1746.701406]  [<ffffffffa0051a15>] i915_gem_object_wait_priority+0x85/0x160 [i915]\n[ 1746.701599]  [<ffffffffa008ccd7>] intel_mmio_flip_work_func+0x47/0x2b0 [i915]\n[ 1746.701717]  [<ffffffff81094c4d>] process_one_work+0x14d/0x470\n[ 1746.701809]  [<ffffffff81094fb3>] worker_thread+0x43/0x4e0\n[ 1746.701888]  [<ffffffff81094f70>] ? process_one_work+0x470/0x470\n[ 1746.701969]  [<ffffffff81094f70>] ? process_one_work+0x470/0x470\n[ 1746.702072]  [<ffffffff8109a4d5>] kthread+0xc5/0xe0\n[ 1746.702152]  [<ffffffff81771c59>] ? _raw_spin_unlock_irq+0x9/0x10\n[ 1746.702234]  [<ffffffff8109a410>] ? kthread_park+0x60/0x60\n[ 1746.702318]  [<ffffffff81772272>] ret_from_fork+0x22/0x30\n[ 1746.702387] Code: 89 42 08 48 8b 45 88 48 89 55 c0 4c 89 6d c8 4c 8d 70 d8 4d 8d 7e 28 4d 39 ef 74 72 49 8b 1e 48 8b 13 48 39 d3 48 8d 42 f8 74 3e <48> 8b 10 8b 52 38 41 39 d4 7e 26 48 8b 50 30 48 8b 78 28 48 8d\n[ 1746.702921] RIP  [<ffffffffa006595d>] execlists_schedule+0x8d/0x300 [i915]\nNov 25 21:42:54 kbl-gbbki7 kernel: [ 1746.703027]  RSP <ffffc90000f6fcd8>\n\nFixes: 27745e829a5c (\"drm/i915/execlists: Use a local lock for dfs_link access\")\nFixes: 9a151987d709 (\"drm/i915: Add execution priority boosting for mmioflips\")\nSigned-off-by: Chris Wilson <chris@chris-wilson.co.uk>\nCc: David Weinehall <david.weinehall@linux.intel.com>\nCc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>\nLink: http://patchwork.freedesktop.org/patch/msgid/20161128143649.4289-1-chris@chris-wilson.co.uk\nReviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>\n(cherry picked from commit 92117f0bce64268b841261774e45462cc7ff80af)\nSigned-off-by: Jani Nikula <jani.nikula@intel.com>","distinct":false,"url":"https://api.github.com/repos/freedesktop/drm-intel/commits/7a9e10253e9e52451bbe80ddb2874368dbd240a3"}]}
{"actor":{"display_login":"fdo-mirror"}}