From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7B4543D5647 for ; Wed, 8 Jul 2026 10:39:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.251.105.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783507160; cv=none; b=GHDTRgF+wvl2Bcooc0FcSe7M6h873CkvG44AFWNev/+JuQJN78NyE14mggMGdY1gRJp5OiwzE1JDZ1YKcAkEw1caLGjiGzqnrn8RbtDcrM8GNoVB4tHiCLuo6PC9C0F8WFGgKjBkmz7kT6k/3UAcN2PhTjDZlGkjGF2IMg/Kw3o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783507160; c=relaxed/simple; bh=iwFN7k1l7x6sZkU0ZQcIM16C6PmtP6fEROcDVf8SnW8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=FU86sD/pD23LXdbOqcOF1yRug+1eelEn99XhS9btBBbKdQBSxQWG5XUTujlETOfS0U7pB7tWCS6EsKL42yx3F8llNBfgKBUImIb8XJl64Wuh7zuVDfcIqqGXjh2bjvFRug6LnlGOkxhd4v2Y+64ZTT0mZDgDWF6ErAejh6kaypU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b=c7219e4r; arc=none smtp.client-ip=148.251.105.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=collabora.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=collabora.com header.i=@collabora.com header.b="c7219e4r" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1783507148; bh=iwFN7k1l7x6sZkU0ZQcIM16C6PmtP6fEROcDVf8SnW8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=c7219e4rWLH+NttiNekbwSuQ/urAUx9f7qHZWqWQ7lsm7kC/ZXj54eakGLwu6gPbB VIUX2fhwzzbK3xtqcH+hlfX4q+HYzLwZGYsFSQA6J+tcvYAedUDIzPr4q6N3O5OTTk ZEyuHF2rg7PKwJ/PLY2m1gvjg3vruEOHX7lpta7MIqqn9XIa58zeob2rv+6lh7dSgr SnZQQqyo9iHjNupsSDLsZfQGgIry09xpJ79KehJI9WoaaWGJqQQP+/k4HkYU2Bzb6r 3ySGC0lMVr5rX0iZnZAy1TxVbbOmzsmZIsxItdx147A+51rDaG7SkGMFujqsHxUtzw sRhpSAH+k7hJw== Received: from [100.64.0.241] (unknown [100.64.0.241]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519) (No client certificate requested) (Authenticated sender: cristicc) by bali.collaboradmins.com (Postfix) with ESMTPSA id 9200417E00F6; Wed, 08 Jul 2026 12:39:07 +0200 (CEST) Message-ID: <31117c25-5410-429a-887b-87c767387c58@collabora.com> Date: Wed, 8 Jul 2026 13:39:07 +0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 09/39] drm/display: hdmi-state-helper: Add fallback TMDS rate validation To: Maxime Ripard Cc: Maarten Lankhorst , Thomas Zimmermann , David Airlie , Simona Vetter , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Luca Ceresoli , Sandy Huang , =?UTF-8?Q?Heiko_St=C3=BCbner?= , Andy Yan , Daniel Stone , Dave Stevenson , =?UTF-8?Q?Ma=C3=ADra_Canal?= , Raspberry Pi Kernel Maintenance , kernel@collabora.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org References: <20260702-dw-hdmi-qp-scramb-v8-0-d79890d00b6a@collabora.com> <20260702-dw-hdmi-qp-scramb-v8-9-d79890d00b6a@collabora.com> <20260707-venomous-helpful-magpie-b2962b@penduick> Content-Language: en-US From: Cristian Ciocaltea In-Reply-To: <20260707-venomous-helpful-magpie-b2962b@penduick> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 7/7/26 2:23 PM, Maxime Ripard wrote: > Hi, > > On Thu, Jul 02, 2026 at 05:46:22PM +0300, Cristian Ciocaltea wrote: >> Validate the computed TMDS character rate against >> connector->hdmi.max_tmds_char_rate when no driver-specific >> tmds_char_rate_valid() hook is provided. >> >> This gives HDMI connectors a common fallback for rejecting modes whose >> TMDS character rate exceeds the connector limit, while still allowing >> drivers with custom validation requirements to implement their own >> tmds_char_rate_valid() callback. >> >> Signed-off-by: Cristian Ciocaltea >> --- >> drivers/gpu/drm/display/drm_hdmi_state_helper.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c b/drivers/gpu/drm/display/drm_hdmi_state_helper.c >> index ce17eeefc2da..db76699093e8 100644 >> --- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c >> +++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c >> @@ -566,6 +566,9 @@ hdmi_clock_valid(const struct drm_connector *connector, >> status = funcs->tmds_char_rate_valid(connector, mode, clock); >> if (status != MODE_OK) >> return status; >> + } else if (connector->hdmi.max_tmds_char_rate) { >> + if (clock > connector->hdmi.max_tmds_char_rate) >> + return MODE_CLOCK_HIGH; > > I think we should handle this the same way we do for > info->max_tmds_clock: if it's set, we always check that before calling > the driver. > > It reduces the boilerplate in drivers, and it's always a relevant check > anyway. Ack. Thanks, Cristian