Re: [PATCH 4/9] media: vsp1: Add support for missing 32-bit RGB formats

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Jacopo,

On Tue, Apr 23, 2019 at 03:21:53PM +0200, Jacopo Mondi wrote:
> On Thu, Apr 18, 2019 at 09:06:45AM +0300, Laurent Pinchart wrote:
> > On Thu, Apr 04, 2019 at 07:39:05PM +0200, Jacopo Mondi wrote:
> >> HI Laurent,
> >>   if you help me out understanding the bit swapping procedure in VSP
> >> I would be more confident in saying I actually reviewed the series.
> >
> > I'll try my best :-)
> 
> Thanks!
> 
> >> On Thu, Mar 28, 2019 at 09:07:18AM +0200, Laurent Pinchart wrote:
> >>> Add support for the V4L2_PIX_FMT_BGRA32, V4L2_PIX_FMT_BGRX32,
> >>> V4L2_PIX_FMT_RGBA32 and V4L2_PIX_FMT_RGBX32 formats to the VSP driver.
> >>>
> >>> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> >>> ---
> >>>  drivers/media/platform/vsp1/vsp1_pipe.c | 14 ++++++++++++++
> >>>  1 file changed, 14 insertions(+)
> >>>
> >>> diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c b/drivers/media/platform/vsp1/vsp1_pipe.c
> >>> index 54ff539ffea0..9f08d85e89d7 100644
> >>> --- a/drivers/media/platform/vsp1/vsp1_pipe.c
> >>> +++ b/drivers/media/platform/vsp1/vsp1_pipe.c
> >>> @@ -68,6 +68,20 @@ static const struct vsp1_format_info vsp1_video_formats[] = {
> >>>  	{ V4L2_PIX_FMT_XBGR32, MEDIA_BUS_FMT_ARGB8888_1X32,
> >>>  	  VI6_FMT_ARGB_8888, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> >>>  	  1, { 32, 0, 0 }, false, false, 1, 1, false },
> >>> +	{ V4L2_PIX_FMT_BGRA32, MEDIA_BUS_FMT_ARGB8888_1X32,
> >>> +	  VI6_FMT_RGBA_8888, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> >>> +	  1, { 32, 0, 0 }, false, false, 1, 1, true },
> >>> +	{ V4L2_PIX_FMT_BGRX32, MEDIA_BUS_FMT_ARGB8888_1X32,
> >>> +	  VI6_FMT_RGBA_8888, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS,
> >>> +	  1, { 32, 0, 0 }, false, false, 1, 1, false },
> >>> +	{ V4L2_PIX_FMT_RGBA32, MEDIA_BUS_FMT_ARGB8888_1X32,
> >>> +	  VI6_FMT_RGBA_8888, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> >>> +	  VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
> >>> +	  1, { 32, 0, 0 }, false, false, 1, 1, true },
> >>> +	{ V4L2_PIX_FMT_RGBX32, MEDIA_BUS_FMT_ARGB8888_1X32,
> >>> +	  VI6_FMT_RGBA_8888, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> >>> +	  VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,
> >>> +	  1, { 32, 0, 0 }, false, false, 1, 1, false },
> >>
> >>
> >> So, this is how I interpret the above lines for format BGRA32 (the
> >> same applies to RGBA32 fwiw)
> >>
> >>         Bytes:          B3      B2      B1      B0
> >> Input: ARGB8888_1X32:   A       R       G       B
> >
> > Note that, at the bus level, there's no byte ordering. Data is
> > transmitted in parallel on a 32-bit bus (at least as far as I know). But
> > this doesn't matter much anyway.
> 
> Indeed, but I should not use this as the description of the input
> format but VI6_FMT_RGBA_8888, as you pointed out, which reads indeed
> as RGBA (out of curiosity, what is the mbus code used for then?)

In the VSP case the media bus format is used to differenciate between
YUV and RGB. Internally after the RPF and before the WPF everything is
transmitted with 32 bits per pixel.

> >> Out:   BGRA32           R       G       B       A
> >>
> >> If I apply LLS and LWS on the "Input Row", according to the table I get
> >>
> >>  Position in Table 32.10:    0  1  2  3
> >>  IN Components ordering:     A  R  G  B  (ARGB8888_1X32
> >>  Position in Table 32.10:    3  2  1  0  (with LLS and LWS applied)
> >>  OUT Components ordering:    B  G  R  A
> >>
> >> Which to me is the ordering of components of the format named
> >> V4L2_PIX_FMT_ARGB32 and not BGRA32 which is instead, as reported RGBA
> >> (GREAT naming here!)
> >>
> >> What am I doing wrong?
> >
> > You need to take entry VI6_FMT_RGBA_8888 (0x14) in table 32.10, which
> > reads R G B A. Applying LLS and LWS but not WDS and BTS swaps the bytes
> > to A B G R (see table 32.13), so the pixel is written to memory in the A
> > B G R order, corresponding to V4L2_PIX_FMT_BGRA32 (I agree with you
> > about the insane naming for the 4CC, but that's not my fault :-().
> 
> Thanks, now that I applied flags to the correct input format, the
> patch seems correct to me.
> 
> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
> 
> >>>  	{ V4L2_PIX_FMT_ARGB32, MEDIA_BUS_FMT_ARGB8888_1X32,
> >>>  	  VI6_FMT_ARGB_8888, VI6_RPF_DSWAP_P_LLS | VI6_RPF_DSWAP_P_LWS |
> >>>  	  VI6_RPF_DSWAP_P_WDS | VI6_RPF_DSWAP_P_BTS,

-- 
Regards,

Laurent Pinchart