Bug 94087

Please advise how to dump the VBT information in case it would be helpful here.

intel_bios_reader reports 16 eDP panel records, of which all are like Panel 1, except the respected Panel 2:

        Panel 1
                Power Sequence: T3 2000 T7 10 T9 2000 T10 500 T12 5000
                Panel color depth: 18 bpp
                eDP sDRRS MSA Delay: Lane 1
                Link params:
                        rate: 1.62G
                        lanes: x2 mode
                        pre-emphasis: none
                        vswing: 0.4V


        Panel 2 *
                Power Sequence: T3 2000 T7 135 T9 800 T10 400 T12 5000
                Panel color depth: 18 bpp
                eDP sDRRS MSA Delay: Lane 1
                Link params:
                        rate: 2.7G
                        lanes: x1 mode
                        pre-emphasis: none
                        vswing: 0.4V

Wah, for BDW, the tick tock spaghetti in intel_ddi does not (!!!) respect the disabled edp_low_vswing, at all (or I am blind). I.e. it forces low_vswing for eDP.

This means that this has never been working for BDW since Nov 2013. Obvious workarounds:

 1. Install Windows.
 2. Patch your kernel with Ben's patch.
 3. Upgrade your mainboard to Skylake.
 4. Wait for a fix by Intel.

Issue introduced by commit:

commit 300644c7dc4699fe9afb61b280aa5ed7109a4d93
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Sat Nov 2 21:07:42 2013 -0700

Fix:

Correctly dispatch to the DP table for eDP in the case of non-low_vswing, like for SKL.

I conclude:

Older T450s either never run Linux with the FHD panel in the T450s.

Created attachment 121666 [details]
opregion

Add opregion as requested in IRC.

The BIOS changelog for 1.20 indicates that Lenovo updated the "EDID" (i.e. also the VBT?) in late December 2015.
The update is not yet pushed to Windows users via the Lenovo tools as far as I could see.

https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-bdw-vol11-display_0.pdf
says that the eDP table should ONLY be used for low_vswing. I.e. it is always wrong to have the new voltage levels on the eDP links if the VBT did not allow low vswings.

I do not see how the current code would differentiate between low and normal vswings.

Hmm, but: intel_bios_reader does not have a notion of low vswing (yet). This confused me.

By looking at the block 27, its obvious that the huge amount of zeros means that low_vswing is enforced. This in turn means that i915 would be doing the right thing according to the VBT: set low vswing.

Created attachment 121670 [details] [review]
Fix for BDW edp vswing

From your VBT I can read that your panel is not using low voltage swing. This part of reading out low or default voltage swing value is actually missing from intel_bios_reader and I need to address that one by providing a patch for it. 

The proposed patch has the same idea as Ben had but this adds additional check if the VBT has requested low voltage swing for eDP. Otherwise, the default translation table is applied. 

You can always override the eDP voltage swing by setting a module parameter

i915.edp_vswing=2 (uses default, higher vswing) or i915.edp_vswing=1 (uses low vswing)

Please, give this patch a go and report back if it succeeds to fix the problem or not.

"You can always override the eDP voltage swing by setting a module parameter

i915.edp_vswing=2"

This was not working before the patch you attached for BDW. Now it should work.

I gathered a VBT of an older BIOS update for the same model (with a different panel, maybe). How would I know that it also enforces normal vswing? To me, block_27[0xec] seems all zero as well. Is not that used as a low_vswing indicator?

Mika, you computed offset 0xcc for block 27. Those 8 bytes are all 0x11. And they are the same in my VBT and the VBT of a much older BIOS version (gathered from a friend of mine).

Thus, I am inclined to say that block 27 is a red herring: at least the low_swing setting did not change between those versions. Nevertheless, nobody on the interwebz seems to have exactly my eDP issues with a T450 or T450s.

The only diffs between the old and new VBT are:

In Block 27:
-       00e0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
+       00e0: 34 08 00 00 00 00 00 00  00 00 00 00 00 00 00 00

In Block 42:
-*      panel type 02: 1920x1080 clock 138700000
+*      panel type 02: 1920x1080 clock 141000000
                info:
-                 LVDS: 0x0020033c
+                 LVDS: 0x0030033c
                  PP_ON_DELAYS: 0x025807d0
                  PP_OFF_DELAYS: 0x01f407d0
                  PP_DIVISOR: 0x00270f05
-                 PFIT: 0x3870a080
-               timings: 1920 1968 2000 2080 1080 1083 1088 1111 138700.00 (good)
+                 PFIT: 0x3870b880
+               timings: 1920 1936 1952 2104 1080 1083 1097 1116 141000.00 (good)

The meaning for those 8 bytes is that for all 16 panels (half a byte for each panel)

0 = low voltage swing setting (200 mV)
1 = default voltage swing setting (400 mV)

In your case, you should use default voltage swing. Unfortunately, it seemed that the driver uses only low voltage swing settings for broadwell.

Correct Mika. But! It was working for the person with the other VBT and similar kernels. I.e. there must be another reason why it was not noticed until now.
I think it would be useful to find it out.

Can you tell what version of of embedded DisplayPort you have? The spec for eDP1.4 for Broadwell suggests to use lower voltage swing values, which in your case may not be enough and the DP link becomes more error prone.

(In reply to Mika Kahola from comment #12)
> Can you tell what version of of embedded DisplayPort you have?

cat /sys/kernel/debug/dri/0/eDP-1/i915_dpcd

(In reply to Jani Nikula from comment #13)
> (In reply to Mika Kahola from comment #12)
> > Can you tell what version of of embedded DisplayPort you have?
> 
> cat /sys/kernel/debug/dri/0/eDP-1/i915_dpcd

Yes, the first byte dictates the revision. For eDP 1.4 you should read 0x14

The working laptop has the first byte as 0x12, mine shows 0x11 with the kernel that loads the DP DDI table. I guess I will reboot with the non-patched kernel and see what the DPCD tells me.

Also without the patch, I get 0x11.
I.e. my newly bought laptop has a lower version (does not work) that the older laptop of the same model (works).

Can somebody give me some indication of the actual frequency used for the FHD resolution on (e)DP?
It is hard to figure it out as I do not have a precise frequency counter here.
Knowing the frequency is useful to understand potential noise sources.

Ah, it is possible to see the current pixel clock using xrandr --verbose.
Interestingly, I get two timing profiles for FHD in my VBT/EDID:

  1920x1080 (0x4a) 141.000MHz -HSync -VSync +preferred
        h: width  1920 start 1936 end 1952 total 2104 skew    0 clock  67.02KHz
        v: height 1080 start 1083 end 1097 total 1116           clock  60.05Hz
  1920x1080 (0x107) 138.500MHz +HSync -VSync *current
        h: width  1920 start 1968 end 2000 total 2080 skew    0 clock  66.59KHz
        v: height 1080 start 1083 end 1088 total 1111           clock  59.93Hz

Please try current drm-intel-nightly branch from 
http://cgit.freedesktop.org/drm-intel

This might be relevant:

commit a05628195a0d9f3173dd9aa76f482aef692e46ee
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Apr 11 10:23:51 2016 +0300

    drm/i915: Get panel_type from OpRegion panel details

Should be fixed by:

commit 00983519214b61c1b9371ec2ed55a4dde773e384
Author: Mika Kahola <mika.kahola@intel.com>
Date:   Wed Apr 20 15:39:02 2016 +0300

    drm/i915: Fix eDP low vswing for Broadwell

It looks like above fix does not fix the underlying cause: there is cross talk in this models display controller symmetric eDP channel rails and the shortwave radio in the intel cpu core that is used from the vbios and/or IME to radiate the screen/audio in bad ECB mode into the world's ether.

Please confirm this crosstalk possibility with your colleagues in California (the block might have been engineered somewhere in EMEA) and talk back here on potential mitigation paths.

Alternatively, ask for the activation/knocking pattern to turn on the radio for your HP laptop and attach a simple coupler to the grounding of your 20V connector and use a spectrum analyzer to have a look at the SW range around 8-12 Mhz.