[natty] UBUNTU: SAUCE: (no-up) [PATCH 0/2] Lenovo t420s display corrupution - drm/i915: delay modesetting registers
Jose Plans
jose.plans at canonical.com
Fri Nov 4 16:49:08 UTC 2011
BugLink: http://bugs.launchpad.net/bugs/812638
Please consider the following for Natty SRU.
== Natty SRU Justification ==
This is patch 1 of 2, both in upstream since early 2011 and well tested
upstream.
While the amount of insertions and deletions are quite significant, the
risk for regressions are minimal since this code does not add any new
changes except the one for the panel display corruption fix (delaying
the registers during modesetting).
The overall change relies on both delaying these registers PLL, pipe and
plane as well as regrouping the pipe/plane activation/deactivation
recurring instructions into clean functions for better reading and
maintenance (this is patch 2/2).
In addition, the commit (2/2) adds assertion functions. These functions
do only check the presence of pipe or planes when necessary. These are a
good inclusion for SRU since they would allow us to spot any issue
during display in the driver.
== Impact ==
Lenovo shipped the t420s Sandy Bridge laptops including both Intel
HD3000 (relying on i915) and different types of panels (LG and Samsung
so far reported in the bug).
Without the two patches, users cannot use this Lenovo t420s. The
display, at boot, is 2/3 of the screen black and 1/3 corrupted. The
system is locked too.
The only workaround is to disable the modesetting or use another
display.
== Fix ==
The Samsung panel seems to be more sensitive when it comes to enabling
the display at mode setting. By just enabling a pipe container and a
plane for mode setting at early stages, the panel will only display one
third of the whole plane with only horizontal lines and without the
ability to interact with the system (hang at that stage).
Applying the patch (1/2) delays the initialisation of the PLL, pipe and
plane for this hardware and Ironlake+ based display cards. Once applied
to the mode setting path and having these initialisations delayed, the
display works on a 90% success. However sometimes the symptoms are
different type of corruption or the same original one.
To fully fix the display corruption issue, there is a need to also fully
enable a pipe and plane later on the code for these cards.
This change does not affect older cards, since we preserve the original
order of activation by enabling these at their original ordering with:
=== snip ===
- dspcntr |= DISPLAY_PLANE_ENABLE;
- pipeconf |= PIPECONF_ENABLE;
- dpll |= DPLL_VCO_ENABLE;
+ if (!HAS_PCH_SPLIT(dev)) { <---------------------------| If not
using Gen5 nor Gen6. This means any card not Ironlake/SandyBridge
+ dspcntr |= DISPLAY_PLANE_ENABLE; | These older
cards are the original 915M which has been tested too to
+ pipeconf |= PIPECONF_ENABLE; | prevent
regressions.
+ dpll |= DPLL_VCO_ENABLE; | The flag
activation ordering remains therefore unchanged for these old cards.
+ }
=== /snip ===
For patch2/2:
The changes are:
1. New code: assertion functions to test whether during addition or
removal of pipes or planes we had or not initialise the pertinent pipes
or planes.
Example if there is a call to enable a plane, we need to test
whether a pipe (container) was already initialised.
This is a major win in terms of stable/maintenance/debug.
2. Changes: grouping add/remove pipe and planes instructions into
functions for better reading.
I have studied the differences from the previous code to the
generic instructions included on the functions, these are almost
identical in calls and identical in instructions. I couldn't find any
reason to believe there would be any issues with these changes.
Example:
New generic function to add a pipe:
=== snip ===
reg = PIPECONF(pipe);
val = I915_READ(reg);
val |= PIPECONF_ENABLE;
I915_WRITE(reg, val);
POSTING_READ(reg);
intel_wait_for_vblank(dev_priv->dev, pipe);
=== snip ===
Previous pipe addition which is often repeated any time there
was a need to enable a pipe:
=== snip ===
reg = PIPECONF(pipe);
temp = I915_READ(reg);
if ((temp & PIPECONF_ENABLE) == 0)
I915_WRITE(reg, temp | PIPECONF_ENABLE);
=== snip ===
Now, the POSTING_READ() macro allows a I915_READ() without
displaying.
The big difference on this part is the usage of the
intel_wait_for_vblank(), on this case (pipe add/remove) we would wait
for the vblank interrupt.
== Test Case ==
How to reproduce:
1. Enable in the BIOS the Intel internal display.
2. Boot the kernel without any changes in the parameters.
The previous results:
3. Display is corrupted.
With the patches:
3. Display is not corrupted.
Hardware tested:
--
if (!HAS_PCH_SPLIT(dev)) {
[...]
}
--
Being HAS_PCH_SPLIT defined as (IS_GEN5(dev) || IS_GEN6(dev))
GEN4 family: (Regression test)
- DELL Inspiron 1420:
8086 : 2a02 - Intel Mobile GM965/GL960 Integrated Graphics
Controller - GEN4:
* Natty kernel:
No issues found.
* 0001-drm-i915-don-t-enable-plane-pipe-and-PLL-prematurely.patch
No issues found.
* 0002-drm-i915-add-pipe-plane-enable-disable-functions.patch
No issues found.
GEN5 family:
- Lenovo x301:
8086 : 2a42 - Intel GMA 4500MHD - GEN5:
* Natty kernel:
No issues found.
* 0001-drm-i915-don-t-enable-plane-pipe-and-PLL-prematurely.patch
No issues found.
* 0002-drm-i915-add-pipe-plane-enable-disable-functions.patch
No issues found.
GEN6 family:
- Lenovo T420s: (laptop reporting the issues)
8086 : 0126 - Intel HD3000 - GEN6:
* Natty kernel:
Display is corrupted on the Samsung panel version of the Lenovo
t420s as described previously.
* 0001-drm-i915-don-t-enable-plane-pipe-and-PLL-prematurely.patch
The issue is reproducible ~10% of the boots.
* 0002-drm-i915-add-pipe-plane-enable-disable-functions.patch
The issue disappears.
Patch 1/2:
drivers/gpu/drm/i915/intel_display.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
Patch 2/2:
drivers/gpu/drm/i915/i915_reg.h | 5 +-
drivers/gpu/drm/i915/intel_display.c | 308
+++++++++++++++++++++++-----------
2 files changed, 216 insertions(+), 97 deletions(-)
thanks,
Jose
More information about the kernel-team
mailing list