| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <2c46d532-f810-392d-b9c0-3b9aaccae7f4@rock-chips.com>
Date: Tue, 8 Oct 2019 10:40:20 +0800
From: "sandy.huang" <hjc@...k-chips.com>
To: Ville Syrjälä <ville.syrjala@...ux.intel.com>
Cc: dri-devel@...ts.freedesktop.org,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <maxime.ripard@...tlin.com>,
Sean Paul <sean@...rly.run>, David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/3] drm: Add some new format DRM_FORMAT_NVXX_10
Hi ville syrjala,
在 2019/9/30 下午6:48, Ville Syrjälä 写道:
> On Thu, Sep 26, 2019 at 04:24:47PM +0800, Sandy Huang wrote:
>> These new format is supported by some rockchip socs:
>>
>> DRM_FORMAT_NV12_10/DRM_FORMAT_NV21_10
>> DRM_FORMAT_NV16_10/DRM_FORMAT_NV61_10
>> DRM_FORMAT_NV24_10/DRM_FORMAT_NV42_10
>>
>> Signed-off-by: Sandy Huang <hjc@...k-chips.com>
>> ---
>> drivers/gpu/drm/drm_fourcc.c | 18 ++++++++++++++++++
>> include/uapi/drm/drm_fourcc.h | 14 ++++++++++++++
>> 2 files changed, 32 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
>> index c630064..ccd78a3 100644
>> --- a/drivers/gpu/drm/drm_fourcc.c
>> +++ b/drivers/gpu/drm/drm_fourcc.c
>> @@ -261,6 +261,24 @@ const struct drm_format_info *__drm_format_info(u32 format)
>> { .format = DRM_FORMAT_P016, .depth = 0, .num_planes = 2,
>> .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 }, .block_h = { 1, 0, 0 },
>> .hsub = 2, .vsub = 2, .is_yuv = true},
>> + { .format = DRM_FORMAT_NV12_10, .depth = 0, .num_planes = 2,
>> + .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 }, .block_h = { 4, 4, 0 },
>> + .hsub = 2, .vsub = 2, .is_yuv = true},
>> + { .format = DRM_FORMAT_NV21_10, .depth = 0, .num_planes = 2,
>> + .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 }, .block_h = { 4, 4, 0 },
>> + .hsub = 2, .vsub = 2, .is_yuv = true},
>> + { .format = DRM_FORMAT_NV16_10, .depth = 0, .num_planes = 2,
>> + .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 }, .block_h = { 4, 4, 0 },
>> + .hsub = 2, .vsub = 1, .is_yuv = true},
>> + { .format = DRM_FORMAT_NV61_10, .depth = 0, .num_planes = 2,
>> + .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 }, .block_h = { 4, 4, 0 },
>> + .hsub = 2, .vsub = 1, .is_yuv = true},
>> + { .format = DRM_FORMAT_NV24_10, .depth = 0, .num_planes = 2,
>> + .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 }, .block_h = { 4, 4, 0 },
>> + .hsub = 1, .vsub = 1, .is_yuv = true},
>> + { .format = DRM_FORMAT_NV42_10, .depth = 0, .num_planes = 2,
>> + .char_per_block = { 5, 10, 0 }, .block_w = { 4, 4, 0 }, .block_h = { 4, 4, 0 },
>> + .hsub = 1, .vsub = 1, .is_yuv = true},
>> { .format = DRM_FORMAT_P210, .depth = 0,
>> .num_planes = 2, .char_per_block = { 2, 4, 0 },
>> .block_w = { 1, 0, 0 }, .block_h = { 1, 0, 0 }, .hsub = 2,
>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>> index 3feeaa3..08e2221 100644
>> --- a/include/uapi/drm/drm_fourcc.h
>> +++ b/include/uapi/drm/drm_fourcc.h
>> @@ -238,6 +238,20 @@ extern "C" {
>> #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /* non-subsampled Cb:Cr plane */
>>
>> /*
>> + * 2 plane YCbCr
>> + * index 0 = Y plane, Y3:Y2:Y1:Y0 10:10:10:10
>> + * index 1 = Cb:Cr plane, Cb3:Cr3:Cb2:Cr2:Cb1:Cr1:Cb0:Cr0 10:10:10:10:10:10:10:10
>> + * or
>> + * index 1 = Cr:Cb plane, Cr3:Cb3:Cr2:Cb2:Cr1:Cb1:Cr0:Cb0 10:10:10:10:10:10:10:10
> So now you're defining it as some kind of byte aligned block.
> With that specifying endianness would now make sense since
> otherwise this tells us absolutely nothing about the memory
> layout.
>
> So I'd either do that, or go back to not specifying anything and
> use some weasel words like "mamory layout is implementation defined"
> which of course means no one can use it for anything that involves
> any kind of cross vendor stuff.
/*
* 2 plane YCbCr
* index 0 = Y plane, [39: 0] Y3:Y2:Y1:Y0 10:10:10:10 little endian
* index 1 = Cb:Cr plane, [79: 0] Cb3:Cr3:Cb2:Cr2:Cb1:Cr1:Cb0:Cr0
10:10:10:10:10:10:10:10 little endian
* or
* index 1 = Cr:Cb plane, [79: 0] Cr3:Cb3:Cr2:Cb2:Cr1:Cb1:Cr0:Cb0
10:10:10:10:10:10:10:10 little endian
*/
Is this description ok?
>> + */
>> +#define DRM_FORMAT_NV12_10 fourcc_code('N', 'A', '1', '2') /* 2x2 subsampled Cr:Cb plane */
>> +#define DRM_FORMAT_NV21_10 fourcc_code('N', 'A', '2', '1') /* 2x2 subsampled Cb:Cr plane */
>> +#define DRM_FORMAT_NV16_10 fourcc_code('N', 'A', '1', '6') /* 2x1 subsampled Cr:Cb plane */
>> +#define DRM_FORMAT_NV61_10 fourcc_code('N', 'A', '6', '1') /* 2x1 subsampled Cb:Cr plane */
>> +#define DRM_FORMAT_NV24_10 fourcc_code('N', 'A', '2', '4') /* non-subsampled Cr:Cb plane */
>> +#define DRM_FORMAT_NV42_10 fourcc_code('N', 'A', '4', '2') /* non-subsampled Cb:Cr plane */
>> +
>> +/*
>> * 2 plane YCbCr MSB aligned
>> * 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.7.4
>>
>>
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@...ts.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Powered by blists - more mailing lists