I've reproduced the hang with drm.debug=0x3f. Looks like it is related to dp/hdmi detect. Every 10sec, intel_dp_detect/intel_hdmi_detect runs and enables/disables some power wells. Last message before the hang was:
[13115.913832] [drm:intel_power_well_enable] enabling dpio-common

Since drm.debug is quite verbose with all the drm_ioctl logs, and each dp/hdmi detect event takes ~400ms, with ~10sec gap in between, the correlation between the hang and the detect event should be significant.

Attached drmdebug_tail.txt is the last few seconds of dmesg before the hang. detect.txt is all the detect related messages (removing ioctls) in the last few hours.

Could Intel team help take a look at the log and see if any of the power well enabling/disabling could cause a hang?

Deleted: drmdebug_tail.txt 557 KB

drmdebug_tail.txt 557 KB View Download

Deleted: detect.txt 2.3 MB

detect.txt 2.3 MB View Download

Shyam, can we please loop in the appropriate folks from Intel?

Sameer, I am working with GFX/Display folks internally to debug. Right folks are in the loop. As you know this is very challenging without XDP support on the board. We are trying to go over the kernel logs to see where the problem is.

what is the easiest way to enable kernel logs on the CPFE images? So we can see those in servo coreboot console.

Assuming that the serial port support is built in, Try using /usr/share/vboot/bin/make_dev_ssd.h scrip to:

1) Disable rootfs verification (--disable_rootfs_verification --partition 2) and reboot.
2) (--save_config /tmp/config --partition 2) to save the current kernel command line. 
3) Change the command line in /tmp/config.2 to add console=... and earlyprintk=... parameters.
4) (--set_config /tmp/config --partition 2) to update the kernel command line.

we tried to enable dev mode using ctrl+f3+power button. not able to enter dev mode. can you please share the coreboot for Ninja?

I think you need to reset/power on the device while holding the recovery button in order to see the recovery screen, then you can press Ctrl-D using USB keyboard to enter Dev mode. Avinash, is that right? The recovery button is located in a hole on the left side near the rear end of the device.

yes, I'm following this doc to get to recovery. https://aopen.zendesk.com/hc/en-us/article_attachments/203195109/Wiping_the_AOPEN_Chromebox_Commercial_Device.pdf

Manually running detect on all connectors in a loop can greatly speed up the hang repro. I've repro-ed the hang within 10mins 3 times with:

while true; do
    echo detect > /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-1/status
    echo detect > /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-1/status
    echo detect > /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-2/status
    echo detect > /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-HDMI-A-2/status
done

is the 4.4 kernel same as KBL(Poppy/Soraka) and APL (Electro/Reef)? can I use APL or KBL kernel?

Yes, there is only one chromeos-4.4 kernel:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4

And BYT/KBL/APL are all using the same chromeos-intel-pineview config:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/chromeos/config/x86_64/chromeos-intel-pineview.flavour.config

Looks like enabling PUNIT_POWER_WELL_DPIO_CMN_BC(dpio-common) during dp detect causes the hang.


My experiment so far:
* Stop drm from scheduling output_poll_execute so we can run and test connector detect manually via sysfs.
* Play video, then disconnect all external monitor.
* while true; do
    echo detect > /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-XXXXXXX/status
  done

1) HDMI detect alone, either HDMI-A-1 or HDMI-A-2. No hang in 50mins+
2) DP detect alone, either DP-1 or DP-2. Hangs after 14mins, 1min, 15mins.
3) DP detect alone. Also in intel_dp_long_pulse, skip all the code except intel_display_power_get/intel_display_power_put. So each dp detect is just enabling/disabling power wells. Hangs after 3mins.

