On Wed, May 09, 2018 at 12:28:15PM +0300, Jani Nikula wrote: > On Wed, 09 May 2018, Feng Tang <feng.tang@xxxxxxxxx> wrote: > > On Wed, May 09, 2018 at 10:53:53AM +0300, Jani Nikula wrote: > >> On Wed, 09 May 2018, Feng Tang <feng.tang@xxxxxxxxx> wrote: > >> > On Tue, May 08, 2018 at 10:30:19PM +0300, Jani Nikula wrote: > >> >> On Wed, 09 May 2018, Feng Tang <feng.tang@xxxxxxxxx> 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: --- 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 better as it runs in an async way at this point. Thanks, Feng _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
