Bug 103779

Created attachment 135518 [details]
kernel dmesg without patch

Created attachment 135519 [details]
kernel dmesg with patch

(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

Created attachment 135776 [details]
kernel dmesg with patch - update

update of dmesg for patched kernel

Created attachment 135777 [details]
kernel dmesg without patch - update

update of clean kernel dmesg (i.e. without patch)

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)

Created attachment 135779 [details]
copy of i915_opregion file - with patch

copy of  /sys/kernel/debug/dri/0/i915_opregion file - with patch

Sorry for previous bad attachments.

(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.

Created attachment 135792 [details]
kernel dmesg with patch - second update

Second update of dmesg with proper kernel options

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)

Created attachment 135794 [details]
copy of i915_opregion file - with patch

update

Created attachment 135795 [details]
copy of i915_opregion file - without patch (clean)

update

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 :)

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

I was already disabled.

*It was already disabled

*It was already disabled(In reply to Tomasz Kazimierczak from comment #16)
> I was already disabled.

Sorry for typo.

(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?

Created attachment 136088 [details]
kernel dmesg without patch (clean) and with BIOS LVDS option enabled

(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.

(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.

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.

Tomasz, is this still issue?
Ville, any help here?

(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.

Tomasz, are you ok with this?

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?

(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.