All the hangs stops at
[  426.349518] [2904:bash]intel_dp_detect enter 
[  426.349526] [drm:intel_dp_detect] [CONNECTOR:46:DP-1]
[  426.349532] [2904:bash]    intel_dp_long_pulse power_domain=24
[  426.349541] [drm:intel_power_well_enable] enabling always-on
[  426.349546] [drm:intel_power_well_enable] enabling display
[  426.349552] [2904:bash]    vlv_set_power_well enter 
[  426.356953] [2904:bash]    vlv_set_power_well exit 
[  426.356993] [drm:i915_redisable_vga_power_on] Something enabled VGA plane, disabling it
[  426.357306] [drm:intel_power_well_enable] enabling dpio-tx-b-01
[  426.357312] [2904:bash]    vlv_set_power_well enter 
[  426.365146] [2904:bash]    vlv_set_power_well exit 
[  426.365161] [drm:intel_power_well_enable] enabling dpio-tx-b-23
[  426.365167] [2904:bash]    vlv_set_power_well enter 
[  426.372876] [2904:bash]    vlv_set_power_well exit 
[  426.372887] [drm:intel_power_well_enable] enabling dpio-tx-c-01
[  426.372893] [2904:bash]    vlv_set_power_well enter 
[  426.381502] [2904:bash]    vlv_set_power_well exit 
[  426.381526] [drm:intel_power_well_enable] enabling dpio-tx-c-23
[  426.381534] [2904:bash]    vlv_set_power_well enter 
[  426.388048] [2904:bash]    vlv_set_power_well exit 
[  426.388062] [drm:intel_power_well_enable] enabling dpio-common
[  426.390166] [2904:bash]    vlv_set_power_well enter 


The power domain intel_dp_long_pulse wants is POWER_DOMAIN_AUX_B/C which requires PUNIT_POWER_WELL_DPIO_CMN_BC. I'm going to try to avoid disabling DPIO_CMN_BC and see if it hangs. I didn't find any doc about the VLV PUNIT besides https://www.kernel.org/doc/html/v4.11/gpu/i915.html#dpio

I have been trying the steps to reproduce the issue over the last 2hr+
So far no success. My observation is that HDMI-A-1 is getting reset when the display is turned ON. 

I will disconnect the HDMI cable from chromebox and run the test overnight to observe failure.

No hang in 65hrs+ over the weekend when PUNIT_POWER_WELL_DPIO_CMN_BC was never disabled. This could be a viable workaround on Ninja for now. I'm working on a patch.

Hey benzh@

Customer is requesting updates for this fix, so do you have any idea of time frame I can share with them?

Also, they had multiple issues with these devices (some of which were patched by fixes in the current build available to Ninja) but they are wondering if they can get a breakdown % of how many device failures were affected by which issue based on the logs they supplied. I'm happy to take a look at those logs to try and work that out, but could you advise if there is a specific identifier in those logs that would show the problem was caused by this?

Thanks,

Matt

re#16, https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/671554 is a promising workaround. We can land it after review and more thorough tests.

The hang in this bug and the hang in issue 719040 do not have any specific identifier in the logs. There are also issue 734708 for broken HPD (fixed), and  issue 757359  (fixed) which may have some identifiers. Let me go through the logs in  issue 757359  and check.

> Try using /usr/share/vboot/bin/make_dev_ssd.h script to:

Note you don't need to reboot to enable drm.debug, this is enough:

  echo 0x3f > /sys/module/drm/parameters/debug
  restart ui

If you want the debug level to persist across a reboot then a single command is enough:

  VISUAL=qemacs /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --edit_config --partitions 2

Hi Avinash,

https://drive.google.com/open?id=0B97XD7QTZDN5eEhQQzhkWHFJRG8 is an image with the workaround in #18. I haven't seen any hang so far. Could you help test it on more Ninja devices?

thanks

Running the test using above image.. Will update the status tomorrow. 

Devices is still running without any issue.

Hi all,

Can I get an update on this? Is there a build I can share with the customer to allow them early access to test?

Thanks

Ben, can we get a tryjob build out for this while we wait for the changes to be reviewed and submitted?

Here is the ninja-release tryjob with the patch, ETA in 4hours:
https://uberchromegw.corp.google.com/i/chromiumos.tryserver/builders/release/builds/15437

