Bug 103779

Summary: Force enabling HDMI output doesn't work since commit 972e7d71c82e ( v4.2-rc8 - v4.3-rc1 )
Product: DRI Reporter: Tomasz Kazimierczak <tkazimierczak>
Component: DRM/IntelAssignee: Ville Syrjala <ville.syrjala>
Status: CLOSED WONTFIX QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: medium CC: intel-gfx-bugs, pocek
Version: DRI gitKeywords: bisected, regression
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: BYT i915 features: display/HDMI
Attachments:
Description Flags
kernel patch
none
kernel dmesg without patch
none
kernel dmesg with patch
none
kernel dmesg with patch - update
none
kernel dmesg without patch - update
none
copy of i915_opregion file - without patch (clean)
none
copy of i915_opregion file - with patch
none
kernel dmesg with patch - second update
none
kernel dmesg without patch (clean) - second update
none
copy of i915_opregion file - with patch
none
copy of i915_opregion file - without patch (clean)
none
kernel dmesg without patch (clean) and with BIOS LVDS option enabled none

Description Tomasz Kazimierczak 2017-11-16 14:26:14 UTC
Created attachment 135517 [details] [review]
kernel patch

Since commit 972e7d71c82ea70100b808695d5cf735c1df5ef8 the kernel option 'video=HDMI-A-1:1920x1080e' stop working.

Commit description head is: "drm/i915: Ignore "digital output" and "not HDMI output" bits for eDP detection".

After applying simple patch to the yesterday (16.11.2017) latest kernel (commit 06718a287f282ad31264560c5dc18a38474cb562), the problem is fixed (i.e. functionality is restored):

