From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3234EC433E2 for ; Tue, 1 Sep 2020 18:02:08 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 170262071B for ; Tue, 1 Sep 2020 18:02:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 170262071B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2AF6F6E8BB; Tue, 1 Sep 2020 18:02:06 +0000 (UTC) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1D2CA6E893; Tue, 1 Sep 2020 18:02:04 +0000 (UTC) IronPort-SDR: Cgz0p/P+RmoFo+NohPAE7GFuheWnJ5bdnBtHUS2k/uZj4fKtY7vUqiMbCkeYkVjuwRX8L6RDFb AxS0k3j9UPcg== X-IronPort-AV: E=McAfee;i="6000,8403,9731"; a="144974479" X-IronPort-AV: E=Sophos;i="5.76,379,1592895600"; d="scan'208";a="144974479" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2020 11:02:02 -0700 IronPort-SDR: rd1H57EaVjxrNmd8W7un0kEeyr0+w5UWt4yGUNSBinQxAjogP0ujYjBRJVLDz8gTHetWvdDYQs tUSqa+lOTSPw== X-IronPort-AV: E=Sophos;i="5.76,379,1592895600"; d="scan'208";a="477294921" Received: from kgeneral-mobl.ccr.corp.intel.com (HELO localhost) ([10.251.95.121]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2020 11:02:00 -0700 From: Jani Nikula To: lyude@redhat.com, intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20200901123226.4177-1-jani.nikula@intel.com> Date: Tue, 01 Sep 2020 21:01:57 +0300 Message-ID: <87d0354bqi.fsf@intel.com> MIME-Version: 1.0 Subject: Re: [Intel-gfx] [PATCH] drm/dp: start using more of the extended receiver caps X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Tue, 01 Sep 2020, Lyude Paul wrote: > On Tue, 2020-09-01 at 15:32 +0300, Jani Nikula wrote: >> In the future, we'll be needing more of the extended receiver capability >> field starting at DPCD address 0x2200. (Specifically, we'll need main >> link channel coding cap for DP 2.0.) Start using it now to not miss out >> later on. >> >> Cc: Lyude Paul >> Signed-off-by: Jani Nikula >> >> --- >> >> I guess this can be merged after the topic branch to drm-misc-next or >> so, but I'd prefer to have this fairly early on to catch any potential >> issues. >> --- >> drivers/gpu/drm/drm_dp_helper.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c >> index 1e7c638873c8..3a3c238452df 100644 >> --- a/drivers/gpu/drm/drm_dp_helper.c >> +++ b/drivers/gpu/drm/drm_dp_helper.c >> @@ -436,7 +436,7 @@ static u8 drm_dp_downstream_port_count(const u8 >> dpcd[DP_RECEIVER_CAP_SIZE]) >> static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux, >> u8 dpcd[DP_RECEIVER_CAP_SIZE]) >> { >> - u8 dpcd_ext[6]; >> + u8 dpcd_ext[DP_RECEIVER_CAP_SIZE]; > > Not 100% sure this is right? It's not clear at first glance of the 2.0 spec, but > my assumption would be that on < DP2.0 devices that everything but those first 6 > bytes are zeroed out in the extended DPRX field. Since we memcpy() dpcd_ext > using sizeof(dpcd_ext), we'd potentially end up zeroing out all of the DPCD caps > that comes after those 6 bytes. Re-reading stuff... AFAICT everything in 0x2200..0x220F should be valid. They should match what's in 0x0000..0x000F except for 0x0000, 0x0001, and 0x0005, for backwards compatibility. Apparently there are no such backwards compatibility concerns with the other receiver cap fields then. But it gives me an uneasy feeling that many places in the spec refer to 0x2200+ even though they should per spec be the same in 0x0000+. I guess we can try without the change, and fix later if we hit issues. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx