| Message ID | 20221219140139.294245-8-tomi.valkeinen+renesas@ideasonboard.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | media/drm: renesas: Add new pixel formats | expand |
Hi Laurent, On Mon, Dec 19, 2022 at 11:47:04PM +0200, Laurent Pinchart wrote: > Hi Tomi, > > (CC'ing Sakari and Hans) > > Thank you for the patch. > > On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote: > > Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210. > > > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> > > --- > > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++ > > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++-- > > 2 files changed, 71 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > index 8c2719efda2a..8ccabf5a30c4 100644 > > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = { > > .bpp = 32, > > .planes = 1, > > .hsub = 1, > > + }, { > > + .fourcc = DRM_FORMAT_RGBX1010102, > > Ah, here the format makes sense. > > > + .v4l2 = V4L2_PIX_FMT_XBGR2101010, > > But this is horrible :-( Could we use the same names as DRM for new > formats, when there is no conflict with existing V4L2 formats ? > > Sakari, Hans, what do you think ? Please see patch 1/7 in the series for > the format definitions. I think it'd be good to have only one set of definitions. Can we can sort the endianness question in a reasonable way? Also new Bayer formats will probably be still needed on V4L2 side but will they be relevant for DRM? I suppose that would mean new DRM format for each pixel order, too? Or can we think of something smarter that would still work reasonably with existing formats?
Hi Sakari, On Tue, Dec 20, 2022 at 11:36:35AM +0200, Sakari Ailus wrote: > On Mon, Dec 19, 2022 at 11:47:04PM +0200, Laurent Pinchart wrote: > > On Mon, Dec 19, 2022 at 04:01:39PM +0200, Tomi Valkeinen wrote: > > > Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210. > > > > > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> > > > --- > > > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++ > > > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++-- > > > 2 files changed, 71 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > > index 8c2719efda2a..8ccabf5a30c4 100644 > > > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > > @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = { > > > .bpp = 32, > > > .planes = 1, > > > .hsub = 1, > > > + }, { > > > + .fourcc = DRM_FORMAT_RGBX1010102, > > > > Ah, here the format makes sense. > > > > > + .v4l2 = V4L2_PIX_FMT_XBGR2101010, > > > > But this is horrible :-( Could we use the same names as DRM for new > > formats, when there is no conflict with existing V4L2 formats ? > > > > Sakari, Hans, what do you think ? Please see patch 1/7 in the series for > > the format definitions. > > I think it'd be good to have only one set of definitions. > > Can we can sort the endianness question in a reasonable way? It's really a matter of macro names only in this case, so it's "just" up to us to decide what we want to do. Hans' argument is that we would then depart from the general V4L2 rule, and thus create confusion, but I don't think there's such a clear cut rule in the first place and confusion is there already. Having common definitions for new formats would, I think, reduce confusion. > Also new Bayer formats will probably be still needed on V4L2 side but will > they be relevant for DRM? I suppose that would mean new DRM format for > each pixel order, too? Or can we think of something smarter that would > still work reasonably with existing formats? We use DRM 4CCs in the libcamera public API, and the DRM maintainers have agreed to add DRM 4CCs for formats that are used by cameras only, such as MJPEG for instance, that's hardly useful for displays. The same holds true for Bayer formats, and we use DRM modifiers to specify the packing instead of defining different 4CCs. I'd like to do something similar for the Bayer pattern, although specifying it out-of-band may be even better.
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 8c2719efda2a..8ccabf5a30c4 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c @@ -259,6 +259,24 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = { .bpp = 32, .planes = 1, .hsub = 1, + }, { + .fourcc = DRM_FORMAT_RGBX1010102, + .v4l2 = V4L2_PIX_FMT_XBGR2101010, + .bpp = 32, + .planes = 1, + .hsub = 1, + }, { + .fourcc = DRM_FORMAT_RGBA1010102, + .v4l2 = V4L2_PIX_FMT_ABGR2101010, + .bpp = 32, + .planes = 1, + .hsub = 1, + }, { + .fourcc = DRM_FORMAT_ARGB2101010, + .v4l2 = V4L2_PIX_FMT_BGRA1010102, + .bpp = 32, + .planes = 1, + .hsub = 1, }, { .fourcc = DRM_FORMAT_YVYU, .v4l2 = V4L2_PIX_FMT_YVYU, @@ -307,6 +325,12 @@ static const struct rcar_du_format_info rcar_du_format_infos[] = { .bpp = 24, .planes = 3, .hsub = 1, + }, { + .fourcc = DRM_FORMAT_Y210, + .v4l2 = V4L2_PIX_FMT_Y210, + .bpp = 32, + .planes = 1, + .hsub = 2, }, }; diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index e465aef41585..6f3e109a4f80 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c @@ -139,6 +139,42 @@ static const u32 rcar_du_vsp_formats[] = { DRM_FORMAT_YVU444, }; +/* + * Gen4 supports the same formats as above, and additionally 2-10-10-10 RGB + * formats and Y210 format. + */ +static const u32 rcar_du_vsp_formats_gen4[] = { + DRM_FORMAT_RGB332, + DRM_FORMAT_ARGB4444, + DRM_FORMAT_XRGB4444, + DRM_FORMAT_ARGB1555, + DRM_FORMAT_XRGB1555, + DRM_FORMAT_RGB565, + DRM_FORMAT_BGR888, + DRM_FORMAT_RGB888, + DRM_FORMAT_BGRA8888, + DRM_FORMAT_BGRX8888, + DRM_FORMAT_ARGB8888, + DRM_FORMAT_XRGB8888, + DRM_FORMAT_RGBX1010102, + DRM_FORMAT_RGBA1010102, + DRM_FORMAT_ARGB2101010, + DRM_FORMAT_UYVY, + DRM_FORMAT_YUYV, + DRM_FORMAT_YVYU, + DRM_FORMAT_NV12, + DRM_FORMAT_NV21, + DRM_FORMAT_NV16, + DRM_FORMAT_NV61, + DRM_FORMAT_YUV420, + DRM_FORMAT_YVU420, + DRM_FORMAT_YUV422, + DRM_FORMAT_YVU422, + DRM_FORMAT_YUV444, + DRM_FORMAT_YVU444, + DRM_FORMAT_Y210, +}; + static void rcar_du_vsp_plane_setup(struct rcar_du_vsp_plane *plane) { struct rcar_du_vsp_plane_state *state = @@ -436,14 +472,23 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp, struct device_node *np, ? DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY; struct rcar_du_vsp_plane *plane = &vsp->planes[i]; + unsigned int num_formats; + const u32 *formats; + + if (rcdu->info->gen < 4) { + num_formats = ARRAY_SIZE(rcar_du_vsp_formats); + formats = rcar_du_vsp_formats; + } else { + num_formats = ARRAY_SIZE(rcar_du_vsp_formats_gen4); + formats = rcar_du_vsp_formats_gen4; + } plane->vsp = vsp; plane->index = i; ret = drm_universal_plane_init(&rcdu->ddev, &plane->plane, crtcs, &rcar_du_vsp_plane_funcs, - rcar_du_vsp_formats, - ARRAY_SIZE(rcar_du_vsp_formats), + formats, num_formats, NULL, type, NULL); if (ret < 0) return ret;
Add new pixel formats: RGBX1010102, RGBA1010102, ARGB2101010 and Y210. Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> --- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 24 +++++++++++++ drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 49 +++++++++++++++++++++++++-- 2 files changed, 71 insertions(+), 2 deletions(-)