From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (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 AE5603033E0 for ; Wed, 28 Jan 2026 16:03:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769616237; cv=none; b=aolm2Qh/saTFD+MaeGbM0P80k2N120NdOgHPAxvK9Oa1cDSaO0g9liGw3gQAWq6KKPAFAQuS2QBt2ymCDYC6Kzexc4j4TzU4FD6Q+IXiU2Y/IyGOUVAI+6jfTwA3Ca2i1dBNgltIqH5XdbASG6i/J0NBcqrLGBnk010rgE3/bZk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769616237; c=relaxed/simple; bh=/l+fkLzjrklFZ0i1RoapoDTSccNdAgCq1C9onxCXPUI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=S6qas9BbJiWZqaC4VpLQMPpn5N9URyvQv2snlbxjYUmfz49/+7SsPVnoOQ3FS3XQWBwyk4OMVFqG8k/xH8easSYRjnSqwI58toam/Wyp77UwAcmPN6ERTfEm8mXid1JSe7LQhRfBWFOEVWhKqUnzpFUhsIsxIuMERfoT375mErM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=jWz80wZk; arc=none smtp.client-ip=213.167.242.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="jWz80wZk" Received: from killaraus.ideasonboard.com (2001-14ba-703d-e500--2a1.rev.dnainternet.fi [IPv6:2001:14ba:703d:e500::2a1]) by perceval.ideasonboard.com (Postfix) with UTF8SMTPSA id 7C7F5E70; Wed, 28 Jan 2026 17:03:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1769616196; bh=/l+fkLzjrklFZ0i1RoapoDTSccNdAgCq1C9onxCXPUI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jWz80wZkVyVjcMVDFtb72599YGWJ8D+DhKWIr5StTFcghYxGBAq1DwCR0z1BZp+us M0auBayLlpkiPA6lx8+n0sTn8PPPJ/7ESlZJIu4JmsfNr6KwAey3LATBAZZtWpl9Sg yOcvXahdHw+bSjr10akskxjqaXuKfTe+LNmSWR0c= Date: Wed, 28 Jan 2026 18:03:52 +0200 From: Laurent Pinchart To: Tomi Valkeinen Cc: Vishal Sagar , Anatoliy Klymenko , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Michal Simek , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Geert Uytterhoeven , Dmitry Baryshkov , Pekka Paalanen , Pekka Paalanen , Dmitry Baryshkov Subject: Re: [PATCH v7 03/11] drm/fourcc: Add DRM_FORMAT_Y8 Message-ID: <20260128160352.GA3225981@killaraus> References: <20251201-xilinx-formats-v7-0-1e1558adfefc@ideasonboard.com> <20251201-xilinx-formats-v7-3-1e1558adfefc@ideasonboard.com> <20260128114941.GF2558360@killaraus> <116b508e-0853-4b0b-966e-47d84167d4be@ideasonboard.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <116b508e-0853-4b0b-966e-47d84167d4be@ideasonboard.com> On Wed, Jan 28, 2026 at 05:38:11PM +0200, Tomi Valkeinen wrote: > On 28/01/2026 13:49, Laurent Pinchart wrote: > > On Mon, Dec 01, 2025 at 02:18:45PM +0200, Tomi Valkeinen wrote: > >> Add greyscale Y8 format. > > > > I would explain here why we need a new format and can't just use > > DRM_FORMAT_R8. You don't need to convince me, but I think it's important > > to summarize the rationale should someone later wonder why we introduced > > this. > > > >> Acked-by: Dmitry Baryshkov > >> Reviewed-by: Pekka Paalanen > >> Reviewed-by: Vishal Sagar > >> Signed-off-by: Tomi Valkeinen > >> --- > >> drivers/gpu/drm/drm_fourcc.c | 1 + > >> include/uapi/drm/drm_fourcc.h | 10 ++++++++++ > >> 2 files changed, 11 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c > >> index b22ef86428a1..a39b9d7a5b62 100644 > >> --- a/drivers/gpu/drm/drm_fourcc.c > >> +++ b/drivers/gpu/drm/drm_fourcc.c > >> @@ -275,6 +275,7 @@ const struct drm_format_info *__drm_format_info(u32 format) > >> { .format = DRM_FORMAT_YVU422, .depth = 0, .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 2, .vsub = 1, .is_yuv = true }, > >> { .format = DRM_FORMAT_YUV444, .depth = 0, .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 1, .vsub = 1, .is_yuv = true }, > >> { .format = DRM_FORMAT_YVU444, .depth = 0, .num_planes = 3, .cpp = { 1, 1, 1 }, .hsub = 1, .vsub = 1, .is_yuv = true }, > >> + { .format = DRM_FORMAT_Y8, .depth = 8, .num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true }, > >> { .format = DRM_FORMAT_NV12, .depth = 0, .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true }, > >> { .format = DRM_FORMAT_NV21, .depth = 0, .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true }, > >> { .format = DRM_FORMAT_NV16, .depth = 0, .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true }, > >> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h > >> index 6c786701238e..5cfc188c4e72 100644 > >> --- a/include/uapi/drm/drm_fourcc.h > >> +++ b/include/uapi/drm/drm_fourcc.h > >> @@ -459,6 +459,16 @@ extern "C" { > >> #define DRM_FORMAT_YUV444 fourcc_code('Y', 'U', '2', '4') /* non-subsampled Cb (1) and Cr (2) planes */ > >> #define DRM_FORMAT_YVU444 fourcc_code('Y', 'V', '2', '4') /* non-subsampled Cr (1) and Cb (2) planes */ > >> > >> +/* > >> + * Y-only (greyscale) formats > >> + * > >> + * The Y-only formats are handled similarly to the YCbCr formats in the display > >> + * pipeline, with the Cb and Cr implicitly neutral (0.0 in nominal values). This > >> + * also means that COLOR_RANGE property applies to the Y-only formats. > >> + * > > > > Extra blank line. > > I'll drop. > > >> + */ > >> + > >> +#define DRM_FORMAT_Y8 fourcc_code('G', 'R', 'E', 'Y') /* 8-bit Y-only */ > > > > I would have gone for 'Y', '8', ' ', ' ' > > Missed these comments earlier... > > Yes, "Y8 " makes sense. But I was trying to be nice, as there are > already users for Y8 ("GREY") with BSP kernels, and changing the fourcc > code would break their userspace... That's a more compeling argument than matching the V4L2 4CC. I have a slight preference for 'Y8 ' for how it would appear in debug messages, but I'm also fine being nice :-) Reviewed-by: Laurent Pinchart -- Regards, Laurent Pinchart