Issue metadata
Sign in to add a comment
|
chell: Display remains off after being turned off for inactivity until suspend/resume |
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Platform: 9765.76.1 (Official Build) stable-channel chell Steps to reproduce the problem: 1. on account that goes to lock screen after idle suspend wait for idle suspend 2. wake device What is the expected behavior? See lock screen What went wrong? see only black screen (backlight on) Did this work before? N/A Chrome version: 61.0.3163.100 Channel: stable OS Version: Flash Version: Shockwave Flash 27.0 r0 feedback here: https://listnr.corp.google.com/report/75368277244 Initial debug here: crbug.com/773421#c19 & #c20 Comment 19 by tbroch@chromium.org, Today (110 minutes ago) ⚐ Interesting, your feedback (powerd.PREVIOUS) leads me to believe there's another issue as well. Your summary mentions a black screen instead of seeing lock screen. powerd.LATEST (feedback:75368277244) [1006/100710:INFO:activity_logger.cc(20)] User activity reported [1006/100710:INFO:state_controller.cc(96)] Undimming screen [1006/100710:INFO:state_controller.cc(96)] Turning screen on [1006/100710:INFO:display_power_setter.cc(82)] Asking Chrome to turn all displays on [1006/100711:INFO:internal_backlight_controller.cc(682)] Setting brightness to 932 (80%) over 0 ms [1006/100711:INFO:keyboard_backlight_controller.cc(492)] Setting brightness to 10 (10%) over 200 ms [1006/100711:INFO:daemon.cc(1396)] Chrome is using normal display mode [1006/100730:INFO:activity_logger.cc(20)] User activity stopped; last reported 20 sec ago [1006/100738:INFO:daemon.cc(777)] On AC (USB_PD, 0.000A at 14.4V, max 3.0A at 15.0V) with battery at 100%, 3.811/3.811Ah at 0.283A, full [1006/100741:INFO:state_controller.cc(89)] Dimming screen after 30s [1006/100741:INFO:internal_backlight_controller.cc(682)] Setting brightness to 150 (34.987%) over 200 ms [1006/100741:INFO:keyboard_backlight_controller.cc(492)] Setting brightness to 0 (0%) over 2000 ms [1006/100741:INFO:keyboard_backlight_controller.cc(492)] Setting brightness to 0 (0%) over 2000 ms [1006/100743:INFO:activity_logger.cc(20)] User activity reported [1006/100743:INFO:state_controller.cc(400)] Scaling delays due to user activity while screen was dimmed or soon after it was turned off [1006/100743:INFO:state_controller.cc(777)] Updated settings: dim=1m screen_off=1m10s lock=1m20s idle_warn=0s idle=30m30s (suspend) lid_closed=suspend use_audio=1 use_video=1 [1006/100743:INFO:state_controller.cc(96)] Undimming screen [1006/100743:INFO:internal_backlight_controller.cc(682)] Setting brightness to 932 (80%) over 200 ms [1006/100743:INFO:keyboard_backlight_controller.cc(492)] Setting brightness to 10 (10%) over 200 ms [1006/100746:INFO:daemon.cc(513)] Lid closed So I'm assuming after the 1st or 2nd 'Undimming' above the screen remained black instead of displaying the lock screen? I do see these, [3695:3703:1006/100711.096728:ERROR:crtc_controller.cc(43)] Failed to modeset: crtc=26 connector=37 framebuffer_id=62 mode=3200x1800@60: Numerical result out of range [3695:3703:1006/100711.096829:ERROR:screen_manager.cc(392)] Failed to enable controller I'll plan to file a separate bug for that and leave this one to focus on shutdown issue. Comment 20, ⚐ >So I'm assuming after the 1st or 2nd 'Undimming' above the screen remained black instead of displaying the lock screen? Correct, and I agree that my issue seems to be different than the unintended shutdown one that's being discussed in this bug. When this happens to me I see a black screen (the screen's backlight is turned on) with no mouse cursor or any other UI elements. This happens after I leave my Chromebook alone for awhile while it's at the lock screen - the screen turns off (as expected due to power management), then I wake it by pressing the left Shift key but I only see a black screen instead of seeing the lock screen. This started when my Chell was upgraded to M61.
,
Oct 11 2017
Graphics folks, Seen any other reports of this on 3.18 devices in M-61? Could it be unique to QHD+ resolution? [3695:3703:1006/100711.096728:ERROR:crtc_controller.cc(43)] Failed to modeset: crtc=26 connector=37 framebuffer_id=62 mode=3200x1800@60: Numerical result out of range [3695:3703:1006/100711.096829:ERROR:screen_manager.cc(392)] Failed to enable controller
,
Oct 11 2017
The failed modeset corresponds with these drm failures: 2017-10-06 10:07:10.854 3 kernel : [ 1572.156689] [drm:skl_set_cdclk] *ERROR* failed to inform PCU about cdclk change 2017-10-06 10:07:11.076 3 kernel : [ 1572.379073] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO underrun I've not seen them, nor do I know what they mean, but that'd be a good place to start.
,
Oct 11 2017
Updating the summary, since it sounds like this is unrelated to suspend/resume (and suspend/resume in fact fixes things). Huh. Do we split Chrome's log messages between the user log and the system log while the user is logged in now? That's... unfortunate. user: [3655:3655:1006/100710.604524:VERBOSE1:display_configurator.cc(904)] SetDisplayPower: power_state=ALL_ON flags=0, configure timer=Stopped [3655:3655:1006/100710.815663:VERBOSE1:display_configurator.cc(952)] Display snapshots invalidated. [3655:3655:1006/100710.815845:VERBOSE1:update_display_configuration_task.cc(76)] OnDisplaysUpdated: new_display_state=SINGLE new_power_state=ALL_ON flags=0 force_configure=0 display_count=1 [3655:3655:1006/100710.815940:VERBOSE1:display_configurator.cc(213)] EnterState: display=SINGLE power=ALL_ON [3655:3655:1006/100711.097238:VERBOSE1:display_configurator.cc(1061)] OnConfigured: success=1 new_display_state=SINGLE new_power_state=ALL_ON system: [3695:3703:1006/100710.815078:WARNING:screen_manager.cc(114)] Display controller (crtc=26) already present. [3695:3703:1006/100710.816327:VERBOSE1:drm_display.cc(102)] DRM configuring: device=/sys/devices/pci0000:00/0000:00:02.0/drm/card0 crtc=26 connector=37 origin=0,0 size=3200x1800 [3695:3703:1006/100711.096728:ERROR:crtc_controller.cc(43)] Failed to modeset: crtc=26 connector=37 framebuffer_id=62 mode=3200x1800@60: Numerical result out of range [3695:3703:1006/100711.096829:ERROR:screen_manager.cc(392)] Failed to enable controller Here's the later suspend/resume from powerd's perspective: [1006/100746:INFO:daemon.cc(513)] Lid closed ... [1006/100746:INFO:internal_backlight_controller.cc(682)] Setting brightness to 0 (0%) over 0 ms [1006/100746:INFO:internal_backlight_controller.cc(699)] Setting resume brightness to 932 (80%) ... [1006/100747:INFO:daemon.cc(1396)] Chrome is using normal display mode ... [1006/100747:INFO:suspender.cc(473)] Starting suspend [1006/100747:INFO:main.cc(233)] Running "/usr/bin/powerd_setuid_helper --action=suspend --suspend_wakeup_count_valid --suspend_wakeup_count=347" [1006/100751:INFO:daemon.cc(698)] powerd_suspend returned 0 ... [1006/100751:INFO:internal_backlight_controller.cc(682)] Setting brightness to 932 (80%) over 0 ms ... [1006/100751:INFO:daemon.cc(522)] Lid opened ... [1006/100751:INFO:daemon.cc(1396)] Chrome is using normal display mode Chrome user: [3655:3655:1006/100746.970869:VERBOSE1:display_configurator.cc(952)] Display snapshots invalidated. [3655:3655:1006/100746.971937:VERBOSE1:update_display_configuration_task.cc(76)] OnDisplaysUpdated: new_display_state=SINGLE new_power_state=ALL_OFF flags=0 force_configure=0 display_count=1 [3655:3655:1006/100746.971991:VERBOSE1:display_configurator.cc(213)] EnterState: display=SINGLE power=ALL_OFF [3655:3655:1006/100747.255549:VERBOSE1:display_configurator.cc(1061)] OnConfigured: success=1 new_display_state=SINGLE new_power_state=ALL_OFF [3655:3655:1006/100751.330190:VERBOSE1:drm_display_host_manager.cc(247)] Got display event CHANGE for /dev/dri/card0 [3655:3655:1006/100751.331691:VERBOSE1:display_configurator.cc(904)] SetDisplayPower: power_state=ALL_ON flags=0, configure timer=Stopped Chrome system: [3695:3703:1006/100746.960122:WARNING:screen_manager.cc(114)] Display controller (crtc=26) already present. [3695:3703:1006/100746.972123:VERBOSE1:drm_display.cc(102)] DRM configuring: device=/sys/devices/pci0000:00/0000:00:02.0/drm/card0 crtc=26 connector=37 origin=0,0 size=0x0 [3695:3703:1006/100751.366030:WARNING:screen_manager.cc(114)] Display controller (crtc=26) already present. [3695:3703:1006/100751.463001:VERBOSE1:drm_display.cc(102)] DRM configuring: device=/sys/devices/pci0000:00/0000:00:02.0/drm/card0 crtc=26 connector=37 origin=0,0 size=3200x1800 [3695:3703:1006/100752.344003:WARNING:screen_manager.cc(114)] Display controller (crtc=26) already present. [3695:3703:1006/100752.344485:VERBOSE1:drm_display.cc(102)] DRM configuring: device=/sys/devices/pci0000:00/0000:00:02.0/drm/card0 crtc=26 connector=37 origin=0,0 size=3200x1800 These kernel errors from the time when the problem occurred might be relevant: 2017-10-06T10:07:10.854624-07:00 ERR kernel: [ 1572.156689] [drm:skl_set_cdclk] *ERROR* failed to inform PCU about cdclk change 2017-10-06T10:07:11.076027-07:00 ERR kernel: [ 1572.379073] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO underrun
,
Oct 12 2017
Patches here seem promising: https://patchwork.freedesktop.org/patch/125603/
,
Oct 12 2017
Dominik can you backport this?
,
Oct 18 2017
Just a quick update - I powerwashed yesterday due to the TPM firmware issue (http://dev.chromium.org/chromium-os/tpm_firmware_update) but I'm still seeing this problem. So this was not fixed by powerwashing.
,
Nov 13 2017
My Chell was updated to Chrome OS 62.0.3202.82, but this is still happening.
,
Jan 24 2018
Issue 802934 has been merged into this issue.
,
Jan 24 2018
Per issue 802934 , this is still happening on M63. It sounds like a likely fix has been available since October, but now we've possibly also missed the stable cut for M64. What's the holdup? Adding RBS on M65 so we don't miss that too, but it'd still be nice to get the fix into M64 if possible so that stable-channel users don't need to deal with this until March.
,
Jan 25 2018
For reference I switched over my Chell to the Beta channel awhile ago and have been running M64 for several weeks, and this issue is still happening in M64. I know that's expected but I figured I would just add it here as a data point.
,
Feb 1 2018
,
Feb 2 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/75022272d63361f896ef235214ed9e4923b69878 commit 75022272d63361f896ef235214ed9e4923b69878 Author: Imre Deak <imre.deak@intel.com> Date: Fri Feb 02 18:17:21 2018 BACKPORT: drm/i915/gen9: Fix PCODE polling during CDCLK change notification commit 848496e5902833600f7992f4faa82dc1546051ba Author: Ville Syrjl <ville.syrjala@linux.intel.com> Date: Wed Jul 13 16:32:03 2016 +0300 drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL increased the timeout to match the spec, but we still see a timeout on at least one SKL. A CDCLK change request following the failed one will succeed nevertheless. I could reproduce this problem easily by running kms_pipe_crc_basic in a loop. In all failure cases _wait_for() was pre-empted for >3ms and so in the worst case - when the pre-emption happened right after calculating timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only once which failed and so _wait_for() timed out. As opposed to this the spec says to keep retrying the request for at most a 3ms period. To fix this send the first request explicitly to guarantee that there is 3ms between the first and last request. Though this matches the spec, I noticed that in rare cases this can still time out if we sent only a few requests (in the worst case 2) _and_ PCODE is busy for some reason even after a previous request and a 3ms delay. To work around this retry the polling with pre-emption disabled to maximize the number of requests. Also increase the timeout to 10ms to account for interrupts that could reduce the number of requests. With this change I couldn't trigger the problem. v2: - Use 1ms poll period instead of 10us. (Chris) v3: - Poll with pre-emption disabled to increase the number of request attempts. (Ville, Chris) - Factor out a helper to poll, it's also needed by the next patch. v4: - Pass reply_mask, reply to skl_pcode_request(), instead of assuming the reply is generic. (Ville) v5: - List the request specific timeout values as code comment. (Ville) v6: - Try the poll first with preemption enabled. - Add code comment about first request being queued by PCODE. (Art) - Add timeout_base_ms argument. (Ville) v7: - Clarify code comment about first queued request. (Chris) Backport: the deleted wait function is little different. BUG= chromium:773825 TEST=set short dimming and blanking timeouts, wait for blanking and resume multiple times Cc: Ville Syrjl <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Art Runyan <arthur.j.runyan@intel.com> Cc: <stable@vger.kernel.org> # v4.2- : 3b2c171 : drm/i915: Wait up to 3ms Cc: <stable@vger.kernel.org> # v4.2- Fixes: 5d96d8afcfbb ("drm/i915/skl: Deinit/init the display at suspend/resume") Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929 Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1480955258-26311-1-git-send-email-imre.deak@intel.com (cherry picked from commit a0b8a1fe34430c3a82258e8cb45f5968bdf31afd) Signed-off-by: Dominik Behr <dbehr@chromium.org> Change-Id: Ib45e53219e5d8c14c78b57f88695f00f4fcf15ae Reviewed-on: https://chromium-review.googlesource.com/898211 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Dominik Behr <dbehr@chromium.org> Reviewed-by: Stéphane Marchesin <marcheu@chromium.org> [modify] https://crrev.com/75022272d63361f896ef235214ed9e4923b69878/drivers/gpu/drm/i915/intel_display.c [modify] https://crrev.com/75022272d63361f896ef235214ed9e4923b69878/drivers/gpu/drm/i915/i915_drv.h [modify] https://crrev.com/75022272d63361f896ef235214ed9e4923b69878/drivers/gpu/drm/i915/intel_pm.c
,
Feb 6 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/1f0b984eb62f18aff8746888d9d6615a9eb4b4ff commit 1f0b984eb62f18aff8746888d9d6615a9eb4b4ff Author: Imre Deak <imre.deak@intel.com> Date: Tue Feb 06 03:08:42 2018 UPSTREAM: drm/i915/gen9: Increase PCODE request timeout to 50ms After commit 2c7d0602c815277f7cb7c932b091288710d8aba7 Author: Imre Deak <imre.deak@intel.com> Date: Mon Dec 5 18:27:37 2016 +0200 drm/i915/gen9: Fix PCODE polling during CDCLK change notification there is still one report of the CDCLK-change request timing out on a KBL machine, see the Reference link. On that machine the maximum time the request took to succeed was 34ms, so increase the timeout to 50ms. v2: - Change timeout from 100 to 50 ms to maintain the current 50 ms limit for atomic waits in the driver. (Chris, Tvrtko) BUG= chromium:773825 TEST=set short dimming and blanking timeouts, wait for blanking and resume multiple times Reference: https://bugs.freedesktop.org/show_bug.cgi?id=99345 Cc: Ville Syrjl <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1487946730-17162-1-git-send-email-imre.deak@intel.com (cherry picked from commit 0129936ddda26afd5d9d207c4e86b2425952579f) Signed-off-by: Dominik Behr <dbehr@chromium.org> Change-Id: I746d8ddb2960311e2709f73f5232f3f1cd02ccb7 Reviewed-on: https://chromium-review.googlesource.com/898212 Commit-Ready: Dominik Behr <dbehr@chromium.org> Tested-by: Dominik Behr <dbehr@chromium.org> Reviewed-by: Stéphane Marchesin <marcheu@chromium.org> [modify] https://crrev.com/1f0b984eb62f18aff8746888d9d6615a9eb4b4ff/drivers/gpu/drm/i915/intel_pm.c
,
Feb 21 2018
Is this ready to merge back to 65? This is marked as release block stable for 65, so we need a fix in the next couple weeks.
,
Mar 7 2018
Ping again for merge query?
,
Mar 8 2018
*shrug*, I'm happy to add the label. :-P
,
Mar 8 2018
This bug requires manual review: Request affecting a post-stable build Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 8 2018
Cool lets merge it.
,
Mar 12 2018
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible! If all merges have been completed, please remove any remaining Merge-Approved labels from this issue. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 12 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/3abea0c38fc9968dd941b3dc2e40960f2b1d6c5f commit 3abea0c38fc9968dd941b3dc2e40960f2b1d6c5f Author: Imre Deak <imre.deak@intel.com> Date: Mon Mar 12 17:02:06 2018 BACKPORT: drm/i915/gen9: Fix PCODE polling during CDCLK change notification commit 848496e5902833600f7992f4faa82dc1546051ba Author: Ville Syrjl <ville.syrjala@linux.intel.com> Date: Wed Jul 13 16:32:03 2016 +0300 drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL increased the timeout to match the spec, but we still see a timeout on at least one SKL. A CDCLK change request following the failed one will succeed nevertheless. I could reproduce this problem easily by running kms_pipe_crc_basic in a loop. In all failure cases _wait_for() was pre-empted for >3ms and so in the worst case - when the pre-emption happened right after calculating timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only once which failed and so _wait_for() timed out. As opposed to this the spec says to keep retrying the request for at most a 3ms period. To fix this send the first request explicitly to guarantee that there is 3ms between the first and last request. Though this matches the spec, I noticed that in rare cases this can still time out if we sent only a few requests (in the worst case 2) _and_ PCODE is busy for some reason even after a previous request and a 3ms delay. To work around this retry the polling with pre-emption disabled to maximize the number of requests. Also increase the timeout to 10ms to account for interrupts that could reduce the number of requests. With this change I couldn't trigger the problem. v2: - Use 1ms poll period instead of 10us. (Chris) v3: - Poll with pre-emption disabled to increase the number of request attempts. (Ville, Chris) - Factor out a helper to poll, it's also needed by the next patch. v4: - Pass reply_mask, reply to skl_pcode_request(), instead of assuming the reply is generic. (Ville) v5: - List the request specific timeout values as code comment. (Ville) v6: - Try the poll first with preemption enabled. - Add code comment about first request being queued by PCODE. (Art) - Add timeout_base_ms argument. (Ville) v7: - Clarify code comment about first queued request. (Chris) Backport: the deleted wait function is little different. BUG= chromium:773825 TEST=set short dimming and blanking timeouts, wait for blanking and resume multiple times Cc: Ville Syrjl <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Art Runyan <arthur.j.runyan@intel.com> Cc: <stable@vger.kernel.org> # v4.2- : 3b2c171 : drm/i915: Wait up to 3ms Cc: <stable@vger.kernel.org> # v4.2- Fixes: 5d96d8afcfbb ("drm/i915/skl: Deinit/init the display at suspend/resume") Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929 Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1480955258-26311-1-git-send-email-imre.deak@intel.com (cherry picked from commit a0b8a1fe34430c3a82258e8cb45f5968bdf31afd) Signed-off-by: Dominik Behr <dbehr@chromium.org> Change-Id: Ib45e53219e5d8c14c78b57f88695f00f4fcf15ae Reviewed-on: https://chromium-review.googlesource.com/898211 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Tested-by: Dominik Behr <dbehr@chromium.org> Reviewed-by: Stéphane Marchesin <marcheu@chromium.org> (cherry picked from commit 75022272d63361f896ef235214ed9e4923b69878) Reviewed-on: https://chromium-review.googlesource.com/958583 Reviewed-by: Bernie Thompson <bhthompson@chromium.org> Commit-Queue: Bernie Thompson <bhthompson@chromium.org> Tested-by: Bernie Thompson <bhthompson@chromium.org> [modify] https://crrev.com/3abea0c38fc9968dd941b3dc2e40960f2b1d6c5f/drivers/gpu/drm/i915/intel_display.c [modify] https://crrev.com/3abea0c38fc9968dd941b3dc2e40960f2b1d6c5f/drivers/gpu/drm/i915/i915_drv.h [modify] https://crrev.com/3abea0c38fc9968dd941b3dc2e40960f2b1d6c5f/drivers/gpu/drm/i915/intel_pm.c
,
Mar 12 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/fd728222c3ad89cbf101dc62c2ca83f7eafac3ea commit fd728222c3ad89cbf101dc62c2ca83f7eafac3ea Author: Imre Deak <imre.deak@intel.com> Date: Mon Mar 12 17:04:02 2018 UPSTREAM: drm/i915/gen9: Increase PCODE request timeout to 50ms After commit 2c7d0602c815277f7cb7c932b091288710d8aba7 Author: Imre Deak <imre.deak@intel.com> Date: Mon Dec 5 18:27:37 2016 +0200 drm/i915/gen9: Fix PCODE polling during CDCLK change notification there is still one report of the CDCLK-change request timing out on a KBL machine, see the Reference link. On that machine the maximum time the request took to succeed was 34ms, so increase the timeout to 50ms. v2: - Change timeout from 100 to 50 ms to maintain the current 50 ms limit for atomic waits in the driver. (Chris, Tvrtko) BUG= chromium:773825 TEST=set short dimming and blanking timeouts, wait for blanking and resume multiple times Reference: https://bugs.freedesktop.org/show_bug.cgi?id=99345 Cc: Ville Syrjl <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1487946730-17162-1-git-send-email-imre.deak@intel.com (cherry picked from commit 0129936ddda26afd5d9d207c4e86b2425952579f) Signed-off-by: Dominik Behr <dbehr@chromium.org> Change-Id: I746d8ddb2960311e2709f73f5232f3f1cd02ccb7 Reviewed-on: https://chromium-review.googlesource.com/898212 Commit-Ready: Dominik Behr <dbehr@chromium.org> Tested-by: Dominik Behr <dbehr@chromium.org> Reviewed-by: Stéphane Marchesin <marcheu@chromium.org> (cherry picked from commit 1f0b984eb62f18aff8746888d9d6615a9eb4b4ff) Reviewed-on: https://chromium-review.googlesource.com/958584 Reviewed-by: Bernie Thompson <bhthompson@chromium.org> Commit-Queue: Bernie Thompson <bhthompson@chromium.org> Tested-by: Bernie Thompson <bhthompson@chromium.org> [modify] https://crrev.com/fd728222c3ad89cbf101dc62c2ca83f7eafac3ea/drivers/gpu/drm/i915/intel_pm.c
,
Mar 12 2018
Presumed fixed.
,
Mar 13 2018
,
Mar 15 2018
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible! If all merges have been completed, please remove any remaining Merge-Approved labels from this issue. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by tbroch@chromium.org
, Oct 11 2017