Looks like that build failed?

yeah the tryjob failure was due to issue 769369, unrelated to this bug. I haven't been able to figure out what's causing issue 769369

Here is the successful ninja-release tryjob build with the patch:
https://uberchromegw.corp.google.com/i/chromiumos.tryserver/builders/release/builds/15716

@benzh sorry - I don't know how to download the build from that page. 

Also, if this passes testing what release will it be in publicly?

On the tryjob page under "56.Report" -> Artifacts[ninja-release/R63-9996.0.0-b15716] -> recovery_image.tar.xz

After the CL lands on TOT (M63), I think it can be cherry-picked to M62 since this is a ninja only change.

Thanks @benzh. @sduraisamy as you know this is for a major APAC customer so would appreciate some clarity around when we can get this fix in.

After talking to benzh@, we are waiting for intel to review and approve.

we are reviewing the patch. Give us a day to complete it.

Thanks guys. FYI, I've had the build running for over two days now with no issues.

Ran fast-feedback.testlist from IGT with and without the fix. No regression. 201/207 passed. Attached is the test result.

Deleted: ninja_igt_results.zip 623 KB

ninja_igt_results.zip 623 KB Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5b1463937329e39ed67ddae3a72eba584f5ff08f

commit 5b1463937329e39ed67ddae3a72eba584f5ff08f
Author: Ben Zhang <benzh@chromium.org>
Date: Tue Oct 10 21:52:25 2017

CHROMIUM: drm/i915: Keep PUNIT_POWER_WELL_DPIO_CMN_BC enabled on Ninja

Repeated toggling PUNIT_POWER_WELL_DPIO_CMN_BC during HPD polls
for DP connectors eventually leads to system hang. This patch
grabs a reference to the power well during power domain init
so that the power well is always enabled. The ref is released
at late suspend just before init power is off to perserve the
existing suspend/resume sequence.

BUG= chromium:764813 
TEST=No hang after repeated DP detect via sysfs when no external
monitor is connected. Suspend/resume with and without external
monitor.

Change-Id: Ide68ab8c1932a20e9ec13c087e44ae3b69cd73e5
Signed-off-by: Ben Zhang <benzh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/671554
Reviewed-by: Manasi D Navare <manasi.d.navare@intel.com>
Reviewed-by: Rajat Jain <rajatja@chromium.org>

[modify] https://crrev.com/5b1463937329e39ed67ddae3a72eba584f5ff08f/drivers/gpu/drm/i915/i915_drv.c
[modify] https://crrev.com/5b1463937329e39ed67ddae3a72eba584f5ff08f/drivers/gpu/drm/i915/intel_drv.h
[modify] https://crrev.com/5b1463937329e39ed67ddae3a72eba584f5ff08f/drivers/gpu/drm/i915/intel_runtime_pm.c

Request to merge the patch in #37 to M62. The patch affects only Ninja.

This bug requires manual review: We are only 6 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hey all,

Any idea of an ETA for a signed build available that I can give to the customer for testing?

Approved for 62. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/cedb28682000cd98bf9bf0de155ef06c7a9d6e4a

commit cedb28682000cd98bf9bf0de155ef06c7a9d6e4a
Author: Ben Zhang <benzh@chromium.org>
Date: Wed Oct 11 19:16:05 2017

CHROMIUM: drm/i915: Keep PUNIT_POWER_WELL_DPIO_CMN_BC enabled on Ninja

Repeated toggling PUNIT_POWER_WELL_DPIO_CMN_BC during HPD polls
for DP connectors eventually leads to system hang. This patch
grabs a reference to the power well during power domain init
so that the power well is always enabled. The ref is released
at late suspend just before init power is off to perserve the
existing suspend/resume sequence.

BUG= chromium:764813 
TEST=No hang after repeated DP detect via sysfs when no external
monitor is connected. Suspend/resume with and without external
monitor.

