All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko@sntech.de>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	David Airlie <airlied@linux.ie>, Sean Paul <sean@poorly.run>
Subject: Re: [PATCH v2 1/3] drm: Add some new format DRM_FORMAT_NVXX_10
Date: Fri, 08 Nov 2019 16:08:50 +0100	[thread overview]
Message-ID: <17879396.dXe580Ps6o@diego> (raw)
In-Reply-To: <20191009145008.GB16989@phenom.ffwll.local>

Hi Daniel, Sandy,

Am Mittwoch, 9. Oktober 2019, 16:50:08 CET schrieb Daniel Vetter:
> 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,
> 
> Yup this is what I had in mind with using the block stuff to describe your
> new 10bit yuv formats. Thanks for respining.
> 
> Once we've nailed the exact bit description of the format precisely this
> can be merged imo.

I just saw this series still sitting in my inbox, so was wondering about the
"once we've nailed the exact bit description..." and what is missing for that.

Thanks
Heiko


> > 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
> > + */
> > +#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
> 
> 




_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Sandy Huang <hjc@rock-chips.com>,
	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>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] drm: Add some new format DRM_FORMAT_NVXX_10
Date: Fri, 08 Nov 2019 16:08:50 +0100	[thread overview]
Message-ID: <17879396.dXe580Ps6o@diego> (raw)
In-Reply-To: <20191009145008.GB16989@phenom.ffwll.local>

Hi Daniel, Sandy,

Am Mittwoch, 9. Oktober 2019, 16:50:08 CET schrieb Daniel Vetter:
> 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,
> 
> Yup this is what I had in mind with using the block stuff to describe your
> new 10bit yuv formats. Thanks for respining.
> 
> Once we've nailed the exact bit description of the format precisely this
> can be merged imo.

I just saw this series still sitting in my inbox, so was wondering about the
"once we've nailed the exact bit description..." and what is missing for that.

Thanks
Heiko


> > 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
> > + */
> > +#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
> 
> 





  reply	other threads:[~2019-11-08 15:09 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-26  8:24 [PATCH v2 0/3] Add some yuv 10bit support Sandy Huang
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-29  3:26     ` 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  2:40       ` sandy.huang
2019-10-08 11:33       ` Ville Syrjälä
2019-10-08 11:49         ` sandy.huang
2019-10-08 11:49           ` sandy.huang
2019-10-11  3:35           ` sandy.huang
2019-10-11  3:35             ` sandy.huang
2019-10-11  6:44             ` james qian wang (Arm Technology China)
2019-10-11  7:07               ` sandy.huang
2019-10-11  7:07                 ` sandy.huang
2019-10-11  7:22                 ` james qian wang (Arm Technology China)
2019-10-11  7:32                   ` sandy.huang
2019-10-11  7:32                     ` sandy.huang
2019-10-11  8:32                     ` james qian wang (Arm Technology China)
2019-10-11  9:45                       ` sandy.huang
2019-10-11  9:45                         ` sandy.huang
2019-10-14  3:02                         ` james qian wang (Arm Technology China)
2019-10-14  8:34                         ` Daniel Vetter
2019-10-14  8:34                           ` Daniel Vetter
2019-10-09 14:50   ` Daniel Vetter
2019-10-09 14:50     ` Daniel Vetter
2019-11-08 15:08     ` Heiko Stübner [this message]
2019-11-08 15:08       ` Heiko Stübner
2019-11-08 16:37       ` Daniel Vetter
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   ` Sandy Huang
2019-09-26  8:24 ` [PATCH v2 3/3] drm/rockchip: Add support 10bit yuv format Sandy Huang
2019-09-26  8:24   ` Sandy Huang
2019-09-26  8:24   ` Sandy Huang
  -- strict thread matches above, loose matches on Subject: below --
2019-09-26  8:17 [PATCH v2 0/3] Add some yuv 10bit support Sandy Huang
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=17879396.dXe580Ps6o@diego \
    --to=heiko@sntech.de \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime.ripard@bootlin.com \
    --cc=sean@poorly.run \
    /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.