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=-13.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 175A2C433ED for ; Tue, 13 Apr 2021 17:22:28 +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 C3105613B1 for ; Tue, 13 Apr 2021 17:22:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C3105613B1 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 6651B6E841; Tue, 13 Apr 2021 17:22:27 +0000 (UTC) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by gabe.freedesktop.org (Postfix) with ESMTPS id AF36F6E841 for ; Tue, 13 Apr 2021 17:22:25 +0000 (UTC) IronPort-SDR: MWvaes1/1o0AWWDZE/b9S1qlvDW5lEEiVbwNGXqAFxScqd1ZET30/kHlnsq0GGfeKfLZuYFUNs EtPnrgWaZcBg== X-IronPort-AV: E=McAfee;i="6200,9189,9953"; a="174564838" X-IronPort-AV: E=Sophos;i="5.82,219,1613462400"; d="scan'208";a="174564838" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Apr 2021 10:22:25 -0700 IronPort-SDR: 5NzfpSYWx9KY/Q6b+wK1n99K2Q1p2qz/5EBTt/sxeUbUpczG+BziI3JKDj4OQ4+xVzTNTwS9Y+ X80ib9EpxYJg== X-IronPort-AV: E=Sophos;i="5.82,219,1613462400"; d="scan'208";a="420863464" Received: from jchunter-mobl.amr.corp.intel.com (HELO ldmartin-desk2) ([10.209.120.106]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Apr 2021 10:22:24 -0700 Date: Tue, 13 Apr 2021 10:22:24 -0700 From: Lucas De Marchi To: Ville =?utf-8?B?U3lyasOkbMOk?= Message-ID: <20210413172224.oqlnqqxgpqy6ifty@ldmartin-desk2> X-Patchwork-Hint: comment References: <20210413060927.114342-1-lucas.demarchi@intel.com> <20210413060927.114342-4-lucas.demarchi@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Subject: Re: [Intel-gfx] [PATCH 3/3] drm/i915/display: remove strap checks from gen 9 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: , Cc: intel-gfx@lists.freedesktop.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Tue, Apr 13, 2021 at 06:45:16PM +0300, Ville Syrj=E4l=E4 wrote: >On Mon, Apr 12, 2021 at 11:09:27PM -0700, Lucas De Marchi wrote: >> Direction on gen9+ was to stop reading the straps and only rely on the >> VBT for marking the port presence. This happened while dealing with >> WaIgnoreDDIAStrap and instead of using it as a WA, it should now be the >> normal flow. See commit 885d3e5b6f08 ("drm/i915/display: fix comment on >> skl straps"). >> >> For gen 10 it's hard to say if this will work or not since I can't test >> it, so leave it with the same behavior as before. >> >> For PCH_TGP we should still rely on the VBT to make ports E and F not >> available. >> >> Signed-off-by: Lucas De Marchi >> Reviewed-by: Anusha Srivatsa >> --- >> drivers/gpu/drm/i915/display/intel_display.c | 36 ++++++-------------- >> 1 file changed, 11 insertions(+), 25 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/= drm/i915/display/intel_display.c >> index d62ce9c87748..5a03cbba0280 100644 >> --- a/drivers/gpu/drm/i915/display/intel_display.c >> +++ b/drivers/gpu/drm/i915/display/intel_display.c >> @@ -10883,34 +10883,25 @@ static void intel_setup_outputs(struct drm_i91= 5_private *dev_priv) >> intel_ddi_init(dev_priv, PORT_B); >> intel_ddi_init(dev_priv, PORT_C); >> vlv_dsi_init(dev_priv); >> + } else if (DISPLAY_VER(dev_priv) =3D=3D 9) { > >Should be >=3D10 I presume? Or did we want ot handle cnl along with why >=3D 10? The only DISPLAY_VER() =3D=3D 10 platforms out there are handl= ed in the branch above. I can make it >=3D 9, but not >=3D 10. Intention was to handle skl/kbl here. >icl perhaps? Doesn't really matter I suppose, but it's surely >going to consfuse the me the next time I read this. > >> + intel_ddi_init(dev_priv, PORT_A); >> + intel_ddi_init(dev_priv, PORT_B); >> + intel_ddi_init(dev_priv, PORT_C); >> + intel_ddi_init(dev_priv, PORT_D); >> + intel_ddi_init(dev_priv, PORT_E); >> + intel_ddi_init(dev_priv, PORT_F); > >DDI F isn't a thing on skl/derivatives, so I'd probably skip it on >those. Could just use IS_CNL_WITH_PORT_F() to match the looks of >the icl stuff. I was actually looking at ICL and thinking "shouldn't this hack for broken VBT be hidden in intel_bios.c?" I think we should trust what we parse from VBT everywhere except of course in intel_bios.c where we fixup when the VBT is wrong. Thoughts? Thanks Lucas De Marchi _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx