| Message ID | 20221221092448.741294-1-tomi.valkeinen+renesas@ideasonboard.com |
|---|---|
| Headers | show |
| Series | media/drm: renesas: Add new pixel formats | expand |
Hi Tomi, Thank you for the patch. On Wed, Dec 21, 2022 at 11:24:42AM +0200, Tomi Valkeinen wrote: > Add XBGR2101010, ABGR2101010 and BGRA1010102 formats. You forgot to rename the formats in the commit message. > Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> > --- > .../userspace-api/media/v4l/pixfmt-rgb.rst | 194 ++++++++++++++++++ > drivers/media/v4l2-core/v4l2-ioctl.c | 3 + > include/uapi/linux/videodev2.h | 3 + > 3 files changed, 200 insertions(+) > > diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst > index 30f51cd33f99..d330aeb4d3eb 100644 > --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst > +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst > @@ -763,6 +763,200 @@ nomenclature that instead use the order of components as seen in a 24- or > \normalsize > > > +10 Bits Per Component > +===================== > + > +These formats store a 30-bit RGB triplet with an optional 2 bit alpha in four > +bytes. They are named based on the order of the RGB components as seen in a > +32-bit word, which is then stored in memory in little endian byte order > +(unless otherwise noted by the presence of bit 31 in the 4CC value), and on the > +number of bits for each component. > + > +.. raw:: latex > + > + \begingroup > + \tiny > + \setlength{\tabcolsep}{2pt} > + > +.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}| > + > + > +.. flat-table:: RGB Formats 10 Bits Per Color Component > + :header-rows: 2 > + :stub-columns: 0 > + > + * - Identifier > + - Code > + - :cspan:`7` Byte 0 in memory > + - :cspan:`7` Byte 1 > + - :cspan:`7` Byte 2 > + - :cspan:`7` Byte 3 > + * - > + - > + - 7 > + - 6 > + - 5 > + - 4 > + - 3 > + - 2 > + - 1 > + - 0 > + > + - 7 > + - 6 > + - 5 > + - 4 > + - 3 > + - 2 > + - 1 > + - 0 > + > + - 7 > + - 6 > + - 5 > + - 4 > + - 3 > + - 2 > + - 1 > + - 0 > + > + - 7 > + - 6 > + - 5 > + - 4 > + - 3 > + - 2 > + - 1 > + - 0 > + * .. _V4L2-PIX-FMT-RGBX1010102: > + > + - ``V4L2_PIX_FMT_RGBX1010102`` > + - 'RX30' > + > + - b\ :sub:`5` > + - b\ :sub:`4` > + - b\ :sub:`3` > + - b\ :sub:`2` > + - b\ :sub:`1` > + - b\ :sub:`0` > + - x > + - x > + > + - g\ :sub:`3` > + - g\ :sub:`2` > + - g\ :sub:`1` > + - g\ :sub:`0` > + - b\ :sub:`9` > + - b\ :sub:`8` > + - b\ :sub:`7` > + - b\ :sub:`6` > + > + - r\ :sub:`1` > + - r\ :sub:`0` > + - g\ :sub:`9` > + - g\ :sub:`8` > + - g\ :sub:`7` > + - g\ :sub:`6` > + - g\ :sub:`5` > + - g\ :sub:`4` > + > + - r\ :sub:`9` > + - r\ :sub:`8` > + - r\ :sub:`7` > + - r\ :sub:`6` > + - r\ :sub:`5` > + - r\ :sub:`4` > + - r\ :sub:`3` > + - r\ :sub:`2` > + - > + * .. _V4L2-PIX-FMT-RGBA1010102: > + > + - ``V4L2_PIX_FMT_RGBA1010102`` > + - 'RA30' > + > + - b\ :sub:`5` > + - b\ :sub:`4` > + - b\ :sub:`3` > + - b\ :sub:`2` > + - b\ :sub:`1` > + - b\ :sub:`0` > + - a\ :sub:`1` > + - a\ :sub:`0` > + > + - g\ :sub:`3` > + - g\ :sub:`2` > + - g\ :sub:`1` > + - g\ :sub:`0` > + - b\ :sub:`9` > + - b\ :sub:`8` > + - b\ :sub:`7` > + - b\ :sub:`6` > + > + - r\ :sub:`1` > + - r\ :sub:`0` > + - g\ :sub:`9` > + - g\ :sub:`8` > + - g\ :sub:`7` > + - g\ :sub:`6` > + - g\ :sub:`5` > + - g\ :sub:`4` > + > + - r\ :sub:`9` > + - r\ :sub:`8` > + - r\ :sub:`7` > + - r\ :sub:`6` > + - r\ :sub:`5` > + - r\ :sub:`4` > + - r\ :sub:`3` > + - r\ :sub:`2` > + - > + * .. _V4L2-PIX-FMT-ARGB2101010: > + > + - ``V4L2_PIX_FMT_ARGB2101010`` > + - 'AR30' > + > + - b\ :sub:`7` > + - b\ :sub:`6` > + - b\ :sub:`5` > + - b\ :sub:`4` > + - b\ :sub:`3` > + - b\ :sub:`2` > + - b\ :sub:`1` > + - b\ :sub:`0` > + > + - g\ :sub:`5` > + - g\ :sub:`4` > + - g\ :sub:`3` > + - g\ :sub:`2` > + - g\ :sub:`1` > + - g\ :sub:`0` > + - b\ :sub:`9` > + - b\ :sub:`8` > + > + - r\ :sub:`3` > + - r\ :sub:`2` > + - r\ :sub:`1` > + - r\ :sub:`0` > + - g\ :sub:`9` > + - g\ :sub:`8` > + - g\ :sub:`7` > + - g\ :sub:`6` > + > + - a\ :sub:`1` > + - a\ :sub:`0` > + - r\ :sub:`9` > + - r\ :sub:`8` > + - r\ :sub:`7` > + - r\ :sub:`6` > + - r\ :sub:`5` > + - r\ :sub:`4` > + - > + > +.. raw:: latex > + > + \endgroup > + > + > Deprecated RGB Formats > ====================== > > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c > index fddba75d9074..875b9a95e3c8 100644 > --- a/drivers/media/v4l2-core/v4l2-ioctl.c > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c > @@ -1304,6 +1304,9 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt) > case V4L2_PIX_FMT_BGRX32: descr = "32-bit XBGR 8-8-8-8"; break; > case V4L2_PIX_FMT_RGBA32: descr = "32-bit RGBA 8-8-8-8"; break; > case V4L2_PIX_FMT_RGBX32: descr = "32-bit RGBX 8-8-8-8"; break; > + case V4L2_PIX_FMT_RGBX1010102: descr = "32-bit RGBX-10-10-10-2"; break; There should be a space instead of a dash between RGBX and 10-10-10-2. Same below. Conditionally-Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> If this is the only change needed in the series, I can fix this when applying. > + case V4L2_PIX_FMT_RGBA1010102: descr = "32-bit RGBA-10-10-10-2"; break; > + case V4L2_PIX_FMT_ARGB2101010: descr = "32-bit ARGB-2-10-10-10"; break; > case V4L2_PIX_FMT_GREY: descr = "8-bit Greyscale"; break; > case V4L2_PIX_FMT_Y4: descr = "4-bit Greyscale"; break; > case V4L2_PIX_FMT_Y6: descr = "6-bit Greyscale"; break; > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h > index 29da1f4b4578..51d6a8aa4e17 100644 > --- a/include/uapi/linux/videodev2.h > +++ b/include/uapi/linux/videodev2.h > @@ -576,6 +576,9 @@ struct v4l2_pix_format { > #define V4L2_PIX_FMT_RGBX32 v4l2_fourcc('X', 'B', '2', '4') /* 32 RGBX-8-8-8-8 */ > #define V4L2_PIX_FMT_ARGB32 v4l2_fourcc('B', 'A', '2', '4') /* 32 ARGB-8-8-8-8 */ > #define V4L2_PIX_FMT_XRGB32 v4l2_fourcc('B', 'X', '2', '4') /* 32 XRGB-8-8-8-8 */ > +#define V4L2_PIX_FMT_RGBX1010102 v4l2_fourcc('R', 'X', '3', '0') /* 32 RGBX-10-10-10-2 */ > +#define V4L2_PIX_FMT_RGBA1010102 v4l2_fourcc('R', 'A', '3', '0') /* 32 RGBA-10-10-10-2 */ > +#define V4L2_PIX_FMT_ARGB2101010 v4l2_fourcc('A', 'R', '3', '0') /* 32 ARGB-2-10-10-10 */ > > /* Grey formats */ > #define V4L2_PIX_FMT_GREY v4l2_fourcc('G', 'R', 'E', 'Y') /* 8 Greyscale */
Hi Tomi, Thank you for the patch. On Wed, Dec 21, 2022 at 11:24:44AM +0200, Tomi Valkeinen wrote: > V3U is actually gen4, not gen3. The same IP is also used in the > (not-yet-supported) V4H. > > Change VI6_IP_VERSION_MODEL_VSPD_V3U to VI6_IP_VERSION_MODEL_VSPD_GEN4, > to represent the model correctly. V3U and V4H can still be > differentiated, if needed, with the VI6_IP_VERSION_SOC_xxx. > > Also mark VI6_IP_VERSION_MODEL_VSPD_GEN4 as gen 4 in vsp1_device_info, > and update the code to correctly match for gen 4. > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> > --- > drivers/media/platform/renesas/vsp1/vsp1_drv.c | 4 ++-- > drivers/media/platform/renesas/vsp1/vsp1_hgo.c | 4 ++-- > drivers/media/platform/renesas/vsp1/vsp1_lif.c | 1 + > drivers/media/platform/renesas/vsp1/vsp1_regs.h | 2 +- > drivers/media/platform/renesas/vsp1/vsp1_rpf.c | 12 ++++++------ > drivers/media/platform/renesas/vsp1/vsp1_video.c | 4 ++-- > drivers/media/platform/renesas/vsp1/vsp1_wpf.c | 4 ++-- > 7 files changed, 16 insertions(+), 15 deletions(-) > > diff --git a/drivers/media/platform/renesas/vsp1/vsp1_drv.c b/drivers/media/platform/renesas/vsp1/vsp1_drv.c > index c260d318d298..5710152d6511 100644 > --- a/drivers/media/platform/renesas/vsp1/vsp1_drv.c > +++ b/drivers/media/platform/renesas/vsp1/vsp1_drv.c > @@ -818,9 +818,9 @@ static const struct vsp1_device_info vsp1_device_infos[] = { > .wpf_count = 2, > .num_bru_inputs = 5, > }, { > - .version = VI6_IP_VERSION_MODEL_VSPD_V3U, > + .version = VI6_IP_VERSION_MODEL_VSPD_GEN4, > .model = "VSP2-D", > - .gen = 3, > + .gen = 4, > .features = VSP1_HAS_BRU | VSP1_HAS_EXT_DL, > .lif_count = 1, > .rpf_count = 5, > diff --git a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c > index bf3f981f93a1..e6492deb0a64 100644 > --- a/drivers/media/platform/renesas/vsp1/vsp1_hgo.c > +++ b/drivers/media/platform/renesas/vsp1/vsp1_hgo.c > @@ -196,10 +196,10 @@ struct vsp1_hgo *vsp1_hgo_create(struct vsp1_device *vsp1) > > /* Initialize the control handler. */ > v4l2_ctrl_handler_init(&hgo->ctrls.handler, > - vsp1->info->gen == 3 ? 2 : 1); > + vsp1->info->gen >= 3 ? 2 : 1); > hgo->ctrls.max_rgb = v4l2_ctrl_new_custom(&hgo->ctrls.handler, > &hgo_max_rgb_control, NULL); > - if (vsp1->info->gen == 3) > + if (vsp1->info->gen >= 3) > hgo->ctrls.num_bins = > v4l2_ctrl_new_custom(&hgo->ctrls.handler, > &hgo_num_bins_control, NULL); > diff --git a/drivers/media/platform/renesas/vsp1/vsp1_lif.c b/drivers/media/platform/renesas/vsp1/vsp1_lif.c > index 186a5730e1e3..0ab2e0c70474 100644 > --- a/drivers/media/platform/renesas/vsp1/vsp1_lif.c > +++ b/drivers/media/platform/renesas/vsp1/vsp1_lif.c > @@ -114,6 +114,7 @@ static void lif_configure_stream(struct vsp1_entity *entity, > break; > > case VI6_IP_VERSION_MODEL_VSPD_GEN3: > + case VI6_IP_VERSION_MODEL_VSPD_GEN4: > default: > hbth = 0; > obth = 3000; > diff --git a/drivers/media/platform/renesas/vsp1/vsp1_regs.h b/drivers/media/platform/renesas/vsp1/vsp1_regs.h > index 8928f4c6bb55..8c9333f76858 100644 > --- a/drivers/media/platform/renesas/vsp1/vsp1_regs.h > +++ b/drivers/media/platform/renesas/vsp1/vsp1_regs.h > @@ -766,7 +766,7 @@ > #define VI6_IP_VERSION_MODEL_VSPD_V3 (0x18 << 8) > #define VI6_IP_VERSION_MODEL_VSPDL_GEN3 (0x19 << 8) > #define VI6_IP_VERSION_MODEL_VSPBS_GEN3 (0x1a << 8) > -#define VI6_IP_VERSION_MODEL_VSPD_V3U (0x1c << 8) > +#define VI6_IP_VERSION_MODEL_VSPD_GEN4 (0x1c << 8) > /* RZ/G2L SoCs have no version register, So use 0x80 as the model version */ > #define VI6_IP_VERSION_MODEL_VSPD_RZG2L (0x80 << 8) > > diff --git a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c > index 75083cb234fe..045aa54f7998 100644 > --- a/drivers/media/platform/renesas/vsp1/vsp1_rpf.c > +++ b/drivers/media/platform/renesas/vsp1/vsp1_rpf.c > @@ -133,18 +133,18 @@ static void rpf_configure_stream(struct vsp1_entity *entity, > * a fixed alpha value set through the V4L2_CID_ALPHA_COMPONENT control > * otherwise. > * > - * The Gen3 RPF has extended alpha capability and can both multiply the > + * The Gen3+ RPF has extended alpha capability and can both multiply the > * alpha channel by a fixed global alpha value, and multiply the pixel > * components to convert the input to premultiplied alpha. > * > * As alpha premultiplication is available in the BRx for both Gen2 and > - * Gen3 we handle it there and use the Gen3 alpha multiplier for global > + * Gen3+ we handle it there and use the Gen3 alpha multiplier for global > * alpha multiplication only. This however prevents conversion to > * premultiplied alpha if no BRx is present in the pipeline. If that use > * case turns out to be useful we will revisit the implementation (for > * Gen3 only). > * > - * We enable alpha multiplication on Gen3 using the fixed alpha value > + * We enable alpha multiplication on Gen3+ using the fixed alpha value > * set through the V4L2_CID_ALPHA_COMPONENT control when the input > * contains an alpha channel. On Gen2 the global alpha is ignored in > * that case. > @@ -155,7 +155,7 @@ static void rpf_configure_stream(struct vsp1_entity *entity, > (fmtinfo->alpha ? VI6_RPF_ALPH_SEL_ASEL_PACKED > : VI6_RPF_ALPH_SEL_ASEL_FIXED)); > > - if (entity->vsp1->info->gen == 3) { > + if (entity->vsp1->info->gen >= 3) { > u32 mult; > > if (fmtinfo->alpha) { > @@ -301,10 +301,10 @@ static void rpf_configure_partition(struct vsp1_entity *entity, > } > > /* > - * On Gen3 hardware the SPUVS bit has no effect on 3-planar > + * On Gen3+ hardware the SPUVS bit has no effect on 3-planar > * formats. Swap the U and V planes manually in that case. > */ > - if (vsp1->info->gen == 3 && format->num_planes == 3 && > + if (vsp1->info->gen >= 3 && format->num_planes == 3 && > fmtinfo->swap_uv) > swap(mem.addr[1], mem.addr[2]); > > diff --git a/drivers/media/platform/renesas/vsp1/vsp1_video.c b/drivers/media/platform/renesas/vsp1/vsp1_video.c > index 9d24647c8f32..544012fd1fe9 100644 > --- a/drivers/media/platform/renesas/vsp1/vsp1_video.c > +++ b/drivers/media/platform/renesas/vsp1/vsp1_video.c > @@ -267,10 +267,10 @@ static int vsp1_video_pipeline_setup_partitions(struct vsp1_pipeline *pipe) > div_size = format->width; > > /* > - * Only Gen3 hardware requires image partitioning, Gen2 will operate > + * Only Gen3+ hardware requires image partitioning, Gen2 will operate > * with a single partition that covers the whole output. > */ > - if (vsp1->info->gen == 3) { > + if (vsp1->info->gen >= 3) { > list_for_each_entry(entity, &pipe->entities, list_pipe) { > unsigned int entity_max; > > diff --git a/drivers/media/platform/renesas/vsp1/vsp1_wpf.c b/drivers/media/platform/renesas/vsp1/vsp1_wpf.c > index 94e91d7bb56c..d0074ca00920 100644 > --- a/drivers/media/platform/renesas/vsp1/vsp1_wpf.c > +++ b/drivers/media/platform/renesas/vsp1/vsp1_wpf.c > @@ -512,10 +512,10 @@ static void wpf_configure_partition(struct vsp1_entity *entity, > } > > /* > - * On Gen3 hardware the SPUVS bit has no effect on 3-planar > + * On Gen3+ hardware the SPUVS bit has no effect on 3-planar > * formats. Swap the U and V planes manually in that case. > */ > - if (vsp1->info->gen == 3 && format->num_planes == 3 && > + if (vsp1->info->gen >= 3 && format->num_planes == 3 && > fmtinfo->swap_uv) > swap(mem.addr[1], mem.addr[2]); >
Hi Tomi, (CC'ing Daniel and Dave) On Wed, Dec 21, 2022 at 11:24:41AM +0200, Tomi Valkeinen wrote: > From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> > > Hi, > > These add new pixel formats for Renesas V3U and V4H SoCs. > > As the display pipeline is split between DRM and V4L2 components, this > series touches both subsystems. I'm sending all these together to > simplify review. If needed, I can later split this to V4L2 and DRM > parts, of which the V4L2 part needs to be merged first. As the changes on the DRM side are small and shouldn't conflict with anything else queued for v6.3, it would be easier to merge the whole series through the media tree. Daniel, Dave, would you be OK with that ? If so, could you please ack patches 6/7 and 7/7 ? > Changes in v3: > - Addressed all the review comments > - Added Y212 > - Updated the kernel docs for the new formats > - Changed the RGB format names to match the DRM's format names > - Updated RPF register field macros according to the comments > > Tomi > > Tomi Valkeinen (7): > media: Add 2-10-10-10 RGB formats > media: Add Y210, Y212 and Y216 formats > media: renesas: vsp1: Change V3U to be gen4 > media: renesas: vsp1: Add V4H SoC version > media: renesas: vsp1: Add new formats (2-10-10-10 ARGB, Y210, Y212) > drm: rcar-du: Bump V3U to gen 4 > drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210) > > .../media/v4l/pixfmt-packed-yuv.rst | 49 ++++- > .../userspace-api/media/v4l/pixfmt-rgb.rst | 194 ++++++++++++++++++ > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 30 +++ > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 50 ++++- > .../media/platform/renesas/vsp1/vsp1_drv.c | 4 +- > .../media/platform/renesas/vsp1/vsp1_hgo.c | 4 +- > .../media/platform/renesas/vsp1/vsp1_lif.c | 1 + > .../media/platform/renesas/vsp1/vsp1_pipe.c | 18 ++ > .../media/platform/renesas/vsp1/vsp1_regs.h | 26 ++- > .../media/platform/renesas/vsp1/vsp1_rpf.c | 64 +++++- > .../media/platform/renesas/vsp1/vsp1_video.c | 4 +- > .../media/platform/renesas/vsp1/vsp1_wpf.c | 4 +- > drivers/media/v4l2-core/v4l2-ioctl.c | 6 + > include/uapi/linux/videodev2.h | 11 + > 15 files changed, 447 insertions(+), 20 deletions(-)
On 26/12/2022 16:56, Laurent Pinchart wrote: > Hi Tomi, > > (CC'ing Daniel and Dave) > > On Wed, Dec 21, 2022 at 11:24:41AM +0200, Tomi Valkeinen wrote: >> From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> >> >> Hi, >> >> These add new pixel formats for Renesas V3U and V4H SoCs. >> >> As the display pipeline is split between DRM and V4L2 components, this >> series touches both subsystems. I'm sending all these together to >> simplify review. If needed, I can later split this to V4L2 and DRM >> parts, of which the V4L2 part needs to be merged first. > > As the changes on the DRM side are small and shouldn't conflict with > anything else queued for v6.3, it would be easier to merge the whole > series through the media tree. Daniel, Dave, would you be OK with that ? > If so, could you please ack patches 6/7 and 7/7 ? Note that these patches depend on the two DRM driver patches in "[PATCH v5 0/7] Renesas V4H DSI & DP output support", which are not very small (but still not big). I don't think there's a compile-time dependency between the DRM and V4L2 parts, but there's a functional side dependency, so it would be nice to merge these via a single tree. I can't say if DRM or V4L2 tree is easier, but I don't expect conflicts either way. Tomi
Hi Tomi, (CC'ing Mauro and Hans) On Tue, Jan 10, 2023 at 04:25:37PM +0200, Tomi Valkeinen wrote: > On 26/12/2022 16:56, Laurent Pinchart wrote: > > Hi Tomi, > > > > (CC'ing Daniel and Dave) > > > > On Wed, Dec 21, 2022 at 11:24:41AM +0200, Tomi Valkeinen wrote: > >> From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> > >> > >> Hi, > >> > >> These add new pixel formats for Renesas V3U and V4H SoCs. > >> > >> As the display pipeline is split between DRM and V4L2 components, this > >> series touches both subsystems. I'm sending all these together to > >> simplify review. If needed, I can later split this to V4L2 and DRM > >> parts, of which the V4L2 part needs to be merged first. > > > > As the changes on the DRM side are small and shouldn't conflict with > > anything else queued for v6.3, it would be easier to merge the whole > > series through the media tree. Daniel, Dave, would you be OK with that ? > > If so, could you please ack patches 6/7 and 7/7 ? > > Note that these patches depend on the two DRM driver patches in "[PATCH > v5 0/7] Renesas V4H DSI & DP output support", which are not very small > (but still not big). Good point. I'm thus leaning more towards merging this through the DRM tree then. Mauro, can we get your ack on the V4L2 part of this series ? We'll create a stable branch based on v6.2-rc1 in case it also need to be merged in the media tree due to last minute conflicts (I'm mainly thinking about the new formats). Hans, as there won't be a pull request through the media tree, if you want to review the new formats, now would be a good time. > I don't think there's a compile-time dependency between the DRM and V4L2 > parts, but there's a functional side dependency, so it would be nice to > merge these via a single tree. I can't say if DRM or V4L2 tree is > easier, but I don't expect conflicts either way.
Em Tue, 17 Jan 2023 15:38:25 +0200 Laurent Pinchart <laurent.pinchart@ideasonboard.com> escreveu: > Hi Tomi, > > (CC'ing Mauro and Hans) > > On Tue, Jan 10, 2023 at 04:25:37PM +0200, Tomi Valkeinen wrote: > > On 26/12/2022 16:56, Laurent Pinchart wrote: > > > Hi Tomi, > > > > > > (CC'ing Daniel and Dave) > > > > > > On Wed, Dec 21, 2022 at 11:24:41AM +0200, Tomi Valkeinen wrote: > > >> From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> > > >> > > >> Hi, > > >> > > >> These add new pixel formats for Renesas V3U and V4H SoCs. > > >> > > >> As the display pipeline is split between DRM and V4L2 components, this > > >> series touches both subsystems. I'm sending all these together to > > >> simplify review. If needed, I can later split this to V4L2 and DRM > > >> parts, of which the V4L2 part needs to be merged first. > > > > > > As the changes on the DRM side are small and shouldn't conflict with > > > anything else queued for v6.3, it would be easier to merge the whole > > > series through the media tree. Daniel, Dave, would you be OK with that ? > > > If so, could you please ack patches 6/7 and 7/7 ? > > > > Note that these patches depend on the two DRM driver patches in "[PATCH > > v5 0/7] Renesas V4H DSI & DP output support", which are not very small > > (but still not big). > > Good point. I'm thus leaning more towards merging this through the DRM > tree then. Mauro, can we get your ack on the V4L2 part of this series ? > We'll create a stable branch based on v6.2-rc1 in case it also need to > be merged in the media tree due to last minute conflicts (I'm mainly > thinking about the new formats). Feel free to merge the V4L2 patches via DRM tree with my ack: Acked-by: Mauro Carvalho Chehab <mchehab@kernel.org> > > Hans, as there won't be a pull request through the media tree, if you > want to review the new formats, now would be a good time. > > > I don't think there's a compile-time dependency between the DRM and V4L2 > > parts, but there's a functional side dependency, so it would be nice to > > merge these via a single tree. I can't say if DRM or V4L2 tree is > > easier, but I don't expect conflicts either way. > Thanks, Mauro
On 21/12/2022 10:24, Tomi Valkeinen wrote: > From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> > > Hi, > > These add new pixel formats for Renesas V3U and V4H SoCs. > > As the display pipeline is split between DRM and V4L2 components, this > series touches both subsystems. I'm sending all these together to > simplify review. If needed, I can later split this to V4L2 and DRM > parts, of which the V4L2 part needs to be merged first. > > Changes in v3: > - Addressed all the review comments > - Added Y212 > - Updated the kernel docs for the new formats > - Changed the RGB format names to match the DRM's format names > - Updated RPF register field macros according to the comments For this series: Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Thanks, Hans > > Tomi > > Tomi Valkeinen (7): > media: Add 2-10-10-10 RGB formats > media: Add Y210, Y212 and Y216 formats > media: renesas: vsp1: Change V3U to be gen4 > media: renesas: vsp1: Add V4H SoC version > media: renesas: vsp1: Add new formats (2-10-10-10 ARGB, Y210, Y212) > drm: rcar-du: Bump V3U to gen 4 > drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210) > > .../media/v4l/pixfmt-packed-yuv.rst | 49 ++++- > .../userspace-api/media/v4l/pixfmt-rgb.rst | 194 ++++++++++++++++++ > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 30 +++ > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 50 ++++- > .../media/platform/renesas/vsp1/vsp1_drv.c | 4 +- > .../media/platform/renesas/vsp1/vsp1_hgo.c | 4 +- > .../media/platform/renesas/vsp1/vsp1_lif.c | 1 + > .../media/platform/renesas/vsp1/vsp1_pipe.c | 18 ++ > .../media/platform/renesas/vsp1/vsp1_regs.h | 26 ++- > .../media/platform/renesas/vsp1/vsp1_rpf.c | 64 +++++- > .../media/platform/renesas/vsp1/vsp1_video.c | 4 +- > .../media/platform/renesas/vsp1/vsp1_wpf.c | 4 +- > drivers/media/v4l2-core/v4l2-ioctl.c | 6 + > include/uapi/linux/videodev2.h | 11 + > 15 files changed, 447 insertions(+), 20 deletions(-) >
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Hi, These add new pixel formats for Renesas V3U and V4H SoCs. As the display pipeline is split between DRM and V4L2 components, this series touches both subsystems. I'm sending all these together to simplify review. If needed, I can later split this to V4L2 and DRM parts, of which the V4L2 part needs to be merged first. Changes in v3: - Addressed all the review comments - Added Y212 - Updated the kernel docs for the new formats - Changed the RGB format names to match the DRM's format names - Updated RPF register field macros according to the comments Tomi Tomi Valkeinen (7): media: Add 2-10-10-10 RGB formats media: Add Y210, Y212 and Y216 formats media: renesas: vsp1: Change V3U to be gen4 media: renesas: vsp1: Add V4H SoC version media: renesas: vsp1: Add new formats (2-10-10-10 ARGB, Y210, Y212) drm: rcar-du: Bump V3U to gen 4 drm: rcar-du: Add new formats (2-10-10-10 ARGB, Y210) .../media/v4l/pixfmt-packed-yuv.rst | 49 ++++- .../userspace-api/media/v4l/pixfmt-rgb.rst | 194 ++++++++++++++++++ drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 30 +++ drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 50 ++++- .../media/platform/renesas/vsp1/vsp1_drv.c | 4 +- .../media/platform/renesas/vsp1/vsp1_hgo.c | 4 +- .../media/platform/renesas/vsp1/vsp1_lif.c | 1 + .../media/platform/renesas/vsp1/vsp1_pipe.c | 18 ++ .../media/platform/renesas/vsp1/vsp1_regs.h | 26 ++- .../media/platform/renesas/vsp1/vsp1_rpf.c | 64 +++++- .../media/platform/renesas/vsp1/vsp1_video.c | 4 +- .../media/platform/renesas/vsp1/vsp1_wpf.c | 4 +- drivers/media/v4l2-core/v4l2-ioctl.c | 6 + include/uapi/linux/videodev2.h | 11 + 15 files changed, 447 insertions(+), 20 deletions(-)