From patchwork Thu May 10 09:21:01 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Feng Tang X-Patchwork-Id: 10391463 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 0DB6B60540 for ; Thu, 10 May 2018 09:20:20 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id ECCC3289B5 for ; Thu, 10 May 2018 09:20:17 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id DE610289B8; Thu, 10 May 2018 09:20:17 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 5ACA8289B5 for ; Thu, 10 May 2018 09:20:15 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D09E46EEB8; Thu, 10 May 2018 09:20:10 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by gabe.freedesktop.org (Postfix) with ESMTPS id 12CE26EEB3; Thu, 10 May 2018 09:20:09 +0000 (UTC) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2018 02:20:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,384,1520924400"; d="scan'208";a="39853554" Received: from shbuild888.sh.intel.com (HELO localhost) ([10.239.146.239]) by orsmga007.jf.intel.com with ESMTP; 10 May 2018 02:20:06 -0700 Date: Thu, 10 May 2018 17:21:01 +0800 From: Feng Tang To: Jani Nikula Message-ID: <20180510092101.aylra6r6ua4ey6mj@shbuild888> References: <20180507150921.GC28661@phenom.ffwll.local> <20180508190315.o4nodihfflkhbba5@shbuild888> <152577922276.24602.629289802991960786@mail.alporthouse.com> <20180508230847.4esu22dtipguqvw3@shbuild888> <878t8uoshg.fsf@intel.com> <20180509063117.org33maeu22ivyhu@shbuild888> <87sh71463y.fsf@intel.com> <20180509075651.cyno666vhmixela6@shbuild888> <87h8nh41qo.fsf@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87h8nh41qo.fsf@intel.com> User-Agent: NeoMutt/20170609 (1.8.3) Subject: Re: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: feng.tang@intel.com, David Airlie , intel-gfx , dri-devel , fei.jiang@intel.com Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP On Wed, May 09, 2018 at 12:28:15PM +0300, Jani Nikula wrote: > On Wed, 09 May 2018, Feng Tang wrote: > > On Wed, May 09, 2018 at 10:53:53AM +0300, Jani Nikula wrote: > >> On Wed, 09 May 2018, Feng Tang wrote: > >> > On Tue, May 08, 2018 at 10:30:19PM +0300, Jani Nikula wrote: > >> >> On Wed, 09 May 2018, Feng Tang 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 --- 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