Bug 96321 - [CHV] HDMI detection fails, black screen after boot
Summary: [CHV] HDMI detection fails, black screen after boot
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Ville Syrjala
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-02 09:01 UTC by Radoslav Duda
Modified: 2016-09-09 09:57 UTC (History)
1 user (show)

See Also:
i915 platform: BSW/CHT
i915 features: display/HDMI


Attachments
dmesg with drm.debug=0x1e log_buf_len=1M (81.27 KB, text/plain)
2016-06-02 09:02 UTC, Radoslav Duda
no flags Details
intel_reg dump --all (97.52 KB, text/plain)
2016-06-02 09:03 UTC, Radoslav Duda
no flags Details
i915_vbt (6.00 KB, application/octet-stream)
2016-06-02 09:04 UTC, Radoslav Duda
no flags Details
i915_opregion (8.00 KB, application/octet-stream)
2016-06-02 09:04 UTC, Radoslav Duda
no flags Details
./intel_reg dump --spec=/root/intel-gpu-tools/tools/registers/cherryview (93.54 KB, text/plain)
2016-06-02 11:44 UTC, Radoslav Duda
no flags Details
[PATCH] drm/i915: Check VBT for port presence in addition to the strap on VLV/CHV (6.59 KB, patch)
2016-06-02 14:31 UTC, Ville Syrjala
no flags Details | Splinter Review
dmesg_4.7.0-rc1+ with patch: Check VBT for port presence (117.37 KB, text/plain)
2016-06-03 08:53 UTC, Radoslav Duda
no flags Details

Description Radoslav Duda 2016-06-02 09:01:55 UTC
system: Voyo v3 - x7-Z8700
OS: gentoo testing ~amd64
kernel: 4.6.0

I'm getting black screen on attached TV (Panasonic TX-48AS640E) just after switching from EFI FB to inteldrmfb. This system has just one display output - HDMI.

From dmesg it seems intel_hdmi_detect is picking incorrect pin for detection (based on wrong info from vbt?)

[    0.721621] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:40:HDMI-A-1]
[    0.721628] [drm:intel_hdmi_detect] [CONNECTOR:40:HDMI-A-1]
[    0.721635] [drm:intel_power_well_enable] enabling display
[    0.729517] i2c i2c-2: master_xfer[0] W, addr=0x50, len=1
[    0.729523] i2c i2c-2: master_xfer[1] R, addr=0x50, len=1
[    0.729693] [drm:do_gmbus_xfer] GMBUS [i915 gmbus panel] NAK for addr: 0050 w(1)
[    0.729699] [drm:do_gmbus_xfer] GMBUS [i915 gmbus panel] NAK on first message, retry
[    0.729865] [drm:do_gmbus_xfer] GMBUS [i915 gmbus panel] NAK for addr: 0050 w(1)
[    0.729872] [drm:drm_do_probe_ddc_edid] drm: skipping non-existent adapter i915 gmbus panel
[    0.735170] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:40:HDMI-A-1] status updated from unknown to disconnected
[    0.735181] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:40:HDMI-A-1] disconnected

I'm able to get correct edid on dpc:
voyo ~ # i2cdetect -l
i2c-0   i2c             i915 gmbus ssc                          I2C adapter
i2c-1   i2c             i915 gmbus vga                          I2C adapter
i2c-2   i2c             i915 gmbus panel                        I2C adapter
i2c-3   i2c             i915 gmbus dpc                          I2C adapter
i2c-4   i2c             i915 gmbus dpb                          I2C adapter
i2c-5   i2c             i915 gmbus dpd                          I2C adapter
i2c-6   i2c             DPDDC-D                                 I2C adapter

voyo ~ # get-edid 
This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 0
No EDID on bus 1
No EDID on bus 2
No EDID on bus 4
No EDID on bus 5
No EDID on bus 6
1 potential busses found: 3
256-byte EDID successfully retrieved from i2c bus 3
Comment 1 Radoslav Duda 2016-06-02 09:02:49 UTC
Created attachment 124255 [details]
dmesg with drm.debug=0x1e log_buf_len=1M
Comment 2 Radoslav Duda 2016-06-02 09:03:43 UTC
Created attachment 124256 [details]
intel_reg dump --all
Comment 3 Radoslav Duda 2016-06-02 09:04:10 UTC
Created attachment 124257 [details]
i915_vbt
Comment 4 Radoslav Duda 2016-06-02 09:04:37 UTC
Created attachment 124258 [details]
i915_opregion
Comment 5 Ville Syrjala 2016-06-02 09:47:52 UTC
Based on the dmesg it looks like the board straps are telling us that port D is the only thing present, but the VBT says port C is the only thing present. Also the EDID seems to be available on the DDC pins used for for port C.

I'd like to see what the straps say, and I'd like to see what the BIOS enables, so can you boot without loading i915.ko, with display already enabled by BIOS preferably, and run 'intel_reg dump --spec=<path to spec files>/cherryview'

The spec files for the tool are under tools/registers/ in igt source tree, and should get installed in <prefix>/share/intel-gpu-tools/registers/ if you've installed it.
Comment 6 Radoslav Duda 2016-06-02 11:44:26 UTC
Created attachment 124264 [details]
./intel_reg dump --spec=/root/intel-gpu-tools/tools/registers/cherryview

modprobe.blacklist=i915
Comment 7 Ville Syrjala 2016-06-02 14:31:33 UTC
Created attachment 124269 [details] [review]
[PATCH] drm/i915: Check VBT for port presence in addition to the strap on VLV/CHV

The dump showed HDMI C being active, so I guess we just have to trust the VBT on this one. This patch should achieve the desired result.

I've pushed this to a branch at
git://github.com/vsyrjala/linux.git chv_dig_port_vbt
as well. You can use that, or grab drm-intel-nightly from the official place and apply the patch manually. It probably won't apply cleanly to anything else since we've had recent changes in the relevant code.

Please test.
Comment 8 Radoslav Duda 2016-06-03 08:50:49 UTC
HDMI output works fine with the patch applied to drm-intel-nightly, thanks!

I'm attaching dmesg for reference.
Comment 9 Radoslav Duda 2016-06-03 08:53:09 UTC
Created attachment 124301 [details]
dmesg_4.7.0-rc1+ with patch: Check VBT for port presence
Comment 10 Ville Syrjala 2016-09-06 14:32:26 UTC
Fixed by

commit a5aac5ab876ad95b7f5e8d862afb07248ee9cae2
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Jun 3 12:17:43 2016 +0300

    drm/i915: Check VBT for port presence in addition to the strap on VLV/CHV


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.