From: Lucas Stach <l.stach@pengutronix.de>
To: Adam Ford <aford173@gmail.com>, dri-devel@lists.freedesktop.org
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
aford@beaconembedded.com,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
Andrzej Hajda <andrzej.hajda@intel.com>,
Fabio Estevam <festevam@gmail.com>,
m.szyprowski@samsung.com, marex@denx.de,
Robert Foss <rfoss@kernel.org>, David Airlie <airlied@gmail.com>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Jagan Teki <jagan@amarulasolutions.com>,
NXP Linux Team <linux-imx@nxp.com>,
devicetree@vger.kernel.org, Daniel Vetter <daniel@ffwll.ch>,
Jonas Karlman <jonas@kwiboo.se>,
Sascha Hauer <s.hauer@pengutronix.de>,
Inki Dae <inki.dae@samsung.com>, Rob Herring <robh+dt@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Neil Armstrong <neil.armstrong@linaro.org>,
linux-kernel@vger.kernel.org,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Shawn Guo <shawnguo@kernel.org>
Subject: Re: [PATCH 1/6] drm: bridge: samsung-dsim: Support multi-lane calculations
Date: Mon, 17 Apr 2023 10:43:25 +0200 [thread overview]
Message-ID: <3e47f0d1017fe4c9f71a5de65f32c6ba1662efe2.camel@pengutronix.de> (raw)
In-Reply-To: <20230415104104.5537-1-aford173@gmail.com>
Hi Adam,
Am Samstag, dem 15.04.2023 um 05:40 -0500 schrieb Adam Ford:
> If there is more than one lane, the HFP, HBP, and HSA is calculated in
> bytes/pixel, then they are divided amongst the different lanes with some
> additional overhead. This is necessary to achieve higher resolutions while
> keeping the pixel clocks lower as the number of lanes increase.
>
In the testing I did to come up with my patch "drm: bridge: samsung-
dsim: fix blanking packet size calculation" the number of lanes didn't
make any difference. My testing might be flawed, as I could only
measure the blanking after translation from MIPI DSI to DPI, so I'm
interested to know what others did here. How did you validate the
blanking with your patch? Would you have a chance to test my patch and
see if it works or breaks in your setup?
Regards,
Lucas
> Signed-off-by: Adam Ford <aford173@gmail.com>
> ---
> drivers/gpu/drm/bridge/samsung-dsim.c | 40 +++++++++++++++++++++++----
> 1 file changed, 34 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> index e0a402a85787..1ccbad4ea577 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -215,6 +215,7 @@
> #define DSI_RX_FIFO_SIZE 256
> #define DSI_XFER_TIMEOUT_MS 100
> #define DSI_RX_FIFO_EMPTY 0x30800002
> +#define DSI_HSYNC_PKT_OVERHEAD 6
>
> #define OLD_SCLK_MIPI_CLK_NAME "pll_clk"
>
> @@ -879,13 +880,40 @@ static void samsung_dsim_set_display_mode(struct samsung_dsim *dsi)
> | DSIM_MAIN_VBP(m->vtotal - m->vsync_end);
> samsung_dsim_write(dsi, DSIM_MVPORCH_REG, reg);
>
> - reg = DSIM_MAIN_HFP(m->hsync_start - m->hdisplay)
> - | DSIM_MAIN_HBP(m->htotal - m->hsync_end);
> - samsung_dsim_write(dsi, DSIM_MHPORCH_REG, reg);
> + /*
> + * If there is more than one lane, the HFP, HBP, and HSA
> + * is calculated in bytes/pixel, then they are divided
> + * amongst the different lanes with some additional
> + * overhead correction
> + */
> + if (dsi->lanes > 1) {
> + u32 hfp, hbp, hsa;
> + int bpp = mipi_dsi_pixel_format_to_bpp(dsi->format) / 8;
> +
> + hfp = ((m->hsync_start - m->hdisplay) * bpp) / dsi->lanes;
> + hfp -= (hfp > DSI_HSYNC_PKT_OVERHEAD) ? DSI_HSYNC_PKT_OVERHEAD : 0;
> +
> + hbp = ((m->htotal - m->hsync_end) * bpp) / dsi->lanes;
> + hbp -= (hbp > DSI_HSYNC_PKT_OVERHEAD) ? DSI_HSYNC_PKT_OVERHEAD : 0;
>
> - reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start)
> - | DSIM_MAIN_HSA(m->hsync_end - m->hsync_start);
> - samsung_dsim_write(dsi, DSIM_MSYNC_REG, reg);
> + hsa = ((m->hsync_end - m->hsync_start) * bpp) / dsi->lanes;
> + hsa -= (hsa > DSI_HSYNC_PKT_OVERHEAD) ? DSI_HSYNC_PKT_OVERHEAD : 0;
> +
> + reg = DSIM_MAIN_HFP(hfp) | DSIM_MAIN_HBP(hbp);
> + samsung_dsim_write(dsi, DSIM_MHPORCH_REG, reg);
> +
> + reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start)
> + | DSIM_MAIN_HSA(hsa);
> + samsung_dsim_write(dsi, DSIM_MSYNC_REG, reg);
> + } else {
> + reg = DSIM_MAIN_HFP(m->hsync_start - m->hdisplay)
> + | DSIM_MAIN_HBP(m->htotal - m->hsync_end);
> + samsung_dsim_write(dsi, DSIM_MHPORCH_REG, reg);
> +
> + reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start)
> + | DSIM_MAIN_HSA(m->hsync_end - m->hsync_start);
> + samsung_dsim_write(dsi, DSIM_MSYNC_REG, reg);
> + }
> }
> reg = DSIM_MAIN_HRESOL(m->hdisplay, num_bits_resol) |
> DSIM_MAIN_VRESOL(m->vdisplay, num_bits_resol);
next prev parent reply other threads:[~2023-04-17 8:43 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-15 10:40 [PATCH 1/6] drm: bridge: samsung-dsim: Support multi-lane calculations Adam Ford
2023-04-15 10:40 ` [PATCH 2/6] drm: bridge: samsung-dsim: Fix PMS Calculator on imx8m[mnp] Adam Ford
2023-04-16 22:07 ` Marek Vasut
2023-04-16 22:31 ` Adam Ford
2023-04-17 7:00 ` Alexander Stein
2023-04-18 11:53 ` Adam Ford
2023-04-20 19:15 ` Adam Ford
2023-04-15 10:41 ` [PATCH 3/6] drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically Adam Ford
2023-04-16 22:08 ` Marek Vasut
2023-04-18 2:29 ` Adam Ford
2023-04-18 8:30 ` Marek Vasut
2023-04-18 8:47 ` Lucas Stach
2023-04-19 10:41 ` Adam Ford
2023-04-21 11:25 ` Marek Szyprowski
2023-04-21 11:44 ` Adam Ford
2023-04-15 10:41 ` [PATCH 4/6] drm: bridge: samsung-dsim: Dynamically configure DPHY timing Adam Ford
2023-04-16 22:12 ` Marek Vasut
2023-04-17 8:37 ` Lucas Stach
2023-04-17 11:53 ` Adam Ford
2023-04-18 2:43 ` Adam Ford
2023-04-15 10:41 ` [PATCH 5/6] drm: bridge: samsung-dsim: Support non-burst mode Adam Ford
2023-04-16 22:13 ` Marek Vasut
2023-04-17 11:57 ` Adam Ford
2023-04-17 20:07 ` Marek Vasut
2023-04-17 22:24 ` Adam Ford
2023-04-17 23:23 ` Marek Vasut
2023-04-20 2:24 ` Adam Ford
2023-04-15 10:41 ` [PATCH 6/6] arm64: dts: imx8mn: Fix video clock parents Adam Ford
2023-04-16 22:02 ` [PATCH 1/6] drm: bridge: samsung-dsim: Support multi-lane calculations Marek Vasut
2023-04-17 8:43 ` Lucas Stach [this message]
2023-04-17 11:55 ` Adam Ford
2023-04-19 10:47 ` Adam Ford
2023-04-20 13:06 ` Lucas Stach
2023-04-20 13:24 ` Adam Ford
2023-04-20 13:42 ` Lucas Stach
2023-04-20 21:51 ` Adam Ford
2023-04-21 8:40 ` Lucas Stach
2023-04-21 11:28 ` Marek Szyprowski
2023-04-21 11:41 ` Adam Ford
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=3e47f0d1017fe4c9f71a5de65f32c6ba1662efe2.camel@pengutronix.de \
--to=l.stach@pengutronix.de \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=aford173@gmail.com \
--cc=aford@beaconembedded.com \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=festevam@gmail.com \
--cc=inki.dae@samsung.com \
--cc=jagan@amarulasolutions.com \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=kernel@pengutronix.de \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=marex@denx.de \
--cc=neil.armstrong@linaro.org \
--cc=rfoss@kernel.org \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
/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).