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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 9EB99C88E48 for ; Thu, 10 Sep 2026 14:24:05 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 129AE10F494; Thu, 10 Sep 2026 14:24:05 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="f8xdOdWV"; dkim-atps=neutral Received: from mail-wm2-f12.google.com (mail-wm2-f12.google.com [74.125.225.140]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3319B10F494 for ; Thu, 10 Sep 2026 12:04:32 +0000 (UTC) Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49b93204449so4106835e9.3 for ; Thu, 10 Sep 2026 05:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789041870; x=1789646670; darn=lists.freedesktop.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=csxrJaNJi4tIfZjrD+uNlOFumjNYljFKlQuyLO7kEBc=; b=f8xdOdWVZgS7Q5bXJKCa4wvAY7Owvwr/BPiS2XaBXCffoIVFhXMjxOd+oZ7xdBcNm0 28lmT18NhmxBPIhj5i3g/pgc1IhLRQtwrVc+d2+lKbA6+OonYBmF5pikam+asq/9iYQ6 qWa1EMiheNM6Q4ZWZir8MSgbtQkZaWb67d9X7A+Xrqv/8N7apjUJ3Hyqlccd09QxRJTS 9cteYcxF4QasMRPwZQ3jmauldYGKnvklBdFpP7GztmlVzqJ1Vmtu8fQqlPrZee1yUbad gUv7x0HJILARb7NtUzdRfTdpidFKWu/dHXyvLZC1bADP0DKzrb9Tn8Df47DZSeQDaO3H IBgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789041870; x=1789646670; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=csxrJaNJi4tIfZjrD+uNlOFumjNYljFKlQuyLO7kEBc=; b=HAMqiuSQlh0Ag02RI/A8LjWB4qaEE+7a5/f5KufDLoQL0sq0IQCZJYBKX9eeFbiP3y zZda6AM4sj6cz+00SRbKXV1+oeU3aoh2Bkl2hSM3ICkVqAfxTxDcP1Q2j9XvVip16dSJ J9IEtIw8W5u8ohGa2lxKdfB+FqjKR+leSPQM8B5Fju3NQ9Jwucs04+vKUHyT8+x22Klh rZauo1hihT+DDwxhpe7sFAPAlqsXoQvS2FxrL6UgSOs2fKISb8twZ8p41q+Ld1SqPoiI 8aa0sFdKJ1tw6hjFV+wjHIkOtv6e6f59tMo+7s/7HLjPwKAcaP1YZDz1wImDXmZu8e3p SZHg== X-Forwarded-Encrypted: i=1; AKwUvByb8y4lwFUljeZCV3YhhXEvzIOYDR7bAHrxQX+CNuvx0J2Mn4eywhY3rbYOcYfuhAwAqxuLYIIN5g==@lists.freedesktop.org X-Gm-Message-State: AFuF++mKS72ulssazVkL38oSN+ORHGmvKc4ez7pJGLePyYfjAep3iCtx EvJ66Mm7u2yjdvIHEthHMfrD6063+W6qBusZun94mK0v5Yf5IVwb3YM/ X-Gm-Gg: AYBFou2I4vVRU/qccMqcN6nbqHVUrHgnCDrljdo+ls6zFu05zOZ1hqgdAOrNALUVUvA e8mjUk1ComVAgni92P8HQns25wP1akk+aLwBPpdPGkLEz4PTbtjfrIJJxSgBYx5wNP5eE1APlOi /+4DjnRhyp1HemSTHGfxLdjGD3XJqRiyKI/NFnMptvv5PbtH+094s5f9KTfsaJS9fG2IQLk/Byw LNrLc9DygIBab/8Vj/ONlvFozFFLQtD5kAzNvR2VBzEhsdy2PHx/9zggX1nH/pzZgs4HSBXyD3D vuvJ9AFWoODakWfdhcgVKzCYEYzf0Va+nQkgvNChmR8NAoF+24o/+/kZLa52vIE0gXOYOSMNR6B u1CYPwnkQFDKX7ImX13xzsKAG41yLApW0dJyV2qNpWCmRl2ZcSvdkCIEVynRupA7d/mXvxf+LMF 4SsueDlfad+w18qsNd9aJ1LY9Vm4nfymNZVoyL62lI2hpVISM8iF+8wbMRTkZITM0GDw0qbStlg 7fLtD9EhCDRHcMD+fomVXLtYVt40DXvBsnNsH7Bi4XH8Aw9x8f+EIE4QwUobJtLyTd3bY+HVKaI 7OGs X-Received: by 2002:a05:600c:c494:b0:499:d95a:41f with SMTP id 5b1f17b1804b1-49d010c3969mr308061045e9.0.1789041870300; Thu, 10 Sep 2026 05:04:30 -0700 (PDT) Received: from OrangePi5-Plus.BB-HOME (20014C4E1B9146001C92980EE71198AB.dsl.pool.telekom.hu. [2001:4c4e:1b91:4600:1c92:980e:e711:98ab]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48591eb3d3bsm34529530f8f.0.2026.09.10.05.04.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2026 05:04:29 -0700 (PDT) From: Igor Paunovic To: Chaoyi Chen , Maxime Ripard , Cristian Ciocaltea Cc: Igor Paunovic , dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Dmitry Baryshkov , Laurent Pinchart , Andrzej Hajda , Neil Armstrong , Robert Foss , Jonas Karlman , Jernej Skrabec , Luca Ceresoli , Maarten Lankhorst , Thomas Zimmermann , David Airlie , Simona Vetter , Sandy Huang , Heiko Stuebner , Andy Yan , Sebastian Reichel , Jani Nikula , Rodrigo Vivi , Ville Syrjala , Imre Deak , Ankit Nautiyal Subject: Re: [PATCH v2 3/3] drm/rockchip: dw_dp: Attach "max bpc" connector property Date: Thu, 10 Sep 2026 14:04:06 +0200 Message-ID: <20260910120409.63850-1-royalnet026@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <388fd1ef-a8c9-4419-8bf2-10af7063e734@rock-chips.com> References: <388fd1ef-a8c9-4419-8bf2-10af7063e734@rock-chips.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 10 Sep 2026 14:24:03 +0000 X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" Hi Chaoyi, On 9/10/26 10:16, Chaoyi Chen wrote: > Maybe we should consider adding a new "DRM_BRIDGE_OP_DP" :) Works for me - it keeps the HDMI-only wording of max_bpc and makes the check explicit. So that Maxime and Cristian have something concrete to object to, this is all I would give the flag: - DRM_BRIDGE_OP_DP: the bridge drives a DisplayPort connector and fills in max_bpc. Nothing else is read from it for now. - drm_bridge_connector_init() treats it like DRM_BRIDGE_OP_HDMI: at most one such bridge in the chain (-EBUSY), max_bpc must be set (-EINVAL), and the connector gets "max bpc" with range 6..max_bpc. - dw-dp sets the flag and max_bpc = 10. The connector itself stays a plain drmm_connector_init() one - no DP counterpart of drmm_connector_hdmi_init() - so bridges without the flag see no change at all. > Perhaps @Cristian and @Maxime have better ideas? That is point 3, and I will wait for it before writing v3: whether the create-state block gets duplicated into the non-HDMI path or factored out of drmm_connector_hdmi_init(), and whether keeping the restore value in struct drm_bridge_connector is acceptable once 71/74 lands. Thanks, Igor