Change-Id: Ide68ab8c1932a20e9ec13c087e44ae3b69cd73e5
Signed-off-by: Ben Zhang <benzh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/671554
Reviewed-by: Manasi D Navare <manasi.d.navare@intel.com>
Reviewed-by: Rajat Jain <rajatja@chromium.org>
(cherry picked from commit 5b1463937329e39ed67ddae3a72eba584f5ff08f)
Reviewed-on: https://chromium-review.googlesource.com/713936

[modify] https://crrev.com/cedb28682000cd98bf9bf0de155ef06c7a9d6e4a/drivers/gpu/drm/i915/i915_drv.c
[modify] https://crrev.com/cedb28682000cd98bf9bf0de155ef06c7a9d6e4a/drivers/gpu/drm/i915/intel_drv.h
[modify] https://crrev.com/cedb28682000cd98bf9bf0de155ef06c7a9d6e4a/drivers/gpu/drm/i915/intel_runtime_pm.c

re#40, 9901.45.0 and later contains the fix: https://storage.cloud.google.com/chromeos-releases/beta-channel/ninja/9901.45.0/chromeos_9901.45.0_ninja_recovery_beta-channel_mp-v2.bin

Benz - customer reported a bunch of issues after installing the test build:

- booted Ninja into recovery mode to start re-image process 
- display connected to HDMI 
- device re-imaged with 62.0.3202.53 
- black screen after rebooting when removing the USB stick 
- restart, still black screen 
- used HDMI > DisplayPort adapter to test different display output (all displays customer uses are HDMI)
- can see video, enrolled the device 
- tested switching display input back to HDMI (hot swapped) 
- system still had video output 

Then: 

- powered device off and back on
- booted to black screen, no video output
- further reboots showed that screen sometimes displays content after a period of time
- switched back to DisplayPort and tried: same issue.

I replicated the exact steps they took and couldn't get the device to show a black screen consistently, although I did find some weird glitches when only a single display is connected:
- unplugging DisplayPort and hot plugging it back again results in a black screen
- unplugging either DisplayPort or HDMI and hot plugging the other connection causes the customers kiosk app to crash and reload

Log available here: https://drive.google.com/drive/folders/0B_5yutJvxlGoLThNT3lhYTU5RUE?usp=sharing

When running their content in Chrome Sign Builder I can't replicate any of the issues noted above, so I've asked them to reimage the device and do further testing. 

I did find one thing that seems broken:

- when connected to DisplayPort there is no output when in recovery mode. Can only see output in recovery when connected to HDMI.

I wouldn't think this is expected?

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

