From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sender4-pp-f112.zoho.com (sender4-pp-f112.zoho.com [136.143.188.112]) (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 01DB62744F for ; Wed, 25 Feb 2026 17:22:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=136.143.188.112 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772040174; cv=pass; b=MnFsk5VeInJvuLOEQvGrhQKVCSKYyRSxND6xU8ysCArJy0epLOxCWvvIt04NauMuY41C2Vq8mF7U+4akhPBXynP9hUw8tgB8XldKc/zYsT95bTFj7u/snZkQZx23WiwrkHyzEnnllndhityPK28fWeFPOcND91JWiBdp8u9RoaU= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772040174; c=relaxed/simple; bh=Us5j4M1BALetgvtC5RkmfEvLNdORRLEYAEiAeF4c/v4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Tr94x0a0f603Ifq80KfTdo0xyEgxBJ0J9idO5MezQUVoy5AQ9TkoGDZArFu9lr3gQK+M6Xu1iGjo4V1QiQkeSOII2Zv4tXHauQnK4JigxbOUllTYvkEdew7Krwmrr0TBTlwHPQXy+dxolF+PkiXqzv9azqJYrxg7bIRFQh67aFQ= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=collabora.com; spf=pass smtp.mailfrom=collabora.com; dkim=pass (1024-bit key) header.d=collabora.com header.i=nicolas.frattaroli@collabora.com header.b=ErAUL623; arc=pass smtp.client-ip=136.143.188.112 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 (1024-bit key) header.d=collabora.com header.i=nicolas.frattaroli@collabora.com header.b="ErAUL623" ARC-Seal: i=1; a=rsa-sha256; t=1772040118; cv=none; d=zohomail.com; s=zohoarc; b=MIpYrwNHTEw1tzZw977bIojdnx+74FWfwIXNhnMSYlTbsSYdvxH+g+QrY4zGMoh0X/3DZPjW1oer4HYTWBAn3lHZ9vLlIC3a8s4C7BO5iCugtzNhaFJrnUwkM4F1mExYqN8mBQfAqYu79QXEyyAM+uYUflDsTia6C1LizlG0obI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1772040118; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=uYQZEmr31PuQ1YWmsWAZzNu809ry9o0BpCJyD6e+hII=; b=DKXVLTbsR+l5XSAncNafwzlzKwZJFdTzPP+h8McRV7E6gSiuqKAo0gab2+6Otdbc1isGUCYTJhxZGjcI7vh1AKsaUvskimpYwdXSRNnYQtDyLKFoTUrS8qniU722QaJ0PXBYYRRWbog7c79LA+nOvzfEoo9YVcVTtTTZ1JP99N8= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=collabora.com; spf=pass smtp.mailfrom=nicolas.frattaroli@collabora.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1772040117; s=zohomail; d=collabora.com; i=nicolas.frattaroli@collabora.com; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-ID:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Reply-To; bh=uYQZEmr31PuQ1YWmsWAZzNu809ry9o0BpCJyD6e+hII=; b=ErAUL623uvHeppqsgHQm+m4bSxj92drF5CKI08sbgfF9ao4z5nFAf0OhjrZ2uhfe 0v2t1b+qb/J6N/g3FbcMj9+VjuVo7d9MRM3n8M4cbxm+P7AbP4Ia+AVf6vI7b8b0tHG 1mpKX6ssj7z59PMyMJjE6UKb4r8TkFnimhIKEEf0= Received: by mx.zohomail.com with SMTPS id 1772040115678826.0329473998504; Wed, 25 Feb 2026 09:21:55 -0800 (PST) From: Nicolas Frattaroli To: Jani Nikula , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Harry Wentland , Leo Li , Rodrigo Siqueira , Alex Deucher , Christian =?UTF-8?B?S8O2bmln?= , Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Andy Yan , Liviu Dudau , Chun-Kuang Hu , Philipp Zabel , Matthias Brugger , AngeloGioacchino Del Regno , Sandy Huang , Heiko =?UTF-8?B?U3TDvGJuZXI=?= , Liu Ying , Chen-Yu Tsai , Samuel Holland , Dave Stevenson , =?UTF-8?B?TWHDrXJh?= Canal , Raspberry Pi Kernel Maintenance , Maxime Ripard Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org, linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-sunxi@lists.linux.dev Subject: Re: [PATCH 14/14] drm/display: hdmi: Use drm_output_color_format instead of hdmi_colorspace Date: Wed, 25 Feb 2026 18:21:46 +0100 Message-ID: <3999997.iIbC2pHGDl@workhorse> In-Reply-To: <8234454.EvYhyI6sBW@workhorse> References: <20260224-drm-rework-color-formats-v1-0-bebc76604ada@kernel.org> <20260224-drm-rework-color-formats-v1-14-bebc76604ada@kernel.org> <8234454.EvYhyI6sBW@workhorse> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" On Wednesday, 25 February 2026 18:03:00 Central European Standard Time Nicolas Frattaroli wrote: > On Tuesday, 24 February 2026 11:58:53 Central European Standard Time Maxime Ripard wrote: > > The hdmi_colorspace enum was defined to represent the colorspace value > > of the HDMI infoframes. It was later used by some HDMI drivers to > > express the output format they should be setting up. > > > > During the introduction of the HDMI helpers, it then was used to > > represent it in the drm_connector_hdmi_state structure. > > > > However, it's always been somewhat redundant with the DRM_COLOR_FORMAT_* > > defines, and now with the drm_output_color_format enum. Let's > > consolidate around drm_output_color_format in drm_connector_hdmi_state > > to facilitate the current effort to provide a global output format > > selection mechanism. > > > > Signed-off-by: Maxime Ripard > > --- > > drivers/gpu/drm/bridge/inno-hdmi.c | 6 +- > > drivers/gpu/drm/bridge/ite-it6263.c | 2 +- > > drivers/gpu/drm/display/drm_hdmi_helper.c | 7 +- > > drivers/gpu/drm/display/drm_hdmi_state_helper.c | 52 ++++-- > > drivers/gpu/drm/drm_bridge.c | 2 +- > > drivers/gpu/drm/drm_connector.c | 14 +- > > drivers/gpu/drm/mediatek/mtk_hdmi_v2.c | 8 +- > > drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 2 +- > > drivers/gpu/drm/tests/drm_connector_test.c | 80 ++++----- > > drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 182 ++++++++++----------- > > drivers/gpu/drm/vc4/vc4_hdmi.c | 18 +- > > drivers/gpu/drm/vc4/vc4_hdmi.h | 2 +- > > include/drm/display/drm_hdmi_helper.h | 3 +- > > include/drm/drm_connector.h | 7 +- > > 14 files changed, 205 insertions(+), 180 deletions(-) > > > > [... snip ...] > > > > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c > > index 4f5b27fab475c7c733622eb8727927571f3fb8fe..171cd495976a3e16f201fd339d3d42a09dc3b63f 100644 > > --- a/drivers/gpu/drm/drm_connector.c > > +++ b/drivers/gpu/drm/drm_connector.c > > [... snip ...] > > > > @@ -1424,25 +1424,25 @@ drm_hdmi_connector_get_broadcast_rgb_name(enum drm_hdmi_broadcast_rgb broadcast_ > > return broadcast_rgb_names[broadcast_rgb].name; > > } > > EXPORT_SYMBOL(drm_hdmi_connector_get_broadcast_rgb_name); > > > > static const char * const output_format_str[] = { > > - [HDMI_COLORSPACE_RGB] = "RGB", > > - [HDMI_COLORSPACE_YUV420] = "YUV 4:2:0", > > - [HDMI_COLORSPACE_YUV422] = "YUV 4:2:2", > > - [HDMI_COLORSPACE_YUV444] = "YUV 4:4:4", > > + [DRM_OUTPUT_COLOR_FORMAT_RGB444] = "RGB", > > + [DRM_OUTPUT_COLOR_FORMAT_YCBCR420] = "YUV 4:2:0", > > + [DRM_OUTPUT_COLOR_FORMAT_YCBCR422] = "YUV 4:2:2", > > + [DRM_OUTPUT_COLOR_FORMAT_YCBCR444] = "YUV 4:4:4", > > }; > > > > /* > > * drm_hdmi_connector_get_output_format_name() - Return a string for HDMI connector output format > > * @fmt: Output format to compute name of > > * > > * Returns: the name of the output format, or NULL if the type is not > > * valid. > > */ > > const char * > > -drm_hdmi_connector_get_output_format_name(enum hdmi_colorspace fmt) > > +drm_hdmi_connector_get_output_format_name(enum drm_output_color_format fmt) > > { > > if (fmt >= ARRAY_SIZE(output_format_str)) > > return NULL; > > Almost unrelated nit: we might want to also `fmt < 0 ||` here, since the > base type of enums is a signed int. I almost caught myself using this function > as a way to quickly check if a supplied color format property from userspace > was valid, which would've had some unpleasant consequences for the kernel's > memory. > > Alternatively, I make my own switch-case based "is this a valid enum value" > function. I probably should do that actually, but my laziness lead me to > make sure we only have a single source of truth of what counts as a valid > enum value. Gah, disregard this, I just realised that this enum shouldn't be used as the one in the property anyway, because of AUTO, as you already pointed out in your reply to my series as well. > > > > > return output_format_str[fmt]; > > [... snip ...] > > Thanks for your work on this series, I was afraid of getting rid of > DRM_COLOR_FORMAT_* myself because I suspected it was going to be a > fairly large refactor across every driver. Guess I was both right > and wrong: it touches many files, but all the replacements are > fairly simple. :) > > Kind regards, > Nicolas Frattaroli