Hi Daniel,
On Tue, 2018-01-30 at 02:22:40 -0800, Daniel Vetter wrote:
> On Thu, Jan 25, 2018 at 06:03:59PM -0800, Hyun Kwon wrote:
> > Multiple pixels can be grouped as a single unit and form a 'macro-pixel'.
> > This is to model formats where multiple pixels are stored together
> > in a specific way, likely byte-algined. For example, if 3 - 10 bit
> > pixels are stored in 32 bit, the 32 bit stroage can be treated as
> > a single macro-pixel with 3 pixels. This aligns non-byte addressable
> > formats with drm core where bpp is expected to be multiple of 8 bit.
> >
> > Add 'ppm', pixels per macro-pixel, to note how many pixels are grouped
> > in a macro-pixel. 'bpm', bits per macro-pixel, specifies how many bits
> > are in a macro-pixel as there can be some extra padding bits.
>
> Should we mandate that macro-pixels are always byte-aligned? This would
> mean cpm for characters per macro-pixel would be more meaningful.
>
Agreed. That would simplify stuff and be more clean.
> >
> > Signed-off-by: Hyun Kwon <hyun.k...@xilinx.com>
> > ---
> > v2
> > - Introduce macro-pixel over scaling factors
> > ---
> > ---
> > drivers/gpu/drm/drm_fourcc.c | 136
> > +++++++++++++++++++++----------------------
> > include/drm/drm_fourcc.h | 9 +++
> > 2 files changed, 77 insertions(+), 68 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > index b891fe0..8fc1e35 100644
> > --- a/drivers/gpu/drm/drm_fourcc.c
> > +++ b/drivers/gpu/drm/drm_fourcc.c
> > @@ -105,74 +105,74 @@ EXPORT_SYMBOL(drm_get_format_name);
> > const struct drm_format_info *__drm_format_info(u32 format)
> > {
> > static const struct drm_format_info formats[] = {
> > - { .format = DRM_FORMAT_C8, .depth = 8,
> > .num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 }, .hsub = 1, .vsub
> > = 1 },
> > - { .format = DRM_FORMAT_RGB332, .depth = 8,
> > .num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 }, .hsub = 1, .vsub
> > = 1 },
> > - { .format = DRM_FORMAT_BGR233, .depth = 8,
> > .num_planes = 1, .cpp = { 1, 0, 0 }, .bpp = { 8, 0, 0 }, .hsub = 1, .vsub
> > = 1 },
> > - { .format = DRM_FORMAT_XRGB4444, .depth = 0,
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub
> > = 1 },
> > - { .format = DRM_FORMAT_XBGR4444, .depth = 0,
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub
> > = 1 },
> > - { .format = DRM_FORMAT_RGBX4444, .depth = 0,
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub
> > = 1 },
> > - { .format = DRM_FORMAT_BGRX4444, .depth = 0,
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub
> > = 1 },
> > - { .format = DRM_FORMAT_ARGB4444, .depth = 0,
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub
> > = 1 },
> > - { .format = DRM_FORMAT_ABGR4444, .depth = 0,
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub
> > = 1 },
> > - { .format = DRM_FORMAT_RGBA4444, .depth = 0,
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub
> > = 1 },
> > - { .format = DRM_FORMAT_BGRA4444, .depth = 0,
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .hsub = 1, .vsub
> > = 1 },
[snip]
> + { .format = DRM_FORMAT_NV16, .depth = 0,
> .num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 8, 16, 0 }, .ppm = { 1, 1, 0
> }, .bpm = { 8, 16, 0 }, .hsub = 2, .vsub = 1 },
> > + { .format = DRM_FORMAT_NV61, .depth = 0,
> > .num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 8, 16, 0 }, .ppm = { 1, 1, 0
> > }, .bpm = { 8, 16, 0 }, .hsub = 2, .vsub = 1 },
> > + { .format = DRM_FORMAT_NV24, .depth = 0,
> > .num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 8, 16, 0 }, .ppm = { 1, 1, 0
> > }, .bpm = { 8, 16, 0 }, .hsub = 1, .vsub = 1 },
> > + { .format = DRM_FORMAT_NV42, .depth = 0,
> > .num_planes = 2, .cpp = { 1, 2, 0 }, .bpp = { 8, 16, 0 }, .ppm = { 1, 1, 0
> > }, .bpm = { 8, 16, 0 }, .hsub = 1, .vsub = 1 },
> > + { .format = DRM_FORMAT_YUYV, .depth = 0,
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .ppm = { 1, 0, 0
> > }, .bpm = { 16, 0, 0 }, .hsub = 2, .vsub = 1 },
> > + { .format = DRM_FORMAT_YVYU, .depth = 0,
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .ppm = { 1, 0, 0
> > }, .bpm = { 16, 0, 0 }, .hsub = 2, .vsub = 1 },
> > + { .format = DRM_FORMAT_UYVY, .depth = 0,
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .ppm = { 1, 0, 0
> > }, .bpm = { 16, 0, 0 }, .hsub = 2, .vsub = 1 },
> > + { .format = DRM_FORMAT_VYUY, .depth = 0,
> > .num_planes = 1, .cpp = { 2, 0, 0 }, .bpp = { 16, 0, 0 }, .ppm = { 1, 0, 0
> > }, .bpm = { 16, 0, 0 }, .hsub = 2, .vsub = 1 },
> > + { .format = DRM_FORMAT_AYUV, .depth = 0,
> > .num_planes = 1, .cpp = { 4, 0, 0 }, .bpp = { 32, 0, 0 }, .ppm = { 1, 0, 0
> > }, .bpm = { 32, 0, 0 }, .hsub = 1, .vsub = 1 },
>
> Ugh. I think some macros for the common/simple cases would be useful.
> There's also other people trying to add more information to these (like
> alpha bits), refactoring this slightly would help I think.
>
> > };
> >
> > unsigned int i;
> > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> > index 752bd43..64038e9 100644
> > --- a/include/drm/drm_fourcc.h
> > +++ b/include/drm/drm_fourcc.h
> > @@ -37,6 +37,13 @@ struct drm_mode_fb_cmd2;
> > * @num_planes: Number of color planes (1 to 3)
> > * @cpp: Number of bytes per pixel (per plane)
> > * @bpp: Number of bits per pixel (per plane)
> > + * @ppm: Number of pixels per macro-pixel (per plane). A macro-pixel is
> > + * composed of multiple pixels, possibly with some padding bits
> > + * around pixels. For example, some 10 bit format has 3 components
> > + * in every 32 bit, where 3 10bit components are followed by 2 bit padding.
> > + * @bpm: Number of bits per macro-pixel (per plane). Bits per macro-pixel.
> > + * The value is different from bpp * ppm if a macro-pixel has
> > + * extra padding bits.
>
> Please switch the entire kernel-doc for this structure to the in-line
> member kerneldoc style. That's much more readable and groups the comments
> closer to the members.
Sure, will do.
>
> Also I think we should write these out. cpp/bpp are well-known, ppm and
> bpm aren't (and bpm usually means beats per minute, so even more
> confusing).
Would having more explanation in the member descriptions abvoe, maybe with
some renaming, be sufficient? or did you mean different write-up?
Thanks,
-hyun
> -Daniel
>
> > * @hsub: Horizontal chroma subsampling factor
> > * @vsub: Vertical chroma subsampling factor
> > */
> > @@ -46,6 +53,8 @@ struct drm_format_info {
> > u8 num_planes;
> > u8 cpp[3];
> > u8 bpp[3];
> > + u8 ppm[3];
> > + u8 bpm[3];
> > u8 hsub;
> > u8 vsub;
> > };
> > --
> > 2.7.4
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