@@ -240,6 +240,7 @@ struct bdb_general_features {
  */
 #define DEVICE_TYPE_eDP_BITS \
        (DEVICE_TYPE_INTERNAL_CONNECTOR |       \
+        DEVICE_TYPE_NOT_HDMI_OUTPUT |          \
         DEVICE_TYPE_MIPI_OUTPUT |              \
         DEVICE_TYPE_COMPOSITE_OUTPUT |         \
         DEVICE_TYPE_DUAL_CHANNEL |             \


Patch and full dmesg of kernel with and without patch attached.
Comment 1 Tomasz Kazimierczak 2017-11-16 14:27:39 UTC
Created attachment 135518 [details]
kernel dmesg without patch
Comment 2 Tomasz Kazimierczak 2017-11-16 14:28:12 UTC
Created attachment 135519 [details]
kernel dmesg with patch
Comment 3 Ville Syrjala 2017-11-24 14:15:28 UTC
(In reply to Tomasz Kazimierczak from comment #1)
> Created attachment 135518 [details]
> kernel dmesg without patch

This log has none of the useful bits. Please use just drm.debug=0xe and possibly increase log_bug_len= as well.

Also pls attach a copy of /sys/kernel/debug/dri/0/i915_opregion
Comment 4 Tomasz Kazimierczak 2017-11-28 16:55:37 UTC
Created attachment 135776 [details]
kernel dmesg with patch - update

update of dmesg for patched kernel
Comment 5 Tomasz Kazimierczak 2017-11-28 16:57:23 UTC
Created attachment 135777 [details]
kernel dmesg without patch - update

update of clean kernel dmesg (i.e. without patch)
Comment 6 Tomasz Kazimierczak 2017-11-28 16:59:17 UTC
Created attachment 135778 [details]
copy of i915_opregion file - without patch (clean)

copy of /sys/kernel/debug/dri/0/i915_opregion file for kernel without patch (clean)
Comment 7 Tomasz Kazimierczak 2017-11-28 17:04:52 UTC
Created attachment 135779 [details]
copy of i915_opregion file - with patch

copy of  /sys/kernel/debug/dri/0/i915_opregion file - with patch
Comment 8 Tomasz Kazimierczak 2017-11-28 17:10:24 UTC
Sorry for previous bad attachments.
Comment 9 Ville Syrjala 2017-11-28 17:34:54 UTC
(In reply to Tomasz Kazimierczak from comment #5)
> Created attachment 135777 [details]
> kernel dmesg without patch - update
> 
> update of clean kernel dmesg (i.e. without patch)

Both patched and unpatched kernels register two HDMI connectors.

The only HDMI related difference I see between the two logs is that you're not specifying any video= or firmware_edid= options on the kernel cmdline with the unpatched kernel. So based on these logs the problem seems to be a PEBKAC.

What is somewhat interesting is the fact that the BIOS apparently enables DP on port C, even though we can't detect anything connected there. I wonder if the BIOS really detected something there, or if it's just hardcoded to enable it for some reason. The VBT seems to say that it should actually be eDP, but the BIOS didn't leave VDD enabled so it seems to think that it's DP. So that part seems to be related to your patch, but I can't really see how it relates to the HDMI cmdline issue.
Comment 10 Tomasz Kazimierczak 2017-11-29 11:52:58 UTC
Created attachment 135792 [details]
kernel dmesg with patch - second update

Second update of dmesg with proper kernel options
Comment 11 Tomasz Kazimierczak 2017-11-29 11:55:35 UTC
Created attachment 135793 [details]
kernel dmesg without patch (clean) - second update

Second update of dmesg with proper kernel options - clean version (i.e. without patch)
Comment 12 Tomasz Kazimierczak 2017-11-29 11:57:12 UTC
Created attachment 135794 [details]
copy of i915_opregion file - with patch

update
Comment 13 Tomasz Kazimierczak 2017-11-29 11:58:09 UTC
Created attachment 135795 [details]
copy of i915_opregion file - without patch (clean)

update
Comment 14 Tomasz Kazimierczak 2017-11-29 12:05:19 UTC
Sorry, my bad again :/ This time I ensured that proper (and exactly the same for both cases) kernel options are set. Hope this time it won't be judged as PEBKAC :)
Comment 15 Ville Syrjala 2017-12-01 15:29:55 UTC
Based on [1] there should be a "LVDS Enable/Disable" knob in the BIOS. Please turn that off (assuming it's not already) and report back whether that has helped.

PS. no need to attach the opregion more than once as it never changes

[1] ftp://data.aaeon.com.tw/DOWNLOAD/MANUAL/GENE-BT05%20Rev%20A%20manual%205th%20Ed.pdf
Comment 16 Tomasz Kazimierczak 2017-12-05 12:08:27 UTC
I was already disabled.
Comment 17 Tomasz Kazimierczak 2017-12-05 12:09:40 UTC
*It was already disabled
Comment 18 Tomasz Kazimierczak 2017-12-05 12:16:36 UTC
*It was already disabled(In reply to Tomasz Kazimierczak from comment #16)
> I was already disabled.

Sorry for typo.
Comment 19 Ville Syrjala 2017-12-08 15:24:54 UTC
(In reply to Tomasz Kazimierczak from comment #16)
> I was already disabled.

So broken BIOS :(

Does anything change if you set it to "enabled"?

Is there a BIOS update available?
Comment 20 Tomasz Kazimierczak 2017-12-11 17:03:42 UTC
Created attachment 136088 [details]
kernel dmesg without patch (clean) and with BIOS LVDS option enabled
Comment 21 Tomasz Kazimierczak 2017-12-11 17:08:19 UTC
(In reply to Ville Syrjala from comment #19)
> (In reply to Tomasz Kazimierczak from comment #16)
> > I was already disabled.
> 
> So broken BIOS :(
> 
> Does anything change if you set it to "enabled"?
> 
> Is there a BIOS update available?

Yes, actually enabling LVDS sort of fix the problem.
Clean kernel loaded with same options work just fine.
And that way the patch is unnecessary.

But, shouldn't it work also with disabled LVDS?

Flashing BIOS for newest version, doesn't change anything...

I also attached dmesg (with forced HDMI option
and enabled LVDS in newest BIOS) in case you would
like to look at it.
Comment 22 Ville Syrjala 2018-01-22 18:08:48 UTC
(In reply to Tomasz Kazimierczak from comment #21)
> (In reply to Ville Syrjala from comment #19)
> > (In reply to Tomasz Kazimierczak from comment #16)
> > > I was already disabled.
> > 
> > So broken BIOS :(
> > 
> > Does anything change if you set it to "enabled"?
> > 
> > Is there a BIOS update available?
> 
> Yes, actually enabling LVDS sort of fix the problem.
> Clean kernel loaded with same options work just fine.
> And that way the patch is unnecessary.
> 
> But, shouldn't it work also with disabled LVDS?

The problem is that the BIOS still partially enables it. And unfortunately our current code can't deal with that weird partially enabled hardware state. It would be possible to rework the code to handle it, but it wouldn't be an entirely trivial change.
Comment 23 Jani Saarinen 2018-03-29 07:10:52 UTC
First of all. Sorry about spam.
This is mass update for our bugs. 

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Comment 24 Jani Saarinen 2018-04-20 15:07:01 UTC
Tomasz, is this still issue?
Ville, any help here?
Comment 25 Ville Syrjala 2018-04-20 15:50:03 UTC
(In reply to Jani Saarinen from comment #24)
> Tomasz, is this still issue?
> Ville, any help here?

We haven't changed the code, so the problem still exists. But I hope we can live with the "enable LVDS in the BIOS" workaround for now. If someone is extremely bored they can try to change the code to deal with the wonky hardware state left behind by the BIOS.
Comment 26 Jani Saarinen 2018-04-20 20:01:32 UTC
Tomasz, are you ok with this?
Comment 27 Tomasz Kazimierczak 2018-04-24 13:48:31 UTC
Hello, 

Sorry for the late reply.

Yes, I can live with that and we can close this issue.
The blame goes to BIOS vendors, I guess...

Cheers,
T.

P.S. I'm setting status 'resolved->wontfix', but is it ok? maybe is should be something else?
Comment 28 Ville Syrjala 2018-04-24 13:53:52 UTC
(In reply to Tomasz Kazimierczak from comment #27)
> Hello, 
> 
> Sorry for the late reply.
> 
> Yes, I can live with that and we can close this issue.
> The blame goes to BIOS vendors, I guess...
> 
> Cheers,
> T.
> 
> P.S. I'm setting status 'resolved->wontfix', but is it ok? maybe is should
> be something else?

Good enough for me :) Thanks.

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.