Bug 97971

Created attachment 126850 [details] [review]
possible fix

(In reply to yangbo from comment #1)
> Created attachment 126850 [details] [review] [review]
> possible fix

would use of IS_VALLEYVIEW(dev) be fitting here?

(In reply to yann from comment #2)
> (In reply to yangbo from comment #1)
> > Created attachment 126850 [details] [review] [review] [review]
> > possible fix
> 
> would use of IS_VALLEYVIEW(dev) be fitting here?

Ah, it probably works.

if the card doesn't has the problem, ret != 0. otherwise probe digital port.

so it doesn't matter if other valleyview cards have this problem or not.

Created attachment 126851 [details] [review]
Update patch to use IS_VALLEYVIEW(dev)

杨波, can you get /sys/kernel/debug/dri/0/i915_vbt or /sys/kernel/debug/dri/0/i915_opregion from the original reporter?

Ville, any idea if we should be looking at some other ddc pin in the VBT, or is the IS_VALLEYVIEW() thing all right? Are there any machines that would have both VGA and DVI connectors, or does having DVI always mean that the VGA is routed to DVI-I?

The original commit adding the retry on DVI-I ddc pin isn't too helpful:

commit 8e4d36b993898b344f9176147f1dfeca583f81fd
Author: ling.ma@intel.com <ling.ma@intel.com>
Date:   Tue Jun 30 11:35:34 2009 +0800

    drm/i915: crt fetch EDID by DVI-I converter on G4x platform
    
    Usually crt mainly get modes via GPIOA ports.
    However on G4X platform we need to probe possible
    ports for DVI-I, which could be wired to GPIOD,
    then fetch our desired EDID, i.e on DG45ID platform
    we successfully fetch EDID by GPIOD port.
    
    It fixed freedesktop.org bug #21084
    
    Signed-off-by: Ma Ling <ling.ma@intel.com>
    Signed-off-by: Eric Anholt <eric@anholt.net>

(In reply to Jani Nikula from comment #5)
> 杨波, can you get /sys/kernel/debug/dri/0/i915_vbt or
> /sys/kernel/debug/dri/0/i915_opregion from the original reporter?
> 


I'll ask for the information and the feedback ASAP

Patch submitted by Chris: https://patchwork.freedesktop.org/series/13066/

(In reply to Jani Nikula from comment #5)
> 杨波, can you get /sys/kernel/debug/dri/0/i915_vbt or
> /sys/kernel/debug/dri/0/i915_opregion from the original reporter?
> 
> Ville, any idea if we should be looking at some other ddc pin in the VBT, or
> is the IS_VALLEYVIEW() thing all right? Are there any machines that would
> have both VGA and DVI connectors, or does having DVI always mean that the
> VGA is routed to DVI-I?

I didn't realize we even had machines with DVI-I. I've only ever seen separate DVI-D + VGA myself.

I would be rather surprised if there's a VLV machine with DVI-I. But who knows, I've been known to be wrong occasionally. So the key question here is; Does the machine have DVI-I, or just HDMI/DVI-D using non-standard DDC pins?

As far as finding the right DDC pin goes, I think VBT has both the global CRT DDC pin, and the per-child device DDC pin. We only look at the global thing I believe. Dunno if we should be looking at the other one.

(In reply to Ville Syrjala from comment #8)
> (In reply to Jani Nikula from comment #5)
> > 杨波, can you get /sys/kernel/debug/dri/0/i915_vbt or
> > /sys/kernel/debug/dri/0/i915_opregion from the original reporter?
> > 
> > Ville, any idea if we should be looking at some other ddc pin in the VBT, or
> > is the IS_VALLEYVIEW() thing all right? Are there any machines that would
> > have both VGA and DVI connectors, or does having DVI always mean that the
> > VGA is routed to DVI-I?
> 
> I didn't realize we even had machines with DVI-I. I've only ever seen
> separate DVI-D + VGA myself.
> 
> I would be rather surprised if there's a VLV machine with DVI-I. But who
> knows, I've been known to be wrong occasionally. So the key question here
> is; Does the machine have DVI-I, or just HDMI/DVI-D using non-standard DDC
> pins?

And naturally "... CRT with non-standard DDC pins?" would have been the right question.

Created attachment 126892 [details]
i915 opregion

information provided moving bug back to reopen

Hello everybody,
I noticed the last update in this case is quite old. Is this issue still valid?
Thank you.

(In reply to yann from comment #7)
> Patch submitted by Chris: https://patchwork.freedesktop.org/series/13066/
Closing this case based on Yann's comment and due the lack of new occurrences reported since September 2016.
Thanks.