| 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: <5c932cb6-fdfb-88db-3757-4c1b602d4778@rock-chips.com>
Date: Fri, 11 Oct 2019 15:07:22 +0800
From: "sandy.huang" <hjc@...k-chips.com>
To: "james qian wang (Arm Technology China)" <james.qian.wang@....com>
Cc: Ville Syrjälä <ville.syrjala@...ux.intel.com>,
Maxime Ripard <maxime.ripard@...tlin.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
David Airlie <airlied@...ux.ie>, Sean Paul <sean@...rly.run>,
nd <nd@....com>
Subject: Re: [PATCH v2 1/3] drm: Add some new format DRM_FORMAT_NVXX_10
在 2019/10/11 下午2:44, james qian wang (Arm Technology China) 写道:
> On Fri, Oct 11, 2019 at 11:35:53AM +0800, sandy.huang wrote:
>> Hi james.qian.wang,
>>
>> Thank for you remind, fou some unknow reason, i miss the the mail from
>> you:(, i get this message from https://patchwork.kernel.org/patch/11161937/
>>
>> sorry about that.
>>
>> About the format block describe, I also found some unreasonable, this
>> format need 2 line aligned, so the block_h need to sed as 2, and the
>> char_per_block need set as w * h * 10 for y plane, and w * h * 2 * 10 for uv
>> plane, so the following describe maybe more correct, thanks.
>>
>> { .format = DRM_FORMAT_NV12_10, .depth = 0, .num_planes = 2,
>> .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
>> = { 2, 2, 0 },
>> .hsub = 2, .vsub = 2, .is_yuv = true},
> Hi Sandy:
> I think for such NV12 YUV-422 (hsub = 2, vsub = 2) 2x2 subsampled format
> the block size can be:
>
> the Y plane: 2x2;
> The UV plane: 1x2; (H direction sample 1 Cb and 1Cr, V direction 2 lines got 2)
>
> Then:
>
> .char_per_block = {5, 5, 0} block_w = {2, 1, 0}. block_h = {2, 2, 0};
>
> Thanks
> James
Hi James,
If the block_w is 2 pixel, one line size at block is 2*10 bit %8 != 0,
although we use block to describe this format, but actually the data is
still stored one line by one line, still need 4 pixel aligned. so i
think here need use 4pixel*2line for per block,
Thanks,
sandy.huang.
>
>> .hsub = 2, .vsub = 2, .is_yuv = true},
>> { .format = DRM_FORMAT_NV21_10, .depth = 0, .num_planes = 2,
>> .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
>> = { 2, 2, 0 },
>> .hsub = 2, .vsub = 2, .is_yuv = true},
>> { .format = DRM_FORMAT_NV16_10, .depth = 0, .num_planes = 2,
>> .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
>> = { 2, 2, 0 },
>> .hsub = 2, .vsub = 1, .is_yuv = true},
>> { .format = DRM_FORMAT_NV61_10, .depth = 0, .num_planes = 2,
>> .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
>> = { 2, 2, 0 },
>> .hsub = 2, .vsub = 1, .is_yuv = true},
>> { .format = DRM_FORMAT_NV24_10, .depth = 0, .num_planes = 2,
>> .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
>> = { 2, 2, 0 },
>> .hsub = 1, .vsub = 1, .is_yuv = true},
>> { .format = DRM_FORMAT_NV42_10, .depth = 0, .num_planes = 2,
>> .char_per_block = { 10, 10, 0 }, .block_w = { 4, 2, 0 }, .block_h
>> = { 2, 2, 0 },
>> .hsub = 1, .vsub = 1, .is_yuv = true},
>>
>>
>>>> { .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 },
>>
>>> Hi Sandy:
>>> Their is a problem here for char_per_block size of plane[0]:
>>> Since: 5 * 8 != 4 * 4 * 10;
>>> Seems you mis-set the block_w/h, per your block size the block is 2x2, and
>> it should be:
>>> .char_per_block = { 5, 10, 0 }, .block_w = { 2, 2, 0 }, .block_h = { 2,
>> 2, 0 },
>>
>>> Best Regards:
>>> James
>>
>>
>>
>>
>>
>> 在 2019/10/8 下午7:49, sandy.huang 写道:
>>> 在 2019/10/8 下午7:33, Ville Syrjälä 写道:
>>>> On Tue, Oct 08, 2019 at 10:40:20AM +0800, sandy.huang wrote:
>>>>> 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?
>>>> Seems OK to me, if it actually describes the format correctly.
>>>>
>>>> Though I'm not sure why the CbCr is defines as an 80bit block
>>>> and Y has a 40bit block. 40bits should be enough for CbCr as well.
>>>>
>>> well, this is taken into account yuv444, 4 y point corresponding with 4
>>> uv point.
>>>
>>> if only describes the layout memory, here can change to 40bit block.
>>>
>>> thanks.
>>>
>>>>>>> + */
>>>>>>> +#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
>>>
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel@...ts.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Powered by blists - more mailing lists