On Wed, Apr 03, 2019 at 11:37:21AM -0700, Manasi Navare wrote:
On Wed, Apr 03, 2019 at 03:14:51PM +0300, Ville Syrjälä wrote:
On Tue, Apr 02, 2019 at 02:52:34PM -0700, Manasi Navare wrote:
For certain eDP 1.4 panels, we need to use max lane count for the link training to succeed.
This patch adds a EDID quirk for such eDP panels using their vendor ID and product ID to force using max lane count in the driver.
Rather than opening the quirk can of worms I think we should consider changing the retry loop to do something more sensible than what it's doing now. The current behaviour of "start at optimal settings (which can be either min lanes or min rate), and then reduce lanes/rate until stuff works" overlooks several possible combinations. One possible approach could be to start the retry loop with max lanes + max rate after the optimal settings have failed. It probably won't give you the best power consumption, but at least you get a picture on the screen if even a single lane count + rate combo works.
So you are saying that for eDP only we should modify the retry function to retry with max lanes and max rate so what we used to do earlier with < eDP 1.4?
Hmm I could try doing that, the only concern I have there is that certain eDP panels just need a retry at same parameters to work so for such panels where the lower values of link rate/lane count work with just an extra retry we would still be using max link rate /lane count now with this change.
If the panels are borked then I wouln't worry about it as long a picture appaears on the screen. And if the extra training cycle is because of some bug in our code then we should figure it out what that bug is.
Or are you suggesting doing the retry with same params for edp < 1.4 and for all edp 1.4 , we retry with , max link rate lane ocunt?
retrain_fail() { if (!use_max_params) { use_max_params = true; rate = max; lanes = max; } else { reduce rate/lanes as usual } }
compute_config() { if (use_max_params) { limits.min = limits.max; } ... }
or something like that.