From patchwork Thu Apr 7 07:58:11 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jani Nikula X-Patchwork-Id: 8769381 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 1DD1FC0553 for ; Thu, 7 Apr 2016 07:58:17 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 3F49D20115 for ; Thu, 7 Apr 2016 07:58:16 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 551872010F for ; Thu, 7 Apr 2016 07:58:15 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7A1FF6E932; Thu, 7 Apr 2016 07:58:14 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTP id E97626E932 for ; Thu, 7 Apr 2016 07:58:13 +0000 (UTC) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP; 07 Apr 2016 00:58:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,448,1455004800"; d="scan'208";a="953543221" Received: from jnikula-mobl.fi.intel.com (HELO localhost) ([10.237.72.67]) by fmsmga002.fm.intel.com with ESMTP; 07 Apr 2016 00:58:12 -0700 From: Jani Nikula To: Tvrtko Ursulin , Ander Conselvan De Oliveira , intel-gfx@lists.freedesktop.org, Shubhangi Shrivastava In-Reply-To: <57051F4A.9060204@linux.intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <1459341326-13142-1-git-send-email-shubhangi.shrivastava@intel.com> <20160331123833.6934.86271@emeril.freedesktop.org> <1459496485.2777.8.camel@gmail.com> <57024268.7000909@linux.intel.com> <877fgdzl5h.fsf@intel.com> <570252DC.5070701@linux.intel.com> <57051F4A.9060204@linux.intel.com> User-Agent: Notmuch/0.21+91~gada1e33 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Thu, 07 Apr 2016 10:58:11 +0300 Message-ID: <87twjdx33g.fsf@intel.com> MIME-Version: 1.0 Subject: Re: [Intel-gfx] =?utf-8?q?=E2=9C=93_Fi=2ECI=2EBAT=3A_success_for_seri?= =?utf-8?q?es_starting_with_=5B1/5=5D_drm/i915=3A_Splitting_intel=5Fdp=5Fd?= =?utf-8?q?etect?= X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, 06 Apr 2016, Tvrtko Ursulin wrote: > On 04/04/16 12:41, Tvrtko Ursulin wrote: >> >> On 04/04/16 12:08, Jani Nikula wrote: >>> On Mon, 04 Apr 2016, Tvrtko Ursulin >>> wrote: >>>> On 01/04/16 08:41, Ander Conselvan De Oliveira wrote: >>>>> On Thu, 2016-03-31 at 12:38 +0000, Patchwork wrote: >>>>>> == Series Details == >>>>>> >>>>>> Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect >>>>>> URL : https://patchwork.freedesktop.org/series/5044/ >>>>>> State : success >>>>> >>>>> I pushed those to dinq. >>>> >>>> This series seems to break eDP detection on BDW RVP. >>> >>> I presume this is due to the sink count check. Can you add debug logging >>> to print intel_dp->sink_count after it's been read in >>> intel_dp_get_dpcd() please? >> >> intel_dp->sink_count is zero here. (raw value, before the >> DP_GET_SINK_COUNT.) >> >> Also, intel_dp_dpcd_read_wake suggests a possibility for reading garbage >> with not overly confident wording for the workaround there. >> >>> Then the question is, is this just because you have an RVP with who >>> knows what panel, or do we have to take into account potentially broken >>> panels too? Then I assume the fix would be to to ignore sink count for >>> eDP. >> >> No idea. :) > > I could really use a solution for this. My only development platform is > incapacitated unless I revert this series which, apart from the extra > work when preparing and sending out patches this is taking, including > lost time waiting on CI which I suspect dislikes patches from top of > unknown bases, I think it won't be so easy to continue doing so when the > conflicts start arriving. :( Ander, Shubhangi? Would something like this be sensible? Tvrtko, can you give it a go? BR, Jani. diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index da0c3d29fda8..0890e71db188 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -3799,6 +3799,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp) */ intel_dp->sink_count = DP_GET_SINK_COUNT(intel_dp->sink_count); + if (is_edp(intel_dp)) + intel_dp->sink_count = max(intel_dp->sink_count, 1); + /* * SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that * a dongle is present but no display. Unless we require to know