Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp456257img; Thu, 21 Mar 2019 01:41:38 -0700 (PDT) X-Google-Smtp-Source: APXvYqxmyF9pM3wnNxHZOzK9HudCjQXgzKI50oEM89Vw5bDOu8e3da+JZAKx0jcUaSbcvH6gL2Se X-Received: by 2002:a65:6559:: with SMTP id a25mr2068474pgw.99.1553157698337; Thu, 21 Mar 2019 01:41:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553157698; cv=none; d=google.com; s=arc-20160816; b=YQjqxYBuRsRXxS+ZZXst5UBRnfSZb+TIb6M/ZWriZn23o0KuiXJknF/Lqcsixy8Ki7 AXK6mmLtWwJhOaI49q8ycK6tezOaqQOkD1SvSxgcDcR0cBf769J4isuPATwK55lCeq8b yj0VpJHRP8og655lzCSQYsDre86rDsXqEDdr5lcBfWHTd9tVehi4dsMooLnZFVqK3pHm vlwV56wbGPGMH+gQWZM6z+jX/NRC4XFnPXhnEtOp/m6+TwdwN+fjb2uQH1bHYkl0m5pM 0fwWfY9P531TjG6pcH3vnT3x0FkMguHbU+ehYW6pDVOdfbDAoWjjBa6e6Ogg1KWbMgOO Gxpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=nZI72C+6Qy4c1jzxuOq/aThqY2JF5llYbI2m6RozYuA=; b=cA42KcG4UErUto2MgOASl+sY6rOACeEg1mZMkGN+4tFBIbcDqs3r8qEGSJmSpr4lfp BoSYhRaf1wxAWKj9/wjARn8WpFmbbhvyWRpBUCr1Rfujl/WVZthM+8qvbWJYVDPqcQpn LMiWpbyzytXJzaJVGJPiknHLD1/JiZ9f0quElEJvxeyPan952Ju2+vtpmFKG6Ju16BNM 7fLg3xCfqza+by2pL9nlMch2sSAI9fmg2ZkHrlklVeWPV247HFKj0of2GxuZ43lxufwo FZNn3rC8G/XhACi17w5kv7PZp1FY+s4FbnoFzZI3tZe+1WK8bnxj/lrysB6ruvCPYmvt h7Mw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g5si3631302pgc.122.2019.03.21.01.41.22; Thu, 21 Mar 2019 01:41:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728094AbfCUIkX (ORCPT + 99 others); Thu, 21 Mar 2019 04:40:23 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:48170 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727874AbfCUIkW (ORCPT ); Thu, 21 Mar 2019 04:40:22 -0400 Received: from localhost (unknown [IPv6:2a01:e0a:2c:6930:5cf4:84a1:2763:fe0d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: bbrezillon) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id EBC6227E23C; Thu, 21 Mar 2019 08:40:20 +0000 (GMT) Date: Thu, 21 Mar 2019 09:40:17 +0100 From: Boris Brezillon To: Maxime Ripard Cc: Daniel Vetter , David Airlie , Maarten Lankhorst , Sean Paul , Mauro Carvalho Chehab , Sakari Ailus , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Paul Kocialkowski , Hans Verkuil , Laurent Pinchart , Thomas Petazzoni , linux-media@vger.kernel.org Subject: Re: [RFC PATCH 06/20] lib: Add video format information library Message-ID: <20190321094017.62425776@collabora.com> In-Reply-To: <20190321082041.aswin5sgpejnx76t@flea> References: <20190320143944.10454b3b@collabora.com> <20190321082041.aswin5sgpejnx76t@flea> Organization: Collabora X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 21 Mar 2019 09:20:41 +0100 Maxime Ripard wrote: > Hi Boris, > > On Wed, Mar 20, 2019 at 02:39:44PM +0100, Boris Brezillon wrote: > > On Tue, 19 Mar 2019 22:57:11 +0100 > > Maxime Ripard wrote: > > > > > Move the DRM formats API to turn this into a more generic image formats API > > > to be able to leverage it into some other places of the kernel, such as > > > v4l2 drivers. > > > > > > Signed-off-by: Maxime Ripard > > > --- > > > include/linux/image-formats.h | 240 +++++++++++- > > > lib/Kconfig | 7 +- > > > lib/Makefile | 3 +- > > > lib/image-formats-selftests.c | 326 +++++++++++++++- > > > lib/image-formats.c | 760 +++++++++++++++++++++++++++++++++++- > > > 5 files changed, 1336 insertions(+) > > > create mode 100644 include/linux/image-formats.h > > > create mode 100644 lib/image-formats-selftests.c > > > create mode 100644 lib/image-formats.c > > > > > > > [...] > > > > > --- /dev/null > > > +++ b/lib/image-formats.c > > > @@ -0,0 +1,760 @@ > > > +#include > > > +#include > > > +#include > > > +#include > > > + > > > +#include > > > + > > > +static const struct image_format_info formats[] = { > > > + { > > > > ... > > > > > + }, > > > +}; > > > + > > > +#define __image_format_lookup(_field, _fmt) \ > > > + ({ \ > > > + const struct image_format_info *format = NULL; \ > > > + unsigned i; \ > > > + \ > > > + for (i = 0; i < ARRAY_SIZE(formats); i++) \ > > > + if (formats[i]._field == _fmt) \ > > > + format = &formats[i]; \ > > > + \ > > > + format; \ > > > + }) > > > + > > > +/** > > > + * __image_format_drm_lookup - query information for a given format > > > + * @drm: DRM fourcc pixel format (DRM_FORMAT_*) > > > + * > > > + * The caller should only pass a supported pixel format to this function. > > > + * > > > + * Returns: > > > + * The instance of struct image_format_info that describes the pixel format, or > > > + * NULL if the format is unsupported. > > > + */ > > > +const struct image_format_info *__image_format_drm_lookup(u32 drm) > > > +{ > > > + return __image_format_lookup(drm_fmt, drm); > > > +} > > > +EXPORT_SYMBOL(__image_format_drm_lookup); > > > + > > > +/** > > > + * image_format_drm_lookup - query information for a given format > > > + * @drm: DRM fourcc pixel format (DRM_FORMAT_*) > > > + * > > > + * The caller should only pass a supported pixel format to this function. > > > + * Unsupported pixel formats will generate a warning in the kernel log. > > > + * > > > + * Returns: > > > + * The instance of struct image_format_info that describes the pixel format, or > > > + * NULL if the format is unsupported. > > > + */ > > > +const struct image_format_info *image_format_drm_lookup(u32 drm) > > > +{ > > > + const struct image_format_info *format; > > > + > > > + format = __image_format_drm_lookup(drm); > > > + > > > + WARN_ON(!format); > > > + return format; > > > +} > > > +EXPORT_SYMBOL(image_format_drm_lookup); > > > > I think this function and the DRM formats table should be moved in > > drivers/gpu/drm/drm_image_format.c since they are DRM specific. The > > remaining functions can IMHO be placed in include/linux/image-formats.h > > as static inline funcs. This way you can get rid of lib/image-formats.c > > and the associated Kconfig entry. > > I'm not quite sure what you mean. The whole point of the series is to > split out that table out of DRM so that we can use it in other places, > so surely putting it back into DRM defeats the purpose? Sorry, I hadn't read the patch series entirely when replying to this email. I thought you were planning to create one table for DRM formats and one for V4L ones and then just use the common infra to have a generic image_format representation, hence my suggestion.