From: Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
To: Sakari Ailus <sakari.ailus-X3B1VOXEql0@public.gmane.org>,
Boris Brezillon
<boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: Mauro Carvalho Chehab
<m.chehab-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Hans Verkuil
<hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>,
Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>,
linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Guennadi Liakhovetski
<g.liakhovetski-Mmb7MZpHnFY@public.gmane.org>
Subject: Re: [PATCH v2 01/10] [media] Move mediabus format definition to a more standard place
Date: Fri, 07 Nov 2014 14:10:28 +0100 [thread overview]
Message-ID: <545CC4C4.6080600@xs4all.nl> (raw)
In-Reply-To: <20141107114358.GB3136-S+BSfZ9RZZmRSg0ZkenSGLdO1Tsj/99ntUK59QYPAWc@public.gmane.org>
On 11/07/14 12:43, Sakari Ailus wrote:
> Hi Boris,
>
> Thank you for the update.
>
> On Thu, Nov 06, 2014 at 10:56:59AM +0100, Boris Brezillon wrote:
>> Rename mediabus formats and move the enum into a separate header file so
>> that it can be used by DRM/KMS subsystem without any reference to the V4L2
>> subsystem.
>>
>> Old v4l2_mbus_pixelcode now points to media_bus_format.
>>
>> Signed-off-by: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> Acked-by: Guennadi Liakhovetski <g.liakhovetski-Mmb7MZpHnFY@public.gmane.org>
>> ---
>> include/uapi/linux/Kbuild | 1 +
>> include/uapi/linux/media-bus-format.h | 131 ++++++++++++++++++++++++++++++++++
>> include/uapi/linux/v4l2-mediabus.h | 114 +----------------------------
>> 3 files changed, 134 insertions(+), 112 deletions(-)
>> create mode 100644 include/uapi/linux/media-bus-format.h
>>
>> diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
>> index b70237e..b2c23f8 100644
>> --- a/include/uapi/linux/Kbuild
>> +++ b/include/uapi/linux/Kbuild
>> @@ -414,6 +414,7 @@ header-y += veth.h
>> header-y += vfio.h
>> header-y += vhost.h
>> header-y += videodev2.h
>> +header-y += media-bus-format.h
>
> Could you arrange this to the list alphabetically, please?
>
>> header-y += virtio_9p.h
>> header-y += virtio_balloon.h
>> header-y += virtio_blk.h
>> diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h
>> new file mode 100644
>> index 0000000..251a902
>> --- /dev/null
>> +++ b/include/uapi/linux/media-bus-format.h
>> @@ -0,0 +1,131 @@
>> +/*
>> + * Media Bus API header
>> + *
>> + * Copyright (C) 2009, Guennadi Liakhovetski <g.liakhovetski-Mmb7MZpHnFY@public.gmane.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#ifndef __LINUX_MEDIA_BUS_FORMAT_H
>> +#define __LINUX_MEDIA_BUS_FORMAT_H
>> +
>> +/*
>> + * These bus formats uniquely identify data formats on the data bus. Format 0
>> + * is reserved, MEDIA_BUS_FMT_FIXED shall be used by host-client pairs, where
>> + * the data format is fixed. Additionally, "2X8" means that one pixel is
>> + * transferred in two 8-bit samples, "BE" or "LE" specify in which order those
>> + * samples are transferred over the bus: "LE" means that the least significant
>> + * bits are transferred first, "BE" means that the most significant bits are
>> + * transferred first, and "PADHI" and "PADLO" define which bits - low or high,
>> + * in the incomplete high byte, are filled with padding bits.
>> + *
>> + * The bus formats are grouped by type, bus_width, bits per component, samples
>> + * per pixel and order of subsamples. Numerical values are sorted using generic
>> + * numerical sort order (8 thus comes before 10).
>> + *
>> + * As their value can't change when a new bus format is inserted in the
>> + * enumeration, the bus formats are explicitly given a numerical value. The next
>> + * free values for each category are listed below, update them when inserting
>> + * new pixel codes.
>> + */
>> +
>> +#define MEDIA_BUS_FMT_ENTRY(name, val) \
>> + MEDIA_BUS_FMT_ ## name = val, \
>> + V4L2_MBUS_FMT_ ## name = val
>> +
>> +enum media_bus_format {
>
> There's no really a need to keep the definitions inside the enum. It looks a
> little bit confusing to me. That made me realise something I missed
> yesterday.
>
> There's a difference: the enum in C++ is a different thing than in C, and
> the enum type isn't able to contain any other values than those defined in
> the enumeration.
>
> So what I propose is the following. Keep enum v4l2_mbus_pixelcode around,
> including the enum values. Define new values for MEDIA_BUS_* equivalents
> using preprocessor macros, as you've done below. Drop the definition of enum
> media_bus_format, and use u32 (or uint32_t) type for the variables.
>
> This way the enum stays intact for existing C++ applications, and new
> applications will have to use a 32-bit type.
>
> I'd like to get an ok from Hans to this as well.
OK, let's do this. Let's keep enum v4l2_mbus_pixelcode but only under #ifndef
__KERNEL and with a comment that this enum is deprecated and frozen and that
the values from the new header should be used.
And make the new MEDIA_BUS_FMT_ values defines instead of an enum.
Regards,
Hans
WARNING: multiple messages have this Message-ID (diff)
From: hverkuil@xs4all.nl (Hans Verkuil)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 01/10] [media] Move mediabus format definition to a more standard place
Date: Fri, 07 Nov 2014 14:10:28 +0100 [thread overview]
Message-ID: <545CC4C4.6080600@xs4all.nl> (raw)
In-Reply-To: <20141107114358.GB3136@valkosipuli.retiisi.org.uk>
On 11/07/14 12:43, Sakari Ailus wrote:
> Hi Boris,
>
> Thank you for the update.
>
> On Thu, Nov 06, 2014 at 10:56:59AM +0100, Boris Brezillon wrote:
>> Rename mediabus formats and move the enum into a separate header file so
>> that it can be used by DRM/KMS subsystem without any reference to the V4L2
>> subsystem.
>>
>> Old v4l2_mbus_pixelcode now points to media_bus_format.
>>
>> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
>> Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>> ---
>> include/uapi/linux/Kbuild | 1 +
>> include/uapi/linux/media-bus-format.h | 131 ++++++++++++++++++++++++++++++++++
>> include/uapi/linux/v4l2-mediabus.h | 114 +----------------------------
>> 3 files changed, 134 insertions(+), 112 deletions(-)
>> create mode 100644 include/uapi/linux/media-bus-format.h
>>
>> diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
>> index b70237e..b2c23f8 100644
>> --- a/include/uapi/linux/Kbuild
>> +++ b/include/uapi/linux/Kbuild
>> @@ -414,6 +414,7 @@ header-y += veth.h
>> header-y += vfio.h
>> header-y += vhost.h
>> header-y += videodev2.h
>> +header-y += media-bus-format.h
>
> Could you arrange this to the list alphabetically, please?
>
>> header-y += virtio_9p.h
>> header-y += virtio_balloon.h
>> header-y += virtio_blk.h
>> diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h
>> new file mode 100644
>> index 0000000..251a902
>> --- /dev/null
>> +++ b/include/uapi/linux/media-bus-format.h
>> @@ -0,0 +1,131 @@
>> +/*
>> + * Media Bus API header
>> + *
>> + * Copyright (C) 2009, Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#ifndef __LINUX_MEDIA_BUS_FORMAT_H
>> +#define __LINUX_MEDIA_BUS_FORMAT_H
>> +
>> +/*
>> + * These bus formats uniquely identify data formats on the data bus. Format 0
>> + * is reserved, MEDIA_BUS_FMT_FIXED shall be used by host-client pairs, where
>> + * the data format is fixed. Additionally, "2X8" means that one pixel is
>> + * transferred in two 8-bit samples, "BE" or "LE" specify in which order those
>> + * samples are transferred over the bus: "LE" means that the least significant
>> + * bits are transferred first, "BE" means that the most significant bits are
>> + * transferred first, and "PADHI" and "PADLO" define which bits - low or high,
>> + * in the incomplete high byte, are filled with padding bits.
>> + *
>> + * The bus formats are grouped by type, bus_width, bits per component, samples
>> + * per pixel and order of subsamples. Numerical values are sorted using generic
>> + * numerical sort order (8 thus comes before 10).
>> + *
>> + * As their value can't change when a new bus format is inserted in the
>> + * enumeration, the bus formats are explicitly given a numerical value. The next
>> + * free values for each category are listed below, update them when inserting
>> + * new pixel codes.
>> + */
>> +
>> +#define MEDIA_BUS_FMT_ENTRY(name, val) \
>> + MEDIA_BUS_FMT_ ## name = val, \
>> + V4L2_MBUS_FMT_ ## name = val
>> +
>> +enum media_bus_format {
>
> There's no really a need to keep the definitions inside the enum. It looks a
> little bit confusing to me. That made me realise something I missed
> yesterday.
>
> There's a difference: the enum in C++ is a different thing than in C, and
> the enum type isn't able to contain any other values than those defined in
> the enumeration.
>
> So what I propose is the following. Keep enum v4l2_mbus_pixelcode around,
> including the enum values. Define new values for MEDIA_BUS_* equivalents
> using preprocessor macros, as you've done below. Drop the definition of enum
> media_bus_format, and use u32 (or uint32_t) type for the variables.
>
> This way the enum stays intact for existing C++ applications, and new
> applications will have to use a 32-bit type.
>
> I'd like to get an ok from Hans to this as well.
OK, let's do this. Let's keep enum v4l2_mbus_pixelcode but only under #ifndef
__KERNEL and with a comment that this enum is deprecated and frozen and that
the values from the new header should be used.
And make the new MEDIA_BUS_FMT_ values defines instead of an enum.
Regards,
Hans
WARNING: multiple messages have this Message-ID (diff)
From: Hans Verkuil <hverkuil@xs4all.nl>
To: Sakari Ailus <sakari.ailus@iki.fi>,
Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>,
Hans Verkuil <hans.verkuil@cisco.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
linux-media@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-api@vger.kernel.org,
devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org,
Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Subject: Re: [PATCH v2 01/10] [media] Move mediabus format definition to a more standard place
Date: Fri, 07 Nov 2014 14:10:28 +0100 [thread overview]
Message-ID: <545CC4C4.6080600@xs4all.nl> (raw)
In-Reply-To: <20141107114358.GB3136@valkosipuli.retiisi.org.uk>
On 11/07/14 12:43, Sakari Ailus wrote:
> Hi Boris,
>
> Thank you for the update.
>
> On Thu, Nov 06, 2014 at 10:56:59AM +0100, Boris Brezillon wrote:
>> Rename mediabus formats and move the enum into a separate header file so
>> that it can be used by DRM/KMS subsystem without any reference to the V4L2
>> subsystem.
>>
>> Old v4l2_mbus_pixelcode now points to media_bus_format.
>>
>> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
>> Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>> ---
>> include/uapi/linux/Kbuild | 1 +
>> include/uapi/linux/media-bus-format.h | 131 ++++++++++++++++++++++++++++++++++
>> include/uapi/linux/v4l2-mediabus.h | 114 +----------------------------
>> 3 files changed, 134 insertions(+), 112 deletions(-)
>> create mode 100644 include/uapi/linux/media-bus-format.h
>>
>> diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
>> index b70237e..b2c23f8 100644
>> --- a/include/uapi/linux/Kbuild
>> +++ b/include/uapi/linux/Kbuild
>> @@ -414,6 +414,7 @@ header-y += veth.h
>> header-y += vfio.h
>> header-y += vhost.h
>> header-y += videodev2.h
>> +header-y += media-bus-format.h
>
> Could you arrange this to the list alphabetically, please?
>
>> header-y += virtio_9p.h
>> header-y += virtio_balloon.h
>> header-y += virtio_blk.h
>> diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h
>> new file mode 100644
>> index 0000000..251a902
>> --- /dev/null
>> +++ b/include/uapi/linux/media-bus-format.h
>> @@ -0,0 +1,131 @@
>> +/*
>> + * Media Bus API header
>> + *
>> + * Copyright (C) 2009, Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#ifndef __LINUX_MEDIA_BUS_FORMAT_H
>> +#define __LINUX_MEDIA_BUS_FORMAT_H
>> +
>> +/*
>> + * These bus formats uniquely identify data formats on the data bus. Format 0
>> + * is reserved, MEDIA_BUS_FMT_FIXED shall be used by host-client pairs, where
>> + * the data format is fixed. Additionally, "2X8" means that one pixel is
>> + * transferred in two 8-bit samples, "BE" or "LE" specify in which order those
>> + * samples are transferred over the bus: "LE" means that the least significant
>> + * bits are transferred first, "BE" means that the most significant bits are
>> + * transferred first, and "PADHI" and "PADLO" define which bits - low or high,
>> + * in the incomplete high byte, are filled with padding bits.
>> + *
>> + * The bus formats are grouped by type, bus_width, bits per component, samples
>> + * per pixel and order of subsamples. Numerical values are sorted using generic
>> + * numerical sort order (8 thus comes before 10).
>> + *
>> + * As their value can't change when a new bus format is inserted in the
>> + * enumeration, the bus formats are explicitly given a numerical value. The next
>> + * free values for each category are listed below, update them when inserting
>> + * new pixel codes.
>> + */
>> +
>> +#define MEDIA_BUS_FMT_ENTRY(name, val) \
>> + MEDIA_BUS_FMT_ ## name = val, \
>> + V4L2_MBUS_FMT_ ## name = val
>> +
>> +enum media_bus_format {
>
> There's no really a need to keep the definitions inside the enum. It looks a
> little bit confusing to me. That made me realise something I missed
> yesterday.
>
> There's a difference: the enum in C++ is a different thing than in C, and
> the enum type isn't able to contain any other values than those defined in
> the enumeration.
>
> So what I propose is the following. Keep enum v4l2_mbus_pixelcode around,
> including the enum values. Define new values for MEDIA_BUS_* equivalents
> using preprocessor macros, as you've done below. Drop the definition of enum
> media_bus_format, and use u32 (or uint32_t) type for the variables.
>
> This way the enum stays intact for existing C++ applications, and new
> applications will have to use a 32-bit type.
>
> I'd like to get an ok from Hans to this as well.
OK, let's do this. Let's keep enum v4l2_mbus_pixelcode but only under #ifndef
__KERNEL and with a comment that this enum is deprecated and frozen and that
the values from the new header should be used.
And make the new MEDIA_BUS_FMT_ values defines instead of an enum.
Regards,
Hans
next prev parent reply other threads:[~2014-11-07 13:10 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-06 9:56 [PATCH v2 00/10] [media] Make mediabus format subsystem neutral Boris Brezillon
2014-11-06 9:56 ` Boris Brezillon
2014-11-06 9:56 ` Boris Brezillon
2014-11-06 9:56 ` [PATCH v2 01/10] [media] Move mediabus format definition to a more standard place Boris Brezillon
2014-11-06 9:56 ` Boris Brezillon
2014-11-06 9:56 ` Boris Brezillon
2014-11-07 11:43 ` Sakari Ailus
2014-11-07 11:43 ` Sakari Ailus
2014-11-07 11:43 ` Sakari Ailus
2014-11-07 11:50 ` Mauro Carvalho Chehab
2014-11-07 11:50 ` Mauro Carvalho Chehab
[not found] ` <20141107114358.GB3136-S+BSfZ9RZZmRSg0ZkenSGLdO1Tsj/99ntUK59QYPAWc@public.gmane.org>
2014-11-07 12:21 ` Boris Brezillon
2014-11-07 12:21 ` Boris Brezillon
2014-11-07 12:21 ` Boris Brezillon
2014-11-07 13:10 ` Hans Verkuil [this message]
2014-11-07 13:10 ` Hans Verkuil
2014-11-07 13:10 ` Hans Verkuil
2014-11-06 9:57 ` [PATCH v2 02/10] [media] v4l: Update subdev-formats doc with new MEDIA_BUS_FMT values Boris Brezillon
2014-11-06 9:57 ` Boris Brezillon
2014-11-06 9:57 ` Boris Brezillon
2014-11-06 9:57 ` [PATCH v2 03/10] [media] Make use of the new media_bus_format definitions Boris Brezillon
2014-11-06 9:57 ` Boris Brezillon
2014-11-06 9:57 ` Boris Brezillon
2014-11-06 9:57 ` [PATCH v2 04/10] [media] i2c: Make use of media_bus_format enum Boris Brezillon
2014-11-06 9:57 ` Boris Brezillon
[not found] ` <1415267829-4177-1-git-send-email-boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2014-11-06 9:57 ` [PATCH v2 05/10] [media] pci: " Boris Brezillon
2014-11-06 9:57 ` Boris Brezillon
2014-11-06 9:57 ` Boris Brezillon
2014-11-06 9:57 ` [PATCH v2 06/10] [media] platform: " Boris Brezillon
2014-11-06 9:57 ` [PATCH v2 07/10] [media] usb: " Boris Brezillon
2014-11-06 9:57 ` Boris Brezillon
2014-11-06 9:57 ` Boris Brezillon
2014-11-06 9:57 ` [PATCH v2 08/10] staging: media: " Boris Brezillon
2014-11-06 9:57 ` Boris Brezillon
2014-11-06 9:57 ` [PATCH v2 09/10] gpu: ipu-v3: " Boris Brezillon
2014-11-06 9:57 ` Boris Brezillon
2014-11-06 9:57 ` Boris Brezillon
2014-11-06 9:57 ` [PATCH v2 10/10] [media] v4l: Forbid usage of V4L2_MBUS_FMT definitions inside the kernel Boris Brezillon
2014-11-06 9:57 ` Boris Brezillon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=545CC4C4.6080600@xs4all.nl \
--to=hverkuil-qwit8jrvyhvmr6xm/wnwpw@public.gmane.org \
--cc=boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org \
--cc=devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b@public.gmane.org \
--cc=g.liakhovetski-Mmb7MZpHnFY@public.gmane.org \
--cc=hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org \
--cc=laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=m.chehab-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=sakari.ailus-X3B1VOXEql0@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.