[Bug 59841] [IVB cpu eDP] panel is broken due to 657445fe86 (eDP bpp clamping)

[bugzilla-daemon at bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=59841

--- Comment #211 from jkp <jkp at iki.fi> ---
Regarding "2) Black screen with link computation done in 18 bpp. Works if
computation is done in 24 bpp, and dithering to 18 bpp is set after that."

>From comment 75 (quoted below), is there a way to check if on computers
referred to in 2), the issue maybe has been fixed with the fixing of "1) Clock
recovery part of link training fails" with patch 110101?

In other words, is there contact to someone who could check if patch 110101
fixes the issue for these computers making it possible to revert the offending
commit
http://o.cs.uvic.ca:20810/perl/cid.pl?cid=657445fe8660100ad174600ebfa61536392b7624

"Trying to get the picture here of what's going on, please correct me if I'm
wrong:

1) The offending commit (which breaks things for TX300 & many others) is this
one by Daniel on 2013-05-04 (from comment 17):
http://o.cs.uvic.ca:20810/perl/cid.pl?cid=657445fe8660100ad174600ebfa61536392b7624

2) From comment 31 by Daniel, apparently on some computers, the bpp value must
be clamped before the dp bandwidth computation code, thus the addition of "bpp
= min_t(int, bpp, dev_priv->edp.bpp);" by Daniel, currently "bpp = min_t(int,
bpp, dev_priv->vbt.edp_bpp);". Is this correct?

3) However the clamping "bpp = min_t() line breaks things for many computers,
e.g. the TX300 and others. The bpp value from BIOS (intel_bios.c /
dev_priv->vbt.edp_bpp) appears to be 18 on the TX300, but apparently the bpp
value to be used is 24 from pipe_config-> pipe_bpp.

4) To make things work on TX300 and others as well as the computers Daniel is
talking about (which one(s)?), we'll some kind of way to differentiate between
computers which need the bpp = min_t line and computers which must not use it."

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.