Received: by 2002:a05:7412:8521:b0:e2:908c:2ebd with SMTP id t33csp2037898rdf; Mon, 6 Nov 2023 02:59:59 -0800 (PST) X-Google-Smtp-Source: AGHT+IG3mVd9ckzk/Gz+Jg6GWEKF4cOLst+8N+MqxjzrDVCvNdYt6VsnNaKK1fsCAylk5CKmoYtv X-Received: by 2002:a05:6a20:12c1:b0:16a:4f24:d30 with SMTP id v1-20020a056a2012c100b0016a4f240d30mr36850195pzg.53.1699268399491; Mon, 06 Nov 2023 02:59:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699268399; cv=none; d=google.com; s=arc-20160816; b=vdVKDS10LrzX9+0F1YbWn35pjgpttUGTOibJR423+BE/YKS4bIHEnXp0smoU80zUbD RavOF9ikV5AfzE1Keao9RXgL/FvAT//LfMaIc1xJDaWixh9h9cVjhuk2yaq/dDBATNVL xLDdCMPFJjYS3KbcXvKjO5137QItDF3COxKg/agZjtYdBBiXopY+/Q7yg+GBfZa5rzwX QSSO7nYZNQ/AeSk2XGjKRqn218O7n+3W0mK/8EHVpKlO6/356EixjKVSvFXWAJuf3hv7 c3DWmYv09NFMwBi6jNBJ5lxkpyx8b+/sJZfdDArgi3TU3XQ+X/ycnMXxsBFTDKvERdI1 jbaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:references:organization:in-reply-to:subject:cc:to :from:dkim-signature; bh=ksxX8ZB2iKJNhHr74r8TAgFTpDQHldOBy0SCsgxL9iI=; fh=w48e6rwVp1PJQX9r49sjyiSiEGW8PdFzSi+UgpndM/g=; b=Kb3Ab2MCfQA089CA0vGdfKO3ESNVAFprflxGytzqx6npriyDrIp79aAlfYN+jnbK0a zb3IUAEPQsB2fMgxt3eFPuMlRb6FgGyIUSTL7cKjg8UCRCGZDiLEc5Rb5YWDgvzLYsCa GunMPJ5AmeMsaOXtNh9ii7jJKTc1Ubj21IORnEvCxy2PJMRWufvkppDqMEgkW6Uc9Wem YIxo5u4bQtgRMkMdPIjUUmNWlwA9rS7JtMFDMIcI6ssjzZ6w3AXULTKNQRgD3lDupxuE vf/pvwm2BOFIQX4r52Wx3UsIr1+MBt9j20ElDHMxCAZM/A3kKw7hcknp6wc5NNzyn5QP 17uw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ROFre+cG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id g132-20020a636b8a000000b005bd0f2f41ddsi7436915pgc.206.2023.11.06.02.59.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Nov 2023 02:59:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ROFre+cG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 378C7802AF04; Mon, 6 Nov 2023 02:59:58 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230284AbjKFK7y (ORCPT + 99 others); Mon, 6 Nov 2023 05:59:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55944 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231243AbjKFK7x (ORCPT ); Mon, 6 Nov 2023 05:59:53 -0500 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7F1D0C6 for ; Mon, 6 Nov 2023 02:59:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1699268390; x=1730804390; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=ksxX8ZB2iKJNhHr74r8TAgFTpDQHldOBy0SCsgxL9iI=; b=ROFre+cG9KJTiNNt7QencBPIb1TZsV8tdiXbxCvig60j8C2vEQjPmDR9 OZsGeTHNbNRxuVHPGNPEXaklxh4nrxvLv0TRcxSUdbrbyPdjdNsMxw3eL LBsJpm4fDtTOZ5rXmF5EjJatVHo/IUyhbJ2P6iZIVlhPgkMb20iyJd9P1 qaBcF7eg+gEEeFPaVPoNjo5oRgQCpj09v8VZGIoMVs/sJGHPijfakIBEw 8MQ/O4cJIlwNzZsjZe3jTVLFIungJ67euaacy90gbq3dfqeSX3wsARRaP 9rk7lvZ10JKNB/0ig5zEzXm/TremMiZrt+M6AsMSgEjZ60BsREDC2gpzj w==; X-IronPort-AV: E=McAfee;i="6600,9927,10885"; a="455735079" X-IronPort-AV: E=Sophos;i="6.03,281,1694761200"; d="scan'208";a="455735079" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Nov 2023 02:59:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10885"; a="755817188" X-IronPort-AV: E=Sophos;i="6.03,281,1694761200"; d="scan'208";a="755817188" Received: from lpilolli-mobl.ger.corp.intel.com (HELO localhost) ([10.252.36.222]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Nov 2023 02:59:46 -0800 From: Jani Nikula To: Maxime Ripard , Doug Anderson Cc: Neil Armstrong , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Thomas Zimmermann , Hsin-Yi Wang , Dmitry Baryshkov , Jessica Zhang , Sam Ravnborg Subject: Re: [PATCH 3/3] drm/panel-edp: Choose correct preferred mode In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20231101212604.1636517-1-hsinyi@chromium.org> <20231101212604.1636517-4-hsinyi@chromium.org> Date: Mon, 06 Nov 2023 12:59:43 +0200 Message-ID: <87v8afywo0.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Mon, 06 Nov 2023 02:59:58 -0800 (PST) On Mon, 06 Nov 2023, Maxime Ripard wrote: > On Thu, Nov 02, 2023 at 07:33:48AM -0700, Doug Anderson wrote: >> Hi, >>=20 >> On Wed, Nov 1, 2023 at 11:31=E2=80=AFPM Dmitry Baryshkov >> wrote: >> > >> > On Wed, 1 Nov 2023 at 23:26, Hsin-Yi Wang wrote: >> > > >> > > If a non generic edp-panel is under aux-bus, the mode read from edid= would >> > > still be selected as preferred and results in multiple preferred mod= es, >> > > which is ambiguous. >> > > >> > > If a hard-coded mode is present, unset the preferred bit of the mode= s read >> > > from edid. >> > >> > Can we skip the EDID completely if the hardcoded override is present? >>=20 >> Yeah, I wondered about that too. The blending of the hardcoded with >> the EDID predates my involvement with the driver. You can see even as >> of commit 280921de7241 ("drm/panel: Add simple panel support") that >> the driver would start with the EDID modes (if it had them) and then >> go onto add the hardcoded modes. At least for eDP panels, though, >> nobody (or almost nobody?) actually provided panel-simple a DDC bus at >> the same time it was given a hardcoded panel. >>=20 >> I guess I could go either way, but I have a slight bias to adding the >> extra modes and just making it clear to userspace that none of them >> are "preferred". That seems like it would give userspace the most >> flexibility > > I disagree. "Flexibility" here just means "the way to shoot itself in > the foot without knowing it's aiming at its foot". > > If a mode is broken, we shouldn't expose it, just like we don't for all > modes that require a maximum frequency higher than what the controller > can provide on HDMI for example. Agreed. This is exactly what the ->mode_valid connector helper callback is for. > >> and also is closer to what we've historically done (though, >> historically, we just allowed there to be more than one "preferred" >> mode). > > I have no idea what history you're referring to here > >> One thing we definitely want to do, though, is to still expose the >> EDID to userspace even if we're using a hardcoded mode. I believe >> that, at least on ChromeOS, there are some tools that look at the EDID >> directly for some reason or another. > > If the EDID is known to be broken and unreliable, what's the point? I don't think it's unheard of to have bogus modes in the EDID while other stuff is required. I think the current agreement pretty much is that the kernel handles the modes, either from the EDID or some other channel, and the userspace does not look at the EDID for modes. BR, Jani. --=20 Jani Nikula, Intel