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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9FC5EC4167B for ; Tue, 20 Dec 2022 10:43:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233030AbiLTKnA (ORCPT ); Tue, 20 Dec 2022 05:43:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53564 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232513AbiLTKm7 (ORCPT ); Tue, 20 Dec 2022 05:42:59 -0500 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8D1DC1743E; Tue, 20 Dec 2022 02:42:58 -0800 (PST) Received: from pendragon.ideasonboard.com (213-243-189-158.bb.dnainternet.fi [213.243.189.158]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 85373706; Tue, 20 Dec 2022 11:42:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1671532976; bh=bK4txdnHUggupo5Doz/7+NZW7J4vreP6k+bN7etEXCg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FNt0pxC36qdgX77AE0cCoE8XbeEi5UynpACkHxQl9dKEl8ChmxuutYLTprMzrmxBP T2PpysNdQVR42GdEJ586Ya5TT5IEXAj0UCYzQF5gcybCRSqNGlvAwrNPa/VaFYErH7 U3WfzZG5xnnIk2P4dQMUML1KfnwAs5Exox44gKmc= Date: Tue, 20 Dec 2022 12:42:52 +0200 From: Laurent Pinchart To: Sakari Ailus Cc: Tomi Valkeinen , linux-renesas-soc@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, Kieran Bingham , Nicolas Dufresne , Geert Uytterhoeven , Hans Verkuil Subject: Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210) Message-ID: References: <20221219140139.294245-1-tomi.valkeinen+renesas@ideasonboard.com> <20221219140139.294245-8-tomi.valkeinen+renesas@ideasonboard.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Hi Sakari, On Tue, Dec 20, 2022 at 11:36:35AM +0200, Sakari Ailus wrote: > On Mon, Dec 19, 2022 at 11:47:04PM +0200, Laurent Pinchart wrote: > > On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote: > > > Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210. > > > > > > Signed-off-by: Tomi Valkeinen > > > --- > > > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++ > > > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++-- > > > 2 files changed, 71 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > > index 8c2719efda2a..8ccabf5a30c4 100644 > > > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > > @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = { > > > .bpp = 32, > > > .planes = 1, > > > .hsub = 1, > > > + }, { > > > + .fourcc = DRM_FORMAT_RGBX1010102, > > > > Ah, here the format makes sense. > > > > > + .v4l2 = V4L2_PIX_FMT_XBGR2101010, > > > > But this is horrible :-( Could we use the same names as DRM for new > > formats, when there is no conflict with existing V4L2 formats ? > > > > Sakari, Hans, what do you think ? Please see patch 1/7 in the series for > > the format definitions. > > I think it'd be good to have only one set of definitions. > > Can we can sort the endianness question in a reasonable way? It's really a matter of macro names only in this case, so it's "just" up to us to decide what we want to do. Hans' argument is that we would then depart from the general V4L2 rule, and thus create confusion, but I don't think there's such a clear cut rule in the first place and confusion is there already. Having common definitions for new formats would, I think, reduce confusion. > Also new Bayer formats will probably be still needed on V4L2 side but will > they be relevant for DRM? I suppose that would mean new DRM format for > each pixel order, too? Or can we think of something smarter that would > still work reasonably with existing formats? We use DRM 4CCs in the libcamera public API, and the DRM maintainers have agreed to add DRM 4CCs for formats that are used by cameras only, such as MJPEG for instance, that's hardly useful for displays. The same holds true for Bayer formats, and we use DRM modifiers to specify the packing instead of defining different 4CCs. I'd like to do something similar for the Bayer pattern, although specifying it out-of-band may be even better. -- Regards, Laurent Pinchart 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 9EEAAC4332F for ; Tue, 20 Dec 2022 10:44:21 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E9ED210E39D; Tue, 20 Dec 2022 10:44:19 +0000 (UTC) Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) by gabe.freedesktop.org (Postfix) with ESMTPS id 36E5F10E39D for ; Tue, 20 Dec 2022 10:42:58 +0000 (UTC) Received: from pendragon.ideasonboard.com (213-243-189-158.bb.dnainternet.fi [213.243.189.158]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 85373706; Tue, 20 Dec 2022 11:42:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1671532976; bh=bK4txdnHUggupo5Doz/7+NZW7J4vreP6k+bN7etEXCg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FNt0pxC36qdgX77AE0cCoE8XbeEi5UynpACkHxQl9dKEl8ChmxuutYLTprMzrmxBP T2PpysNdQVR42GdEJ586Ya5TT5IEXAj0UCYzQF5gcybCRSqNGlvAwrNPa/VaFYErH7 U3WfzZG5xnnIk2P4dQMUML1KfnwAs5Exox44gKmc= Date: Tue, 20 Dec 2022 12:42:52 +0200 From: Laurent Pinchart To: Sakari Ailus Subject: Re: [PATCH v2 7/7] drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210) Message-ID: References: <20221219140139.294245-1-tomi.valkeinen+renesas@ideasonboard.com> <20221219140139.294245-8-tomi.valkeinen+renesas@ideasonboard.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kieran Bingham , dri-devel@lists.freedesktop.org, Nicolas Dufresne , linux-renesas-soc@vger.kernel.org, Geert Uytterhoeven , Tomi Valkeinen , Hans Verkuil , linux-media@vger.kernel.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Sakari, On Tue, Dec 20, 2022 at 11:36:35AM +0200, Sakari Ailus wrote: > On Mon, Dec 19, 2022 at 11:47:04PM +0200, Laurent Pinchart wrote: > > On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote: > > > Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210. > > > > > > Signed-off-by: Tomi Valkeinen > > > --- > > > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++ > > > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++-- > > > 2 files changed, 71 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > > index 8c2719efda2a..8ccabf5a30c4 100644 > > > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > > @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = { > > > .bpp = 32, > > > .planes = 1, > > > .hsub = 1, > > > + }, { > > > + .fourcc = DRM_FORMAT_RGBX1010102, > > > > Ah, here the format makes sense. > > > > > + .v4l2 = V4L2_PIX_FMT_XBGR2101010, > > > > But this is horrible :-( Could we use the same names as DRM for new > > formats, when there is no conflict with existing V4L2 formats ? > > > > Sakari, Hans, what do you think ? Please see patch 1/7 in the series for > > the format definitions. > > I think it'd be good to have only one set of definitions. > > Can we can sort the endianness question in a reasonable way? It's really a matter of macro names only in this case, so it's "just" up to us to decide what we want to do. Hans' argument is that we would then depart from the general V4L2 rule, and thus create confusion, but I don't think there's such a clear cut rule in the first place and confusion is there already. Having common definitions for new formats would, I think, reduce confusion. > Also new Bayer formats will probably be still needed on V4L2 side but will > they be relevant for DRM? I suppose that would mean new DRM format for > each pixel order, too? Or can we think of something smarter that would > still work reasonably with existing formats? We use DRM 4CCs in the libcamera public API, and the DRM maintainers have agreed to add DRM 4CCs for formats that are used by cameras only, such as MJPEG for instance, that's hardly useful for displays. The same holds true for Bayer formats, and we use DRM modifiers to specify the packing instead of defining different 4CCs. I'd like to do something similar for the Bayer pattern, although specifying it out-of-band may be even better. -- Regards, Laurent Pinchart