Bug 95476 - [BXT-P] i915 driver overwrites the DDI PHY register for the 1366x768 panel with incorrect values
Summary: [BXT-P] i915 driver overwrites the DDI PHY register for the 1366x768 panel wi...
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: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-18 20:04 UTC by Tarun Vyas
Modified: 2017-07-24 22:41 UTC (History)
2 users (show)

See Also:
i915 platform: BXT
i915 features: display/eDP

Attachments
Full dmesg log (60.36 KB, text/plain)
2016-05-18 20:04 UTC, Tarun Vyas 		no flags Details
View All

Description Tarun Vyas 2016-05-18 20:04:01 UTC 
Created attachment 123891 [details]
Full dmesg log

In the APL platforms, the firmware enables the 1366x768 panels by correctly programming the DDI PHY registers, but this leads to a PHY state mismatch according to the i915 driver because the driver expects to read a value from the PHY registers that differs from what was programmed by the firmware. Hence, the i915 driver goes ahead and reprograms the PHY, incorrectly, causing the DP link training to fail. The i915 driver will need modifications to correct this behavior. Filing this bug to track those modifications.

Steps to reproduce:
1. Connect a 1366x768 panel as an eDP to a APL system.
2. Boot the system with dinq kernel.
3. The 1366x768 panel will fail to come up.

Reproduciblity: 100%

System architecture: x86_64

Kernel version: 4.6.0-01610-g68c6a6d-dirty

Linux distro: Chromium OS

Display Connector: eDP

Machine info:
Comment 1 Tarun Vyas 2016-05-18 20:08:05 UTC 
FYI: Imre Deak <imre.deak@intel.com> is aware of this issue and he'll be providing a fix soon.
Comment 2 Jani Nikula 2016-05-23 12:51:08 UTC 
(In reply to Tarun Vyas from comment #0)
> In the APL platforms, the firmware enables the 1366x768 panels by correctly
> programming the DDI PHY registers, but this leads to a PHY state mismatch
> according to the i915 driver because the driver expects to read a value from
> the PHY registers that differs from what was programmed by the firmware.
> Hence, the i915 driver goes ahead and reprograms the PHY, incorrectly,
> causing the DP link training to fail. The i915 driver will need
> modifications to correct this behavior. Filing this bug to track those
> modifications.

I get the impression you know where things go wrong; can you give more specifics please?

Alternatively, please add 'intel_reg dump' output before and after loading the i915 driver, i.e. register dumps with the values programmed by firmware and i915, respectively.

The intel_reg tool is part of the intel-gpu-tools package 
http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/
Comment 3 Imre Deak 2016-05-23 13:43:25 UTC 
(In reply to Jani Nikula from comment #2)
> (In reply to Tarun Vyas from comment #0)
> > In the APL platforms, the firmware enables the 1366x768 panels by correctly
> > programming the DDI PHY registers, but this leads to a PHY state mismatch
> > according to the i915 driver because the driver expects to read a value from
> > the PHY registers that differs from what was programmed by the firmware.
> > Hence, the i915 driver goes ahead and reprograms the PHY, incorrectly,
> > causing the DP link training to fail. The i915 driver will need
> > modifications to correct this behavior. Filing this bug to track those
> > modifications.
> 
> I get the impression you know where things go wrong; can you give more
> specifics please?
> 
> Alternatively, please add 'intel_reg dump' output before and after loading
> the i915 driver, i.e. register dumps with the values programmed by firmware
> and i915, respectively.
> 
> The intel_reg tool is part of the intel-gpu-tools package 
> http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/

The problem is caused by incorrect PHY lane staggering setup, not matching the eDP lane configuration. I'm working on a solution that moves the PHY setup later where we know already the eDP lane config, so can program the staggering properly.
Comment 4 Imre Deak 2016-06-07 19:34:10 UTC 
Could you try if the following patchset solves the problem:
https://lists.freedesktop.org/archives/intel-gfx/2016-June/097854.html
Comment 5 Tarun Vyas 2016-06-08 20:53:10 UTC 
I tried booting a Chromium image with the latest drm-intel-next and *as expected*, the 1366x768 panel *did not* light up with "link training errors" in the log.

Subsequently, I applied the 6 patches starting @ https://patchwork.freedesktop.org/patch/92202/ and ending @ https://patchwork.freedesktop.org/patch/92407/ and built another Chromium image. This time the 1366x768 panel lighted up, so that patches are helping. Will have to do more regression testing.
Comment 6 Imre Deak 2016-06-13 16:30:02 UTC 
(In reply to Tarun Vyas from comment #5)
> I tried booting a Chromium image with the latest drm-intel-next and *as
> expected*, the 1366x768 panel *did not* light up with "link training errors"
> in the log.
> 
> Subsequently, I applied the 6 patches starting @
> https://patchwork.freedesktop.org/patch/92202/ and ending @
> https://patchwork.freedesktop.org/patch/92407/ and built another Chromium
> image. This time the 1366x768 panel lighted up, so that patches are helping.
> Will have to do more regression testing.

The patch is merged now to drm-intel-nightly, so closing this for now. Please reopen this if you still see the problem.

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.