From: Jacopo Mondi <jacopo@jmondi.org> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>, dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Maxime Ripard <maxime.ripard@bootlin.com> Subject: Re: [PATCH 4/9] media: vsp1: Add support for missing 32-bit RGB formats Date: Tue, 23 Apr 2019 15:21:53 +0200 [thread overview] Message-ID: <20190423132153.xfvy4dn3cflzotuf@uno.localdomain> (raw) In-Reply-To: <20190418060645.GC4806@pendragon.ideasonboard.com> [-- Attachment #1: Type: text/plain, Size: 4074 bytes --] 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Jacopo Mondi <jacopo@jmondi.org> To: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: linux-renesas-soc@vger.kernel.org, Maxime Ripard <maxime.ripard@bootlin.com>, Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>, dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org Subject: Re: [PATCH 4/9] media: vsp1: Add support for missing 32-bit RGB formats Date: Tue, 23 Apr 2019 15:21:53 +0200 [thread overview] Message-ID: <20190423132153.xfvy4dn3cflzotuf@uno.localdomain> (raw) In-Reply-To: <20190418060645.GC4806@pendragon.ideasonboard.com> [-- Attachment #1.1: Type: text/plain, Size: 4074 bytes --] 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 [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-04-23 13:21 UTC|newest] Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-03-28 7:07 [PATCH 0/9] R-Car DU: Add missing RGB pixel formats Laurent Pinchart 2019-03-28 7:07 ` Laurent Pinchart 2019-03-28 7:07 ` [PATCH 1/9] v4l: Add definitions for missing 32-bit RGB formats Laurent Pinchart 2019-03-28 7:07 ` Laurent Pinchart 2019-03-28 13:15 ` Jacopo Mondi 2019-03-28 13:15 ` Jacopo Mondi 2019-04-02 12:12 ` Laurent Pinchart 2019-04-02 12:12 ` Laurent Pinchart 2019-04-04 16:02 ` Jacopo Mondi 2019-04-04 16:02 ` Jacopo Mondi 2019-03-28 7:07 ` [PATCH 2/9] v4l: Add definitions for missing 16-bit RGB4444 formats Laurent Pinchart 2019-03-28 7:07 ` Laurent Pinchart 2019-04-04 16:00 ` Jacopo Mondi 2019-04-04 16:00 ` Jacopo Mondi 2019-04-18 5:57 ` Laurent Pinchart 2019-04-18 5:57 ` Laurent Pinchart 2019-07-09 12:56 ` Hans Verkuil 2019-07-09 12:56 ` Hans Verkuil 2019-03-28 7:07 ` [PATCH 3/9] v4l: Add definitions for missing 16-bit RGB555 formats Laurent Pinchart 2019-03-28 7:07 ` Laurent Pinchart 2019-04-04 15:57 ` Jacopo Mondi 2019-04-04 15:57 ` Jacopo Mondi 2019-04-18 6:25 ` Laurent Pinchart 2019-04-18 6:25 ` Laurent Pinchart 2019-04-18 6:27 ` [PATCH v1.1 " Laurent Pinchart 2019-04-18 6:27 ` Laurent Pinchart 2019-04-23 11:53 ` Jacopo Mondi 2019-04-23 11:53 ` Jacopo Mondi 2019-03-28 7:07 ` [PATCH 4/9] media: vsp1: Add support for missing 32-bit RGB formats Laurent Pinchart 2019-03-28 7:07 ` Laurent Pinchart 2019-04-04 17:39 ` Jacopo Mondi 2019-04-04 17:39 ` Jacopo Mondi 2019-04-18 6:06 ` Laurent Pinchart 2019-04-18 6:06 ` Laurent Pinchart 2019-04-23 13:21 ` Jacopo Mondi [this message] 2019-04-23 13:21 ` Jacopo Mondi 2019-04-23 14:10 ` Laurent Pinchart 2019-04-23 14:10 ` Laurent Pinchart 2019-03-28 7:07 ` [PATCH 5/9] media: vsp1: Add support for missing 16-bit RGB444 formats Laurent Pinchart 2019-03-28 7:07 ` Laurent Pinchart 2019-04-23 13:38 ` Jacopo Mondi 2019-04-23 13:38 ` Jacopo Mondi 2019-03-28 7:07 ` [PATCH 6/9] media: vsp1: Add support for missing 16-bit RGB555 formats Laurent Pinchart 2019-03-28 7:07 ` Laurent Pinchart 2019-04-23 13:55 ` Jacopo Mondi 2019-04-23 13:55 ` Jacopo Mondi 2019-04-23 14:46 ` Laurent Pinchart 2019-04-23 14:46 ` Laurent Pinchart 2019-04-23 16:56 ` Jacopo Mondi 2019-04-23 16:56 ` Jacopo Mondi 2019-04-23 19:29 ` Laurent Pinchart 2019-04-23 19:29 ` Laurent Pinchart 2019-03-28 7:07 ` [PATCH 7/9] drm: rcar-du: Add support for missing 32-bit RGB formats Laurent Pinchart 2019-03-28 7:07 ` Laurent Pinchart 2019-04-23 14:05 ` Jacopo Mondi 2019-04-23 14:05 ` Jacopo Mondi 2019-03-28 7:07 ` [PATCH 8/9] drm: rcar-du: Add support for missing 16-bit RGB4444 formats Laurent Pinchart 2019-03-28 7:07 ` Laurent Pinchart 2019-04-23 14:06 ` Jacopo Mondi 2019-04-23 14:06 ` Jacopo Mondi 2019-03-28 7:07 ` [PATCH 9/9] drm: rcar-du: Add support for missing 16-bit RGB1555 formats Laurent Pinchart 2019-03-28 7:07 ` Laurent Pinchart 2019-04-23 14:09 ` Jacopo Mondi 2019-04-23 14:09 ` Jacopo Mondi 2019-04-20 13:09 ` [PATCH 0/9] R-Car DU: Add missing RGB pixel formats Laurent Pinchart 2019-04-20 13:09 ` Laurent Pinchart
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190423132153.xfvy4dn3cflzotuf@uno.localdomain \ --to=jacopo@jmondi.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=laurent.pinchart+renesas@ideasonboard.com \ --cc=laurent.pinchart@ideasonboard.com \ --cc=linux-media@vger.kernel.org \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=maxime.ripard@bootlin.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.