Benz@ - customer has investigated further and agreed that their initial testing (as per #44) might have been related to a bad update as they aren't having the same issue on a different device.

They are seeing the same black screen in recovery mode problem as I did however, but they are saying it happens when connected to HDMI.

To reiterate, when a device is in recovery mode there is no video output. I saw this on a test device connected to DisplayPort, customer has seen it when connected to HDMI. Easy to replicate - device in dev mode shows no output and you can hear the warning beep.

I haven't been able to reproduce the black screen issue during recovery. Tested both HDMI and DP with several runs of recovery.
* recovery image used: beta channel 9901.45.0
* HWID: NINJA B25-A2D-A8L
* fw on device: Google_Ninja.5216.383.7

The recovery screen drawn by fw and the recovery screens drawn by the recovery kernel+rootfs are displayed correctly (attached).

@msnoxell, could you provide the HWID and fw id by pressing tab at the recovery screen or dev mode warn screen using HDMI (the working case)?

Deleted: 1.jpg 1.7 MB

	1.jpg 1.7 MB View Download

Deleted: 2.jpg 2.1 MB

	2.jpg 2.1 MB View Download

Deleted: 3.jpg 2.7 MB

	3.jpg 2.7 MB View Download

Deleted: 4.jpg 3.2 MB

	4.jpg 3.2 MB View Download

I have two Ninjas on my desk that I can replicate this with - same behaviour with both: no video in recovery mode when connected to DisplayPort. I've tested this with two different displays and also two sets of cables.

One Ninja is running 9901.45.0 and the other I updated to 9901.46.0 (now live on the beta channel).

Ninja on 9901.45.0
HWID:C25-A3D-A41
Firmware: Google_Ninja.5216.383.7

Ninja on 9901.46.0
HWID: C2B-A3D-A6X
Firmware: Google_Ninja.5216.383.7

Chat with msnoxell@ offline. The issue is that DP shows black screen all the time after pressing recovery+power button. There is no "Chrome OS is missing or damaged...." screen from the read-only recovery fw which cannot be updated. Also code initializing video in the firmware on baytrail is a vbios BLOB that only Intel can fix. +reinauer fyi

DVT works, but PVT doesn't. From CPFE HWID lookup (https://www.google.com/chromeos/partner/fe/#hwid) , they have different read-only firmware:

* DVT NINJA B25-A2D-A8L ro_main_firmware_mp
* PVT NINJA C2B-A3D-A6X ro_main_firmware_mp_2
* Couldn't find NINJA C25-A3D-A41

I can only find schematics for DVT, but not PVT. So not sure if there is any hardware change.

msnoxell@, could you help post the content of bios_info section from chrome://system on your DVT device? Just to confirm the ro firmware version.

avkodipelli@, if you have PVT devices, could you help test the recovery flow with DisplayPort?  

Thanks.

Text files with bios_info from both my test devices attached.

Deleted: bios_info C2B-A3D-A6X.txt 6.2 KB

bios_info C2B-A3D-A6X.txt 6.2 KB View Download

Deleted: bios_info C25-A3D-A4I.txt 6.2 KB

bios_info C25-A3D-A4I.txt 6.2 KB View Download

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

Any news on this? Customer is asking for updates.

I don't think anything can be done for the black screen on DP during recovery, as it's in the read-only firmware. The issue is probably there since the beginning. Only other (unlikely) possibility I can think of is that the GFX is left in a bad state that somehow persists across the reboot to recovery.  To rule this out: disconnect AC first then boot directly to recovery by holding recovery button while connecting AC.

If a recovery fails, the recovery logs saved on the usb drive can show what went wrong, e.g.:
benzh@benzh0:/media/benzh/e28b3c61-4ffe-497d-9e2c-a275f136fa8c$ ls -l
total 96
drwx------ 2 root root 16384 Oct 12 02:54 lost+found
lrwxrwxrwx 1 root root    24 Oct 25 13:20 recovery_logs -> recovery_logs.1508952015
drwxr-xr-x 2 root root  4096 Oct 25 13:20 recovery_logs.1508952015
drwxr-xr-x 2 root root  4096 Oct 25 15:42 recovery_logs.1508960537
drwxr-xr-x 3 root root  4096 Oct 12 02:54 unencrypted
-rw-r--r-- 1 root root 65536 Oct 12 03:07 vmlinuz_hd.vblock

Workaround for the original hang issue is already in the R62 live beta build. Another way to verify the workaround is switching to the beta channel to do an AU.

Issue 783919 has been merged into this issue.

There is still a bug, don't just mark it fixed...

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/board-overlays/+/81c8a7da0aa82d2fa00d8c192a71505a0a66a107

commit 81c8a7da0aa82d2fa00d8c192a71505a0a66a107
Author: Ben Zhang <benzh@chromium.org>
Date: Fri Dec 01 20:28:37 2017

Ninja: Set i915.disable_power_well=0 to workaround HDMI detect issue

Keeping PUNIT_POWER_WELL_DPIO_CMN_BC enabled alone causes HDMI detect
issue on certain devices, so use i915.disable_power_well=0 to keep all
vlv power well enabled.

BUG=chromium:780122,  chromium:764813 
TEST=HDMI/DP single/dual display tested in verified mode on the affected device.
     Suspend/resume with and without display.
     No hang after repeated HDMI/DP detect via sysfs without monitor.

Change-Id: Ifbd416ad839c50b58dd57399998281c5809485d6
Signed-off-by: Ben Zhang <benzh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/791070
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>

[add] https://crrev.com/81c8a7da0aa82d2fa00d8c192a71505a0a66a107/overlay-ninja/scripts/build_kernel_image.sh

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ae291a97d0513fde92475c235a6d03d3ef6a012b

commit ae291a97d0513fde92475c235a6d03d3ef6a012b
Author: Ben Zhang <benzh@chromium.org>
Date: Sat Dec 02 04:32:45 2017

Revert "CHROMIUM: drm/i915: Keep PUNIT_POWER_WELL_DPIO_CMN_BC enabled on Ninja"

This reverts commit 5b1463937329e39ed67ddae3a72eba584f5ff08f.

Keeping PUNIT_POWER_WELL_DPIO_CMN_BC enabled alone causes HDMI detect
issue on certain devices, so use i915.disable_power_well=0 to keep all
vlv power well enabled.

BUG=chromium:780122,  chromium:764813 
TEST=HDMI/DP single/dual display tested in verified mode on the affected device.
     Suspend/resume with and without display.
     No hang after repeated HDMI/DP detect via sysfs without monitor.
CQ-DEPEND=CL:791070

Change-Id: I034238ab189cb122e6d05004b0eaefce8b8bde5b
Signed-off-by: Ben Zhang <benzh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/791033
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>

[modify] https://crrev.com/ae291a97d0513fde92475c235a6d03d3ef6a012b/drivers/gpu/drm/i915/i915_drv.c
[modify] https://crrev.com/ae291a97d0513fde92475c235a6d03d3ef6a012b/drivers/gpu/drm/i915/intel_drv.h
[modify] https://crrev.com/ae291a97d0513fde92475c235a6d03d3ef6a012b/drivers/gpu/drm/i915/intel_runtime_pm.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/board-overlays/+/05a5c4675a32e4479a67ab62b76522b76eee8365

commit 05a5c4675a32e4479a67ab62b76522b76eee8365
Author: Ben Zhang <benzh@chromium.org>
Date: Mon Dec 04 22:00:04 2017

Ninja: Set i915.disable_power_well=0 to workaround HDMI detect issue

Keeping PUNIT_POWER_WELL_DPIO_CMN_BC enabled alone causes HDMI detect
issue on certain devices, so use i915.disable_power_well=0 to keep all
vlv power well enabled.

BUG=chromium:780122,  chromium:764813 
TEST=HDMI/DP single/dual display tested in verified mode on the affected device.
     Suspend/resume with and without display.
     No hang after repeated HDMI/DP detect via sysfs without monitor.

Change-Id: Ifbd416ad839c50b58dd57399998281c5809485d6
Signed-off-by: Ben Zhang <benzh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/791070
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
(cherry picked from commit 81c8a7da0aa82d2fa00d8c192a71505a0a66a107)
Reviewed-on: https://chromium-review.googlesource.com/806975

[add] https://crrev.com/05a5c4675a32e4479a67ab62b76522b76eee8365/overlay-ninja/scripts/build_kernel_image.sh

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/7399bee2ff8d8ba29aa1ba729dab66371c61bb1d

commit 7399bee2ff8d8ba29aa1ba729dab66371c61bb1d
Author: Ben Zhang <benzh@chromium.org>
Date: Mon Dec 04 22:00:37 2017

Revert "CHROMIUM: drm/i915: Keep PUNIT_POWER_WELL_DPIO_CMN_BC enabled on Ninja"

This reverts commit 5b1463937329e39ed67ddae3a72eba584f5ff08f.

Keeping PUNIT_POWER_WELL_DPIO_CMN_BC enabled alone causes HDMI detect
issue on certain devices, so use i915.disable_power_well=0 to keep all
vlv power well enabled.

BUG=chromium:780122,  chromium:764813 
TEST=HDMI/DP single/dual display tested in verified mode on the affected device.
     Suspend/resume with and without display.
     No hang after repeated HDMI/DP detect via sysfs without monitor.
CQ-DEPEND=CL:791070

Change-Id: I034238ab189cb122e6d05004b0eaefce8b8bde5b
Signed-off-by: Ben Zhang <benzh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/791033
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
(cherry picked from commit ae291a97d0513fde92475c235a6d03d3ef6a012b)
Reviewed-on: https://chromium-review.googlesource.com/806995

[modify] https://crrev.com/7399bee2ff8d8ba29aa1ba729dab66371c61bb1d/drivers/gpu/drm/i915/i915_drv.c
[modify] https://crrev.com/7399bee2ff8d8ba29aa1ba729dab66371c61bb1d/drivers/gpu/drm/i915/intel_drv.h
[modify] https://crrev.com/7399bee2ff8d8ba29aa1ba729dab66371c61bb1d/drivers/gpu/drm/i915/intel_runtime_pm.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/board-overlays/+/5da4e58899d95d546a41197e994b46c8a5c3c6b1

commit 5da4e58899d95d546a41197e994b46c8a5c3c6b1
Author: Ben Zhang <benzh@chromium.org>
Date: Mon Dec 04 22:19:20 2017

Ninja: Set i915.disable_power_well=0 to workaround HDMI detect issue

Keeping PUNIT_POWER_WELL_DPIO_CMN_BC enabled alone causes HDMI detect
issue on certain devices, so use i915.disable_power_well=0 to keep all
vlv power well enabled.

BUG=chromium:780122,  chromium:764813 
TEST=HDMI/DP single/dual display tested in verified mode on the affected device.
     Suspend/resume with and without display.
     No hang after repeated HDMI/DP detect via sysfs without monitor.

Change-Id: Ifbd416ad839c50b58dd57399998281c5809485d6
Signed-off-by: Ben Zhang <benzh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/791070
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
(cherry picked from commit 81c8a7da0aa82d2fa00d8c192a71505a0a66a107)
Reviewed-on: https://chromium-review.googlesource.com/806263

[add] https://crrev.com/5da4e58899d95d546a41197e994b46c8a5c3c6b1/overlay-ninja/scripts/build_kernel_image.sh

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/34949471b5c04fa2f63b4958a1f7bf24969531a1

commit 34949471b5c04fa2f63b4958a1f7bf24969531a1
Author: Ben Zhang <benzh@chromium.org>
Date: Mon Dec 04 22:19:52 2017

Revert "CHROMIUM: drm/i915: Keep PUNIT_POWER_WELL_DPIO_CMN_BC enabled on Ninja"

This reverts commit 5b1463937329e39ed67ddae3a72eba584f5ff08f.

Keeping PUNIT_POWER_WELL_DPIO_CMN_BC enabled alone causes HDMI detect
issue on certain devices, so use i915.disable_power_well=0 to keep all
vlv power well enabled.

BUG=chromium:780122,  chromium:764813 
TEST=HDMI/DP single/dual display tested in verified mode on the affected device.
     Suspend/resume with and without display.
     No hang after repeated HDMI/DP detect via sysfs without monitor.
CQ-DEPEND=CL:791070

Change-Id: I034238ab189cb122e6d05004b0eaefce8b8bde5b
Signed-off-by: Ben Zhang <benzh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/791033
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@chromium.org>
(cherry picked from commit ae291a97d0513fde92475c235a6d03d3ef6a012b)
Reviewed-on: https://chromium-review.googlesource.com/807224

[modify] https://crrev.com/34949471b5c04fa2f63b4958a1f7bf24969531a1/drivers/gpu/drm/i915/i915_drv.c
[modify] https://crrev.com/34949471b5c04fa2f63b4958a1f7bf24969531a1/drivers/gpu/drm/i915/intel_drv.h
[modify] https://crrev.com/34949471b5c04fa2f63b4958a1f7bf24969531a1/drivers/gpu/drm/i915/intel_runtime_pm.c

The new workaround for this issue is "i915.disable_power_well=0". It won't cause HDMI detect issue at boot (issue 780122), so marking as fixed.