From: Jagan Teki <jagan@amarulasolutions.com>
To: Marek Vasut <marex@denx.de>
Cc: dri-devel@lists.freedesktop.org,
linux-samsung-soc@vger.kernel.org,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
Joonyoung Shim <jy0922.shim@samsung.com>,
Tommaso Merciai <tommaso.merciai@amarulasolutions.com>,
linux-amarula <linux-amarula@amarulasolutions.com>,
Seung-Woo Kim <sw0312.kim@samsung.com>,
Neil Armstrong <narmstrong@linaro.org>,
Frieder Schrempf <frieder.schrempf@kontron.de>,
Kyungmin Park <kyungmin.park@samsung.com>,
Matteo Lisi <matteo.lisi@engicam.com>,
Robert Foss <robert.foss@linaro.org>,
Andrzej Hajda <andrzej.hajda@intel.com>,
NXP Linux Team <linux-imx@nxp.com>,
Fancy Fang <chen.fang@nxp.com>,
Michael Nazzareno Trimarchi <michael@amarulasolutions.com>,
Adam Ford <aford173@gmail.com>,
linux-arm-kernel@lists.infradead.org,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH v7 07/10] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts
Date: Mon, 7 Nov 2022 22:30:30 +0530 [thread overview]
Message-ID: <CAMty3ZAM+fetmBQWaSbfjME7-Up4h+Ln3BRHaPgg5tuSsObPdw@mail.gmail.com> (raw)
In-Reply-To: <2f0c2dae-07c9-814b-a252-5fdd3e0d9dda@denx.de>
Hi Marek,
On Fri, Nov 4, 2022 at 12:28 AM Marek Vasut <marex@denx.de> wrote:
>
> On 11/3/22 18:27, Jagan Teki wrote:
> > On Thu, Nov 3, 2022 at 9:56 PM Marek Vasut <marex@denx.de> wrote:
> >>
> >> On 11/3/22 10:39, Jagan Teki wrote:
> >>> On Sun, Oct 16, 2022 at 3:31 AM Marek Vasut <marex@denx.de> wrote:
> >>>>
> >>>> On 10/5/22 17:13, Jagan Teki wrote:
> >>>>
> >>>> [...]
> >>>>
> >>>>> @@ -1321,6 +1322,32 @@ static void samsung_dsim_atomic_post_disable(struct drm_bridge *bridge,
> >>>>> pm_runtime_put_sync(dsi->dev);
> >>>>> }
> >>>>>
> >>>>> +#define MAX_INPUT_SEL_FORMATS 1
> >>>>> +
> >>>>> +static u32 *
> >>>>> +samsung_dsim_atomic_get_input_bus_fmts(struct drm_bridge *bridge,
> >>>>> + struct drm_bridge_state *bridge_state,
> >>>>> + struct drm_crtc_state *crtc_state,
> >>>>> + struct drm_connector_state *conn_state,
> >>>>> + u32 output_fmt,
> >>>>> + unsigned int *num_input_fmts)
> >>>>> +{
> >>>>> + u32 *input_fmts;
> >>>>> +
> >>>>> + *num_input_fmts = 0;
> >>>>> +
> >>>>> + input_fmts = kcalloc(MAX_INPUT_SEL_FORMATS, sizeof(*input_fmts),
> >>>>> + GFP_KERNEL);
> >>>>> + if (!input_fmts)
> >>>>> + return NULL;
> >>>>> +
> >>>>> + /* This is the DSI-end bus format */
> >>>>> + input_fmts[0] = MEDIA_BUS_FMT_RGB888_1X24;
> >>>>> + *num_input_fmts = 1;
> >>>>
> >>>> Is this the only supported format ? NXP AN13573 lists the following:
> >>>>
> >>>> i.MX 8/RT MIPI DSI/CSI-2, Rev. 0, 21 March 2022
> >>>> 3.7.4 Pixel formats
> >>>> Table 14. DSI pixel packing formats
> >>>>
> >>>> Loosely Packed Pixel Stream, 20-bit YCbCr, 4:2:2
> >>>> Packed Pixel Stream, 24-bit YCbCr, 4:2:2
> >>>> Packed Pixel Stream, 16-bit YCbCr, 4:2:2
> >>>
> >>> Look like these are unsupported in media-bus-format.h list.
> >>
> >> Aren't those:
> >>
> >> MEDIA_BUS_FMT_UYVY12_1X24
> >
> > Why is UYVY12 - YCbCr, 4:2:2 is 4+2+2 = 8 then it has UYVY8 ?
>
> (someone please correct me if I'm totally wrong here)
>
> The 12 is channel width (12 bit for each Y1/Y2/U/V channel sample).
> The 4:2:2 is subsampling (where are the color components sampled
> relative to brightness component).
>
> Picture is here:
> https://upload.wikimedia.org/wikipedia/commons/f/f2/Common_chroma_subsampling_ratios.svg
>
> Each Y square of the left is 12bit sample.
> Each U+V square is 12bit sample for U and 12bit sample for V.
>
> In case of 4:4:4 subsampling, each luminance (brightness) component has
> matching chrominance (color) components.
>
> In case of the 4:2:2 subsampling, two neighboring luminance components
> share two chrominance components. To transfer one pixel including color
> information, you have to transfer two pixels, Y0+U as 2x12bit sample in
> one cycle of 24bit bus, and then Y1+V as 2x12bit sample in another cycle
> of 24bit bus (2 clock cycles total, 4 samples total). From that you can
> reconstruct the two top-left squares (purple pixels) in the rightmost
> YUV column of 4:2:2 row.
>
> The entire trick is that because eye is less sensitive to color than it
> is to light, you can transfer less color information and thus save
> bandwidth without anyone noticing (much of it).
>
> >> MEDIA_BUS_FMT_UYVY8_1X16
> >
> > If YCbCr is UYVY (I still don't get this notation, sorry) then Packed
> > Pixel Stream, 24-bit YCbCr, 4:2:2 with 2 Pixels per packet from Table
> > 14 can be
> >
> > MEDIA_BUS_FMT_UYVY8_2X24
> > (YCbCr 4:2:2 is UYVY8)
> >
> > " based on a reference example from media bus format doc
> > 4.13.3.4.1.1.3. Packed YUV Formats, For instance, a format where
> > pixels are encoded as 8-bit YUV values downsampled to 4:2:2 and
> > transferred as 2 8-bit bus samples per pixel in the U, Y, V, Y order
> > will be named MEDIA_BUS_FMT_UYVY8_2X8."
>
> The way I read the above is that the channel width of each channel is
> 8-bit , so you start with two pixels Y0/U/Y1/V which add up to 32bit
> total. That is transferred over 8-bit bus, in 4 bus cycles total. One
> pixel therefore takes 2 cycles of the 8 bit bus to transfer, even if you
> cannot transfer one pixel separately .
>
> > https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/subdev-formats.html
> >
> > _2X24 here 2 Pixels per packet is the exact packets to consider or we
> > can consider 1 Pixel per packet also. If later is true then _1X24 from
> > your notation is correct.
>
> Since the DSIM input bus is 32bit wide, to transfer one such 4:2:2
> pixel, you need 1 bus cycle (2x12 bits per half of two pixels).
Thanks for your explanation. I need some time to understand and it
looks worth waiting for others to comment on this.
Meanwhile, I'm planning to send subsequent version patches with
possible supported formats like,
MEDIA_BUS_FMT_UYVY8_1X16,
MEDIA_BUS_FMT_RGB101010_1X30,
MEDIA_BUS_FMT_RGB121212_1X36,
MEDIA_BUS_FMT_RGB565_1X16,
MEDIA_BUS_FMT_RGB666_1X18,
MEDIA_BUS_FMT_RGB888_1X24,
Let me know.
Jagan.
next prev parent reply other threads:[~2022-11-07 17:00 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20221005151323eucas1p2c69fc9989b84a9d74d568469ccd81f35@eucas1p2.samsung.com>
2022-10-05 15:12 ` [PATCH v7 00/10] drm: bridge: Add Samsung MIPI DSIM bridge Jagan Teki
2022-10-05 15:13 ` [PATCH v7 01/10] drm: bridge: Add Samsung DSIM bridge driver Jagan Teki
2022-10-15 21:46 ` Marek Vasut
2022-10-17 2:49 ` Jagan Teki
2022-10-17 7:19 ` Marek Vasut
2022-10-17 7:43 ` Jagan Teki
2022-10-17 8:48 ` Marek Vasut
2022-10-17 9:01 ` Marek Szyprowski
2022-10-18 3:05 ` Jagan Teki
2022-10-28 12:12 ` Jagan Teki
2022-10-05 15:13 ` [PATCH v7 02/10] drm: bridge: samsung-dsim: Lookup OF-graph or Child node devices Jagan Teki
2022-10-15 21:48 ` Marek Vasut
2022-10-17 2:52 ` Jagan Teki
2022-10-05 15:13 ` [PATCH v7 03/10] drm: bridge: samsung-dsim: Mark PHY as optional Jagan Teki
2022-10-15 21:50 ` Marek Vasut
2022-10-05 15:13 ` [PATCH v7 04/10] drm: bridge: samsung-dsim: Handle proper DSI host initialization Jagan Teki
2022-10-05 15:13 ` [PATCH v7 05/10] drm: bridge: samsung-dsim: Add atomic_check Jagan Teki
2022-10-15 21:23 ` Marek Vasut
2022-10-17 3:54 ` Jagan Teki
2022-10-17 7:23 ` Marek Vasut
2022-10-17 7:51 ` Jagan Teki
2022-10-05 15:13 ` [PATCH v7 06/10] drm: bridge: samsung-dsim: Add platform PLL_P (PMS_P) offset Jagan Teki
2022-10-15 21:56 ` Marek Vasut
2022-10-05 15:13 ` [PATCH v7 07/10] drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts Jagan Teki
2022-10-15 22:01 ` Marek Vasut
2022-10-17 3:58 ` Jagan Teki
2022-10-17 7:24 ` Marek Vasut
2022-11-03 7:40 ` Jagan Teki
2022-11-03 16:03 ` Marek Vasut
2022-11-03 9:39 ` Jagan Teki
2022-11-03 16:02 ` Marek Vasut
2022-11-03 17:27 ` Jagan Teki
2022-11-03 18:58 ` Marek Vasut
2022-11-07 17:00 ` Jagan Teki [this message]
2022-10-05 15:13 ` [PATCH v7 08/10] drm: bridge: samsung-dsim: Add input_bus_flags Jagan Teki
2022-10-15 21:37 ` Marek Vasut
2022-10-05 15:13 ` [PATCH v7 09/10] dt-bindings: display: exynos: dsim: Add NXP i.MX8MM support Jagan Teki
2022-10-15 22:02 ` Marek Vasut
2022-10-05 15:13 ` [PATCH v7 10/10] drm: bridge: samsung-dsim: Add " Jagan Teki
2022-10-15 21:30 ` Marek Vasut
2022-10-05 20:51 ` [PATCH v7 00/10] drm: bridge: Add Samsung MIPI DSIM bridge Marek Szyprowski
2022-10-06 14:21 ` Jagan Teki
2022-10-06 15:26 ` Tim Harvey
2022-10-19 10:16 ` Marcel Ziswiler
2022-10-20 9:20 ` Robert Foss
2022-10-24 8:44 ` Alexander Stein
2022-10-28 14:37 ` Sébastien Szymanski
2022-11-07 16:34 ` Frieder Schrempf
2022-11-10 15:54 ` Fabio Estevam
2022-11-10 16:03 ` Jagan Teki
2022-11-10 16:59 ` Marek Vasut
2022-11-10 17:37 ` Jagan Teki
2022-11-10 17:41 ` Marek Vasut
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=CAMty3ZAM+fetmBQWaSbfjME7-Up4h+Ln3BRHaPgg5tuSsObPdw@mail.gmail.com \
--to=jagan@amarulasolutions.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=aford173@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=chen.fang@nxp.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=frieder.schrempf@kontron.de \
--cc=jy0922.shim@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-amarula@amarulasolutions.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=marex@denx.de \
--cc=matteo.lisi@engicam.com \
--cc=michael@amarulasolutions.com \
--cc=narmstrong@linaro.org \
--cc=robert.foss@linaro.org \
--cc=sw0312.kim@samsung.com \
--cc=tommaso.merciai@amarulasolutions.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).