[Intel-gfx] drm/dp: add module parameter for the dpcd access max retries

Commit Message

Feng Tang May 10, 2018, 9:21 a.m. UTC

On Wed, May 09, 2018 at 12:28:15PM +0300, Jani Nikula wrote:
> On Wed, 09 May 2018, Feng Tang <[e-mail]> wrote:
> > On Wed, May 09, 2018 at 10:53:53AM +0300, Jani Nikula wrote:
> >> On Wed, 09 May 2018, Feng Tang <[e-mail]> wrote:
> >> > On Tue, May 08, 2018 at 10:30:19PM +0300, Jani Nikula wrote:
> >> >> On Wed, 09 May 2018, Feng Tang <[e-mail]> wrote:
> >> >> >> Well if it's edp probing, then atm we do need to block since we have
> >> >> >> no support for panel hotplugging. And userspace generally no
> >> >> >> expectations that built-in panels come&go. async_synchronize_full
> >> >> >> making our fbdev code less async than desired is kinda a different
> >> >> >> story I think here. First step would be trying to figure out why we
> >> >> >> even bother with edp probing on this platform, when the thing isn't
> >> >> >> there. Sounds like broken VBT.
> >> >> >
> >> >> > Hi Daniel,
> >> >> >
> >> >> > Here are some of the VBT and DPCD related logs on my A3900 (bxt + GEN9 LP)
> >> >> > based NUC. but I don't have the knowledge to tell if the VBT is broken :)
> >> >> 
> >> >> Please run current upstream drm-tip when you're suggesting changes to
> >> >> upstream code. Looks like you're running at most v4.14. This can't be
> >> >> emphasized enough. We can't and won't merge the changes unless they make
> >> >> sense with current code.
> >> >
> >> > Yes, I understand, the patch posted  was created right after git-pulling
> >> > Linus' tree, and back-ported to test with 4.14 kernel. 
> >> >
> >> >> 
> >> >> As to vbt, please send me /sys/kernel/debug/dri/0/i915_vbt.
> >> >
> >> > Sure. as attached
> >> 
> >> Your VBT claims the device has an eDP panel. Does it have one or not?
> >
> > After asking around, our platform (BXT NUC) does have a eDP interface (someone
> > has tested with a eDP screen), but most of our platforms are connected
> > with 2 HDMI LCD monitors.
> 
> Sounds like you should have a different VBT for the cases where you ship
> with/without eDP connected. As you've noticed, we generally try pretty
Yep, this is a good idea. Currently I'm not able to change VBT, so I hacked
the code to simulating a no-eDP VBT like:

better as it runs in an async way at this point.

Thanks,
Feng

Patch

--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1261,7 +1261,8 @@  static void parse_ddi_port(struct drm_i915_private *dev_priv, enum port port,
 	is_crt = child->device_type & DEVICE_TYPE_ANALOG_OUTPUT;
 	is_hdmi = is_dvi && (child->device_type & DEVICE_TYPE_NOT_HDMI_OUTPUT) == 0;
-	is_edp = is_dp && (child->device_type & DEVICE_TYPE_INTERNAL_CONNECTOR);
+	is_edp = 0; 
 
And it does cut the boottime a lot!! as avoiding the dpcd access.

And later i915_hpd_poll_init_work() will still call intel_dp_detect() and
call the time-eater drm_dp_dpcd_access() finally, but the situation is