From: "sandy.huang" <hjc@rock-chips.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: dri-devel@lists.freedesktop.org,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <maxime.ripard@bootlin.com>,
Sean Paul <sean@poorly.run>, David Airlie <airlied@linux.ie>,
Daniel Vetter <daniel@ffwll.ch>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] drm: Add some new format DRM_FORMAT_NVXX_10
Date: Tue, 8 Oct 2019 19:49:33 +0800 [thread overview]
Message-ID: <a5fa3d8e-9e8e-8aa8-8abb-f00e8357acb5@rock-chips.com> (raw)
In-Reply-To: <20191008113338.GP1208@intel.com>
在 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@rock-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@lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-10-08 11:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1569486289-152061-1-git-send-email-hjc@rock-chips.com>
2019-09-26 8:24 ` [PATCH v2 1/3] drm: Add some new format DRM_FORMAT_NVXX_10 Sandy Huang
2019-09-29 3:26 ` [v2,1/3] " james qian wang (Arm Technology China)
2019-09-30 10:48 ` [PATCH v2 1/3] " Ville Syrjälä
2019-10-08 2:40 ` sandy.huang
2019-10-08 11:33 ` Ville Syrjälä
2019-10-08 11:49 ` sandy.huang [this message]
2019-10-11 3:35 ` sandy.huang
[not found] ` <20191011064433.GA18503@jamwan02-TSP300>
2019-10-11 7:07 ` sandy.huang
[not found] ` <20191011072250.GA20592@jamwan02-TSP300>
2019-10-11 7:32 ` sandy.huang
[not found] ` <20191011083247.GA22224@jamwan02-TSP300>
2019-10-11 9:45 ` sandy.huang
2019-10-14 8:34 ` Daniel Vetter
2019-10-09 14:50 ` Daniel Vetter
2019-11-08 15:08 ` Heiko Stübner
2019-11-08 16:37 ` Daniel Vetter
2019-09-26 8:24 ` [PATCH v2 2/3] drm/rockchip: Add rockchip_vop_get_offset to get offset Sandy Huang
2019-09-26 8:24 ` [PATCH v2 3/3] drm/rockchip: Add support 10bit yuv format Sandy Huang
[not found] <1569485848-151295-1-git-send-email-hjc@rock-chips.com>
2019-09-26 8:17 ` [PATCH v2 1/3] drm: Add some new format DRM_FORMAT_NVXX_10 Sandy Huang
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=a5fa3d8e-9e8e-8aa8-8abb-f00e8357acb5@rock-chips.com \
--to=hjc@rock-chips.com \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=maxime.ripard@bootlin.com \
--cc=sean@poorly.run \
--cc=ville.syrjala@linux.intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).