[4/9] media: vsp1: Add support for missing 32-bit RGB formats
diff mbox series

Message ID 20190328070723.26553-5-laurent.pinchart+renesas@ideasonboard.com
State New
Delegated to: Kieran Bingham
Headers show
Series
  • R-Car DU: Add missing RGB pixel formats
Related show

Commit Message

Laurent Pinchart March 28, 2019, 7:07 a.m. UTC
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(+)

Comments

Jacopo Mondi April 4, 2019, 5:39 p.m. UTC | #1
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.

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
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?

Thanks
  j


>  	{ 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
>
Laurent Pinchart April 18, 2019, 6:06 a.m. UTC | #2
Hi Jacopo,

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 :-)

> 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.

> 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 :-().

> >  	{ 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,
Jacopo Mondi April 23, 2019, 1:21 p.m. UTC | #3
Hi Laurent,

On Thu, Apr 18, 2019 at 09:06:45AM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> 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?)

> > 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>

Thanks
   j

>
> > >  	{ 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
Laurent Pinchart April 23, 2019, 2:10 p.m. UTC | #4
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,

Patch
diff mbox series

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 },
 	{ 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,