On Thu, Feb 08, 2018 at 06:19:32PM -0800, Hyun Kwon wrote:
> 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.kwon@xxxxxxxxxx>
> > > ---
> > > 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?
I meant the member name itself needs to be more self-explanatory. Forcing
everyone to go to the docs is inefficient. Good docs are still needed ofc.
-Daniel
>
> 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
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
