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 9FF4CC79FB9 for ; Thu, 10 Sep 2026 14:24:24 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 66E4A10F4B3; Thu, 10 Sep 2026 14:24:21 +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 2C29210F48B for ; Thu, 10 Sep 2026 12:04:32 +0000 (UTC) Received: by mail-wm2-f12.google.com with SMTP id 5b1f17b1804b1-49c5a927a1fso3235375e9.2 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=JgnyUUsOO00eoADFtu0YCCvsUmJcuaNV2WFVPIiqBsMMqD2wE5zTDREQGhE/2qb1oC yROfNfLWSB3J21z3+HBiiy5Z+eTQmfTtQo/iRpmsbz63Ok80tzbb8dHEN34WBV1vMRkl JKVYcQyl0lSrzlBSI1MA9X+Xvyxx+wvktE7shgfdx386tFxPwGXJYBSHp3ugM6XUvCDH lcuRrf/vWHP8RDACZcm0uaGhUkXKDCwe+l6kQpJH3MxlCwYanOS4fVGrgnYVWQ1ZAIeC dYoQ9uwtyitdvKC4qQ6PXYiQYY9InLp+VgzIDu65uut5fG3smMC8JFctQmVu03/grURv ADkQ== X-Forwarded-Encrypted: i=1; AKwUvBxjwzwb6ZEerNiNaOYlfY8YHU6cdwS0FKS27mqp4RHo+68gd98y7AqepVL5K2fjdYAiJ6kwCPeeH54=@lists.freedesktop.org X-Gm-Message-State: AFuF++mdLzTyV3xZZorNOuslGWK2DdqQfFU5N/gEABHp2MqNp1eBKPV7 QYb08ldSTwvqg+dFrm5LROXGlCfYrmNbK16YLlK73i+zafhi3whHucpD X-Gm-Gg: AYBFou3AbsBv5z1D0/wm1eaRnmTm0/0s5tnGGRDdLsDOcLkOc4tOI+/EW9LocpZQKCI oFiSq6PRgoZh2R7Qeob/ZIqm0hpRoUyQyTU3eFuRhcVENfFlNRlmA8+PxKkqlcltlp9V1c4jLt8 RYJEv0XKiztbrTRTT3pZ1r5cLuxpQYdHQx1o0gaPzYJ17CQPmsE29+bHgvUhyXqkwiBnpYOI58R u2mtYjJgZ8mmJj4R/5tD/8PCi8vqtgfs8Gyu3vkuj3/rRLLNYFhJtv9kzfym5EixOczL3jfCmC0 O+UlOAiASzWRREkkUyUjUv/oxFPevO18FlsVzz4V09SL54ecUGlWGMlyR10+KTgzBMsCsT6p5C3 cxDxg1C0GJSfvnmU2E5c0SYE20weFtrrhUyfeCmSqTSLrGJ9dhlu8sG4FFAmlTRCQK2gWXsr648 jJe0Tn88Ddqn1eBsNZCHpUG+3UsKOVuEQvcjstUlVC6gZ+bxy6rA4rGi937UCXloGSQdYP0GUNn IuY9r1vm1nKbmq8bBp60bZll65FZy6+ArxVaa0Fnqo/UgwXzd8zVGlTeGxOEB9SAzuWSeN53YZn JtdG 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:20 +0000 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: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" 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