[PATCH 0/2] Add pixel format for 10 bits YUV video

[PATCH 0/2] Add pixel format for 10 bits YUV video

[Randy Li]

Those pixel formats comes from Gstreamer and ffmpeg. Currently,
the VOP(video output mixer) found on RK3288 and future support
those pixel formats are input. Also the decoder on RK3288
could use them as output.

Randy Li (2):
  drm_fourcc: Add new P010 video format
  [media] v4l: Add 10-bits per channel YUV pixel formats

 include/uapi/drm/drm_fourcc.h  | 1 +
 include/uapi/linux/videodev2.h | 2 ++
 2 files changed, 3 insertions(+)

-- 
2.7.4

[PATCH 1/2] drm_fourcc: Add new P010 video format

[Randy Li]

P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
per channel video format. Rockchip's vop support this
video format(little endian only) as the input video format.

Signed-off-by: Randy Li <ayaka@soulik.info>
---
 include/uapi/drm/drm_fourcc.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 9e1bb7f..d2721da 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -119,6 +119,7 @@ extern "C" {
 #define DRM_FORMAT_NV61		fourcc_code('N', 'V', '6', '1') /* 2x1 subsampled Cb:Cr plane */
 #define DRM_FORMAT_NV24		fourcc_code('N', 'V', '2', '4') /* non-subsampled Cr:Cb plane */
 #define DRM_FORMAT_NV42		fourcc_code('N', 'V', '4', '2') /* non-subsampled Cb:Cr plane */
+#define DRM_FORMAT_P010		fourcc_code('P', '0', '1', '0') /* 2x2 subsampled Cr:Cb plane 10 bits per channel */
 
 /*
  * 3 plane YCbCr
-- 
2.7.4

[PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats

[Randy Li]

The formats added by this patch are:
	V4L2_PIX_FMT_P010
	V4L2_PIX_FMT_P010M
Currently, none of driver uses those format, but some video device
has been confirmed with could as those format for video output.
The Rockchip's new decoder has supported those format for profile_10
HEVC/AVC video.

Signed-off-by: Randy Li <ayaka@soulik.info>
---
 include/uapi/linux/videodev2.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 46e8a2e3..9e03f20 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -551,6 +551,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_NV61    v4l2_fourcc('N', 'V', '6', '1') /* 16  Y/CrCb 4:2:2  */
 #define V4L2_PIX_FMT_NV24    v4l2_fourcc('N', 'V', '2', '4') /* 24  Y/CbCr 4:4:4  */
 #define V4L2_PIX_FMT_NV42    v4l2_fourcc('N', 'V', '4', '2') /* 24  Y/CrCb 4:4:4  */
+#define V4L2_PIX_FMT_P010    v4l2_fourcc('P', '0', '1', '0') /* 15  Y/CbCr 4:2:0, 10 bits per channel */
 
 /* two non contiguous planes - one Y, one Cr + Cb interleaved  */
 #define V4L2_PIX_FMT_NV12M   v4l2_fourcc('N', 'M', '1', '2') /* 12  Y/CbCr 4:2:0  */
@@ -559,6 +560,7 @@ struct v4l2_pix_format {
 #define V4L2_PIX_FMT_NV61M   v4l2_fourcc('N', 'M', '6', '1') /* 16  Y/CrCb 4:2:2  */
 #define V4L2_PIX_FMT_NV12MT  v4l2_fourcc('T', 'M', '1', '2') /* 12  Y/CbCr 4:2:0 64x32 macroblocks */
 #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12  Y/CbCr 4:2:0 16x16 macroblocks */
+#define V4L2_PIX_FMT_P010M   v4l2_fourcc('P', 'M', '1', '0') /* 15  Y/CbCr 4:2:0, 10 bits per channel */
 
 /* three planes - Y Cb, Cr */
 #define V4L2_PIX_FMT_YUV410  v4l2_fourcc('Y', 'U', 'V', '9') /*  9  YUV 4:1:0     */
-- 
2.7.4

Re: [PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats

[Sakari Ailus]

Hi Randy,

Thanks for the patch.

On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:
> The formats added by this patch are:
> 	V4L2_PIX_FMT_P010
> 	V4L2_PIX_FMT_P010M
> Currently, none of driver uses those format, but some video device
> has been confirmed with could as those format for video output.
> The Rockchip's new decoder has supported those format for profile_10
> HEVC/AVC video.
> 
> Signed-off-by: Randy Li <ayaka@soulik.info>

If the format resembles the existing formats but on a different bit depth,
it should be named in similar fashion.

Could you also add ReST documentation for the format, please?

The common requirement for merging patches that change interfaces has been
that there's a user for that change. It'll still help you to get this
reviewed now so the interface that the future hopefully-in-mainline driver
provides will not change.

> ---
>  include/uapi/linux/videodev2.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 46e8a2e3..9e03f20 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -551,6 +551,7 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_NV61    v4l2_fourcc('N', 'V', '6', '1') /* 16  Y/CrCb 4:2:2  */
>  #define V4L2_PIX_FMT_NV24    v4l2_fourcc('N', 'V', '2', '4') /* 24  Y/CbCr 4:4:4  */
>  #define V4L2_PIX_FMT_NV42    v4l2_fourcc('N', 'V', '4', '2') /* 24  Y/CrCb 4:4:4  */
> +#define V4L2_PIX_FMT_P010    v4l2_fourcc('P', '0', '1', '0') /* 15  Y/CbCr 4:2:0, 10 bits per channel */
>  
>  /* two non contiguous planes - one Y, one Cr + Cb interleaved  */
>  #define V4L2_PIX_FMT_NV12M   v4l2_fourcc('N', 'M', '1', '2') /* 12  Y/CbCr 4:2:0  */
> @@ -559,6 +560,7 @@ struct v4l2_pix_format {
>  #define V4L2_PIX_FMT_NV61M   v4l2_fourcc('N', 'M', '6', '1') /* 16  Y/CrCb 4:2:2  */
>  #define V4L2_PIX_FMT_NV12MT  v4l2_fourcc('T', 'M', '1', '2') /* 12  Y/CbCr 4:2:0 64x32 macroblocks */
>  #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12  Y/CbCr 4:2:0 16x16 macroblocks */
> +#define V4L2_PIX_FMT_P010M   v4l2_fourcc('P', 'M', '1', '0') /* 15  Y/CbCr 4:2:0, 10 bits per channel */
>  
>  /* three planes - Y Cb, Cr */
>  #define V4L2_PIX_FMT_YUV410  v4l2_fourcc('Y', 'U', 'V', '9') /*  9  YUV 4:1:0     */

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

Re: [PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats

[ayaka]

On 01/02/2017 05:10 PM, Sakari Ailus wrote:
> Hi Randy,
>
> Thanks for the patch.
>
> On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:
>> The formats added by this patch are:
>> 	V4L2_PIX_FMT_P010
>> 	V4L2_PIX_FMT_P010M
>> Currently, none of driver uses those format, but some video device
>> has been confirmed with could as those format for video output.
>> The Rockchip's new decoder has supported those format for profile_10
>> HEVC/AVC video.
>>
>> Signed-off-by: Randy Li <ayaka@soulik.info>
> If the format resembles the existing formats but on a different bit depth,
> it should be named in similar fashion.
Do you mean it would be better if it is called as NV12_10?
>
> Could you also add ReST documentation for the format, please?
I will.
>
> The common requirement for merging patches that change interfaces has been
> that there's a user for that change. It'll still help you to get this
The kernel used in rockchip has supported that format in drm driver, but 
just we don't have a agreement about the pixel format. As the Gstreamer 
and some others would call it with a P010_ prefix, but Mark(rockchip's 
drm author) prefer the something like NV12_10, that is why I sent out 
those patches, I want the upstream decided its final name.
> reviewed now so the interface that the future hopefully-in-mainline driver
> provides will not change.
>
>> ---
>>   include/uapi/linux/videodev2.h | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>> index 46e8a2e3..9e03f20 100644
>> --- a/include/uapi/linux/videodev2.h
>> +++ b/include/uapi/linux/videodev2.h
>> @@ -551,6 +551,7 @@ struct v4l2_pix_format {
>>   #define V4L2_PIX_FMT_NV61    v4l2_fourcc('N', 'V', '6', '1') /* 16  Y/CrCb 4:2:2  */
>>   #define V4L2_PIX_FMT_NV24    v4l2_fourcc('N', 'V', '2', '4') /* 24  Y/CbCr 4:4:4  */
>>   #define V4L2_PIX_FMT_NV42    v4l2_fourcc('N', 'V', '4', '2') /* 24  Y/CrCb 4:4:4  */
>> +#define V4L2_PIX_FMT_P010    v4l2_fourcc('P', '0', '1', '0') /* 15  Y/CbCr 4:2:0, 10 bits per channel */
>>   
>>   /* two non contiguous planes - one Y, one Cr + Cb interleaved  */
>>   #define V4L2_PIX_FMT_NV12M   v4l2_fourcc('N', 'M', '1', '2') /* 12  Y/CbCr 4:2:0  */
>> @@ -559,6 +560,7 @@ struct v4l2_pix_format {
>>   #define V4L2_PIX_FMT_NV61M   v4l2_fourcc('N', 'M', '6', '1') /* 16  Y/CrCb 4:2:2  */
>>   #define V4L2_PIX_FMT_NV12MT  v4l2_fourcc('T', 'M', '1', '2') /* 12  Y/CbCr 4:2:0 64x32 macroblocks */
>>   #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12  Y/CbCr 4:2:0 16x16 macroblocks */
>> +#define V4L2_PIX_FMT_P010M   v4l2_fourcc('P', 'M', '1', '0') /* 15  Y/CbCr 4:2:0, 10 bits per channel */
>>   
>>   /* three planes - Y Cb, Cr */
>>   #define V4L2_PIX_FMT_YUV410  v4l2_fourcc('Y', 'U', 'V', '9') /*  9  YUV 4:1:0     */

Re: [PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats

[Sakari Ailus]

Hi,

On Mon, Jan 02, 2017 at 06:53:16PM +0800, ayaka wrote:
> 
> 
> On 01/02/2017 05:10 PM, Sakari Ailus wrote:
> >Hi Randy,
> >
> >Thanks for the patch.
> >
> >On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:
> >>The formats added by this patch are:
> >>	V4L2_PIX_FMT_P010
> >>	V4L2_PIX_FMT_P010M
> >>Currently, none of driver uses those format, but some video device
> >>has been confirmed with could as those format for video output.
> >>The Rockchip's new decoder has supported those format for profile_10
> >>HEVC/AVC video.
> >>
> >>Signed-off-by: Randy Li <ayaka@soulik.info>
> >If the format resembles the existing formats but on a different bit depth,
> >it should be named in similar fashion.
> Do you mean it would be better if it is called as NV12_10?

If it otherwise resembles NV12 but just has 10 bits per pixel, I think
NV12_10 is a good name for it.

> >
> >Could you also add ReST documentation for the format, please?
> I will.
> >
> >The common requirement for merging patches that change interfaces has been
> >that there's a user for that change. It'll still help you to get this
> The kernel used in rockchip has supported that format in drm driver, but
> just we don't have a agreement about the pixel format. As the Gstreamer and
> some others would call it with a P010_ prefix, but Mark(rockchip's drm
> author) prefer the something like NV12_10, that is why I sent out those
> patches, I want the upstream decided its final name.

Ack.

I think we haven't really tried to unify the format naming in the past
between the two subsystems. If existing conventions exist on both regarding
this format, then it's probably better to follow those.

Cc Laurent as well.

> >reviewed now so the interface that the future hopefully-in-mainline driver
> >provides will not change.
> >
> >>---
> >>  include/uapi/linux/videodev2.h | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >>diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> >>index 46e8a2e3..9e03f20 100644
> >>--- a/include/uapi/linux/videodev2.h
> >>+++ b/include/uapi/linux/videodev2.h
> >>@@ -551,6 +551,7 @@ struct v4l2_pix_format {
> >>  #define V4L2_PIX_FMT_NV61    v4l2_fourcc('N', 'V', '6', '1') /* 16  Y/CrCb 4:2:2  */
> >>  #define V4L2_PIX_FMT_NV24    v4l2_fourcc('N', 'V', '2', '4') /* 24  Y/CbCr 4:4:4  */
> >>  #define V4L2_PIX_FMT_NV42    v4l2_fourcc('N', 'V', '4', '2') /* 24  Y/CrCb 4:4:4  */
> >>+#define V4L2_PIX_FMT_P010    v4l2_fourcc('P', '0', '1', '0') /* 15  Y/CbCr 4:2:0, 10 bits per channel */
> >>  /* two non contiguous planes - one Y, one Cr + Cb interleaved  */
> >>  #define V4L2_PIX_FMT_NV12M   v4l2_fourcc('N', 'M', '1', '2') /* 12  Y/CbCr 4:2:0  */
> >>@@ -559,6 +560,7 @@ struct v4l2_pix_format {
> >>  #define V4L2_PIX_FMT_NV61M   v4l2_fourcc('N', 'M', '6', '1') /* 16  Y/CrCb 4:2:2  */
> >>  #define V4L2_PIX_FMT_NV12MT  v4l2_fourcc('T', 'M', '1', '2') /* 12  Y/CbCr 4:2:0 64x32 macroblocks */
> >>  #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12  Y/CbCr 4:2:0 16x16 macroblocks */
> >>+#define V4L2_PIX_FMT_P010M   v4l2_fourcc('P', 'M', '1', '0') /* 15  Y/CbCr 4:2:0, 10 bits per channel */
> >>  /* three planes - Y Cb, Cr */
> >>  #define V4L2_PIX_FMT_YUV410  v4l2_fourcc('Y', 'U', 'V', '9') /*  9  YUV 4:1:0     */
> 

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

Re: [PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats

[ayaka]

On 01/02/2017 07:07 PM, Sakari Ailus wrote:
> Hi,
>
> On Mon, Jan 02, 2017 at 06:53:16PM +0800, ayaka wrote:
>>
>> On 01/02/2017 05:10 PM, Sakari Ailus wrote:
>>> Hi Randy,
>>>
>>> Thanks for the patch.
>>>
>>> On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:
>>>> The formats added by this patch are:
>>>> 	V4L2_PIX_FMT_P010
>>>> 	V4L2_PIX_FMT_P010M
>>>> Currently, none of driver uses those format, but some video device
>>>> has been confirmed with could as those format for video output.
>>>> The Rockchip's new decoder has supported those format for profile_10
>>>> HEVC/AVC video.
>>>>
>>>> Signed-off-by: Randy Li <ayaka@soulik.info>
>>> If the format resembles the existing formats but on a different bit depth,
>>> it should be named in similar fashion.
>> Do you mean it would be better if it is called as NV12_10?
> If it otherwise resembles NV12 but just has 10 bits per pixel, I think
> NV12_10 is a good name for it.
The main reason I don't like it is that there is a various of software 
having used the P010 for this kind of pixel format. It would leadi a 
conflict between them(and I never saw it is used as NV12_10), as the 
P010 is more common to be used.
I left a problem unsolved for P010 in v4l2, P010 have two variant, 
little endian and big endian. Which could be easy identified in drm 
driver(there is a flag for all the big endian pixel format).
>
>>> Could you also add ReST documentation for the format, please?
>> I will.
>>> The common requirement for merging patches that change interfaces has been
>>> that there's a user for that change. It'll still help you to get this
>> The kernel used in rockchip has supported that format in drm driver, but
>> just we don't have a agreement about the pixel format. As the Gstreamer and
>> some others would call it with a P010_ prefix, but Mark(rockchip's drm
>> author) prefer the something like NV12_10, that is why I sent out those
>> patches, I want the upstream decided its final name.
> Ack.
>
> I think we haven't really tried to unify the format naming in the past
> between the two subsystems. If existing conventions exist on both regarding
> this format, then it's probably better to follow those.
>
> Cc Laurent as well.
>
>>> reviewed now so the interface that the future hopefully-in-mainline driver
>>> provides will not change.
>>>
>>>> ---
>>>>   include/uapi/linux/videodev2.h | 2 ++
>>>>   1 file changed, 2 insertions(+)
>>>>
>>>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>>>> index 46e8a2e3..9e03f20 100644
>>>> --- a/include/uapi/linux/videodev2.h
>>>> +++ b/include/uapi/linux/videodev2.h
>>>> @@ -551,6 +551,7 @@ struct v4l2_pix_format {
>>>>   #define V4L2_PIX_FMT_NV61    v4l2_fourcc('N', 'V', '6', '1') /* 16  Y/CrCb 4:2:2  */
>>>>   #define V4L2_PIX_FMT_NV24    v4l2_fourcc('N', 'V', '2', '4') /* 24  Y/CbCr 4:4:4  */
>>>>   #define V4L2_PIX_FMT_NV42    v4l2_fourcc('N', 'V', '4', '2') /* 24  Y/CrCb 4:4:4  */
>>>> +#define V4L2_PIX_FMT_P010    v4l2_fourcc('P', '0', '1', '0') /* 15  Y/CbCr 4:2:0, 10 bits per channel */
>>>>   /* two non contiguous planes - one Y, one Cr + Cb interleaved  */
>>>>   #define V4L2_PIX_FMT_NV12M   v4l2_fourcc('N', 'M', '1', '2') /* 12  Y/CbCr 4:2:0  */
>>>> @@ -559,6 +560,7 @@ struct v4l2_pix_format {
>>>>   #define V4L2_PIX_FMT_NV61M   v4l2_fourcc('N', 'M', '6', '1') /* 16  Y/CrCb 4:2:2  */
>>>>   #define V4L2_PIX_FMT_NV12MT  v4l2_fourcc('T', 'M', '1', '2') /* 12  Y/CbCr 4:2:0 64x32 macroblocks */
>>>>   #define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12  Y/CbCr 4:2:0 16x16 macroblocks */
>>>> +#define V4L2_PIX_FMT_P010M   v4l2_fourcc('P', 'M', '1', '0') /* 15  Y/CbCr 4:2:0, 10 bits per channel */
>>>>   /* three planes - Y Cb, Cr */
>>>>   #define V4L2_PIX_FMT_YUV410  v4l2_fourcc('Y', 'U', 'V', '9') /*  9  YUV 4:1:0     */

Re: [PATCH 2/2] [media] v4l: Add 10-bits per channel YUV pixel formats

[Daniel Stone]

Hi all,

On 2 January 2017 at 13:03, ayaka <ayaka@soulik.info> wrote:
> On 01/02/2017 07:07 PM, Sakari Ailus wrote:
>> On Mon, Jan 02, 2017 at 06:53:16PM +0800, ayaka wrote:
>>> On 01/02/2017 05:10 PM, Sakari Ailus wrote:
>>>> If the format resembles the existing formats but on a different bit
>>>> depth,
>>>> it should be named in similar fashion.
>>>
>>> Do you mean it would be better if it is called as NV12_10?
>>
>> If it otherwise resembles NV12 but just has 10 bits per pixel, I think
>> NV12_10 is a good name for it.
>
> The main reason I don't like it is that there is a various of software
> having used the P010 for this kind of pixel format. It would leadi a
> conflict between them(and I never saw it is used as NV12_10), as the P010 is
> more common to be used.

Indeed; GStreamer, FFmpeg and Microsoft all call this P010:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx

fourcc.org is supposed to reflect Microsoft's registry, but seems to
not be actively maintained anymore.

Cheers,
Daniel

Re: [PATCH 1/2] drm_fourcc: Add new P010 video format

[Daniel Stone]

Hi Randy,

On 2 January 2017 at 09:50, Randy Li <ayaka@soulik.info> wrote:
> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
> per channel video format. Rockchip's vop support this
> video format(little endian only) as the input video format.
>
> Signed-off-by: Randy Li <ayaka@soulik.info>
> ---
>  include/uapi/drm/drm_fourcc.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 9e1bb7f..d2721da 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -119,6 +119,7 @@ extern "C" {
>  #define DRM_FORMAT_NV61                fourcc_code('N', 'V', '6', '1') /* 2x1 subsampled Cb:Cr plane */
>  #define DRM_FORMAT_NV24                fourcc_code('N', 'V', '2', '4') /* non-subsampled Cr:Cb plane */
>  #define DRM_FORMAT_NV42                fourcc_code('N', 'V', '4', '2') /* non-subsampled Cb:Cr plane */
> +#define DRM_FORMAT_P010                fourcc_code('P', '0', '1', '0') /* 2x2 subsampled Cr:Cb plane 10 bits per channel */

Thanks, this looks good, but I have two requests. Firstly, the
Microsoft page here also mentions that P016 is a preferred format
along P010, so please add P016 as well:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx

I don't see much use of the other (P21x/P41x/Yxxx) formats defined
there, so there's probably no use going wild and adding them just yet.

Secondly, please update the format_info table in drm_fourcc.c for
these two formats, to avoid throwing a WARN_ON every time they are
used.

Cheers,
Daniel

Re: [PATCH 1/2] drm_fourcc: Add new P010 video format

[Ville Syrjälä]

On Mon, Jan 02, 2017 at 04:50:03PM +0800, Randy Li wrote:
> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
> per channel video format. Rockchip's vop support this
> video format(little endian only) as the input video format.
> 
> Signed-off-by: Randy Li <ayaka@soulik.info>
> ---
>  include/uapi/drm/drm_fourcc.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 9e1bb7f..d2721da 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -119,6 +119,7 @@ extern "C" {
>  #define DRM_FORMAT_NV61		fourcc_code('N', 'V', '6', '1') /* 2x1 subsampled Cb:Cr plane */
>  #define DRM_FORMAT_NV24		fourcc_code('N', 'V', '2', '4') /* non-subsampled Cr:Cb plane */
>  #define DRM_FORMAT_NV42		fourcc_code('N', 'V', '4', '2') /* non-subsampled Cb:Cr plane */
> +#define DRM_FORMAT_P010		fourcc_code('P', '0', '1', '0') /* 2x2 subsampled Cr:Cb plane 10 bits per channel */

We could use a better description of the format here. IIRC there is
10bits of actual data contained in each 16bits. So there should be a
proper comment explaning in which way the bits are stored.

>  
>  /*
>   * 3 plane YCbCr
> -- 
> 2.7.4
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC

Re: [PATCH 1/2] drm_fourcc: Add new P010 video format

[ayaka]

On 01/04/2017 11:56 PM, Ville Syrjälä wrote:
> On Mon, Jan 02, 2017 at 04:50:03PM +0800, Randy Li wrote:
>> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
>> per channel video format. Rockchip's vop support this
>> video format(little endian only) as the input video format.
>>
>> Signed-off-by: Randy Li <ayaka@soulik.info>
>> ---
>>   include/uapi/drm/drm_fourcc.h | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>> index 9e1bb7f..d2721da 100644
>> --- a/include/uapi/drm/drm_fourcc.h
>> +++ b/include/uapi/drm/drm_fourcc.h
>> @@ -119,6 +119,7 @@ extern "C" {
>>   #define DRM_FORMAT_NV61		fourcc_code('N', 'V', '6', '1') /* 2x1 subsampled Cb:Cr plane */
>>   #define DRM_FORMAT_NV24		fourcc_code('N', 'V', '2', '4') /* non-subsampled Cr:Cb plane */
>>   #define DRM_FORMAT_NV42		fourcc_code('N', 'V', '4', '2') /* non-subsampled Cb:Cr plane */
>> +#define DRM_FORMAT_P010		fourcc_code('P', '0', '1', '0') /* 2x2 subsampled Cr:Cb plane 10 bits per channel */
> We could use a better description of the format here. IIRC there is
> 10bits of actual data contained in each 16bits. So there should be a
> proper comment explaning in which way the bits are stored.
It is a little hard to describe P010, which leaves a problem cpp 
information in the new patches.
Also I have no idea how to draw the byte-order table the rst document 
for v4l2.
>
>>   
>>   /*
>>    * 3 plane YCbCr
>> -- 
>> 2.7.4
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] drm_fourcc: Add new P010 video format

[Ville Syrjälä]

On Thu, Jan 05, 2017 at 12:31:27AM +0800, ayaka wrote:
>
>
> On 01/04/2017 11:56 PM, Ville Syrjälä wrote:
> > On Mon, Jan 02, 2017 at 04:50:03PM +0800, Randy Li wrote:
> >> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
> >> per channel video format. Rockchip's vop support this
> >> video format(little endian only) as the input video format.
> >>
> >> Signed-off-by: Randy Li <ayaka@soulik.info>
> >> ---
> >>   include/uapi/drm/drm_fourcc.h | 1 +
> >>   1 file changed, 1 insertion(+)
> >>
> >> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> >> index 9e1bb7f..d2721da 100644
> >> --- a/include/uapi/drm/drm_fourcc.h
> >> +++ b/include/uapi/drm/drm_fourcc.h
> >> @@ -119,6 +119,7 @@ extern "C" {
> >>   #define DRM_FORMAT_NV61		fourcc_code('N', 'V', '6', '1') /* 2x1 subsampled Cb:Cr plane */
> >>   #define DRM_FORMAT_NV24		fourcc_code('N', 'V', '2', '4') /* non-subsampled Cr:Cb plane */
> >>   #define DRM_FORMAT_NV42		fourcc_code('N', 'V', '4', '2') /* non-subsampled Cb:Cr plane */
> >> +#define DRM_FORMAT_P010		fourcc_code('P', '0', '1', '0') /* 2x2 subsampled Cr:Cb plane 10 bits per channel */
> > We could use a better description of the format here. IIRC there is
> > 10bits of actual data contained in each 16bits. So there should be a
> > proper comment explaning in which way the bits are stored.
> It is a little hard to describe P010,

/*
 * 2 plane YCbCr
 * index 0 = Y plane, [15:0] Y:X 10:6 little-endian
 * index 1 = Cr:Cb plane, [31:0] Cr:X:Cb:X 10:6:10:6 little-endian
 */

/*
 * 2 plane YCbCr
 * index 0 = Y plane, [15:0] Y 16 little-endian
 * index 1 = Cr:Cb plane, [31:0] Cr:Cb 16:16 little-endian
 */

or something like that (not 100% sure I got the order of bits and
whatnot correct).

-- 
Ville Syrjälä
Intel OTC