From: "Shuijing Li (李水静)" <Shuijing.Li@mediatek.com>
To: "chunkuang.hu@kernel.org" <chunkuang.hu@kernel.org>,
"Jitao Shi (石记涛)" <jitao.shi@mediatek.com>,
"daniel@ffwll.ch" <daniel@ffwll.ch>,
"p.zabel@pengutronix.de" <p.zabel@pengutronix.de>,
"CK Hu (胡俊光)" <ck.hu@mediatek.com>,
"airlied@gmail.com" <airlied@gmail.com>,
"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
"angelogioacchino.delregno@collabora.com"
<angelogioacchino.delregno@collabora.com>
Cc: "dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Project_Global_Chrome_Upstream_Group
<Project_Global_Chrome_Upstream_Group@mediatek.com>
Subject: Re: [PATCH] mediatek: dsi: Add dsi per-frame lp code for mt8188
Date: Wed, 24 Apr 2024 09:14:43 +0000 [thread overview]
Message-ID: <6a817e32cb2c2c9a65b6878a49f98578e7478b72.camel@mediatek.com> (raw)
In-Reply-To: <2a0a4d12edfc92d40d5ae463f8a261e8799ddafa.camel@mediatek.com>
Dear CK,
> As I know, some low power mode would has some side effect. For
> example,
> CPU dvfs would let CPU run in low frequency when CPU is idle, but
> when
> CPU is suddenly busy, it would take some time to let CPU frequency
> speed up and may cause some real time issue. Does this have any side
> effect. If so, please describe it.
>
==》This is not a CPU low-power feature, but a characteristic of DSI. It
maintains high speed without entering low power during the DSI active
period, which can save the time of entering and exiting low power,
without side effects.
Based on the feedback you provided, I have made the necessary changes
and would like to submit a version 2 for your consideration at a later
date.
Thank you for your time and attention to this matter.
Best regards,
Shuijing
On Wed, 2024-03-20 at 06:03 +0000, CK Hu (胡俊光) wrote:
> Hi, Shuijing:
>
> Add 'drm/' in the title.
>
> On Thu, 2024-03-14 at 17:41 +0800, Shuijing Li wrote:
> > Adding the per-frame lp function of mt8188, which can keep HFP in
> > HS
> > and
> > reduce the time required for each line to enter and exit low power.
> > Per Frame LP:
> > |<----------One Active Frame-------->|
> > --______________________________________----___________________
> > ^HSA+HBP^^RGB^^HFP^^HSA+HBP^^RGB^^HFP^ ^HSA+HBP^^RGB^^HFP^
> >
> > Per Line LP:
> > |<---------------One Active Frame----------->|
> > --______________--______________--______________----______________
> > ^HSA+HBP^^RGB^ ^HSA+HBP^^RGB^ ^HSA+HBP^^RGB^ ^HSA+HBP^^RGB^
>
> As I know, some low power mode would has some side effect. For
> example,
> CPU dvfs would let CPU run in low frequency when CPU is idle, but
> when
> CPU is suddenly busy, it would take some time to let CPU frequency
> speed up and may cause some real time issue. Does this have any side
> effect. If so, please describe it.
>
> >
> > Signed-off-by: Shuijing Li <shuijing.li@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_dsi.c | 100
> > +++++++++++++++++++++++++++++
> > 1 file changed, 100 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > index a2fdfc8ddb15..e6f4807c8711 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> > @@ -83,6 +83,7 @@
> > #define DSI_HSA_WC 0x50
> > #define DSI_HBP_WC 0x54
> > #define DSI_HFP_WC 0x58
> > +#define DSI_BLLP_WC 0x5C
> >
> > #define DSI_CMDQ_SIZE 0x60
> > #define CMDQ_SIZE 0x3f
> > @@ -180,6 +181,7 @@ struct mtk_dsi_driver_data {
> > bool has_shadow_ctl;
> > bool has_size_ctl;
> > bool cmdq_long_packet_ctl;
> > + bool support_per_frame_lp;
> > };
> >
> > struct mtk_dsi {
> > @@ -516,6 +518,103 @@ static void mtk_dsi_config_vdo_timing(struct
> > mtk_dsi *dsi)
> > (vm->hactive * dsi_tmp_buf_bpp + 2) % dsi-
> > > lanes;
> >
> > }
> >
> > + if (dsi->driver_data->support_per_frame_lp) {
> > + unsigned int lpx = 0, da_hs_exit = 0, da_hs_prep = 0,
> > da_hs_trail = 0;
> > + unsigned int da_hs_zero = 0, ps_wc = 0, hs_vb_ps_wc =
> > 0;
>
> It's not necessary to initialize to zero because these variable would
> be assigned to other value later.
>
> > + u32 bllp_wc, bllp_en, v_active_roundup, hstx_cklp_wc;
> > + u32 hstx_cklp_wc_max, hstx_cklp_wc_min;
> > +
> > + da_hs_trail = (readl(dsi->regs + DSI_PHY_TIMECON0) >>
> > 24) & 0xff;
>
> operator '>>' has higher priority than operator '&', so it's not
> necessary to add '()'.
>
> > + bllp_en = (readl(dsi->regs + DSI_TXRX_CTRL) >> 7) &
> > 0x1;
> > + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE) {
> > + horizontal_sync_active_byte =
> > + (vm->hsync_len * dsi_tmp_buf_bpp - 10);
>
> '()' is redundant.
>
> > + horizontal_backporch_byte =
> > + (vm->hback_porch * dsi_tmp_buf_bpp -
> > 10);
>
> ditto.
>
> > + horizontal_frontporch_byte =
> > + (vm->hfront_porch * dsi_tmp_buf_bpp -
> > 12);
>
> ditto.
>
> > +
> > + ps_wc = readl(dsi->regs + DSI_PSCTRL) & 0x7fff;
> > + v_active_roundup = (32 +
> > horizontal_sync_active_byte +
> > + horizontal_backporch_byte + ps_wc +
> > + horizontal_frontporch_byte) % dsi-
> > > lanes;
> >
> > + if (v_active_roundup)
> > + horizontal_backporch_byte =
> > horizontal_backporch_byte +
> > + dsi->lanes - v_active_roundup;
> > + hstx_cklp_wc_min = (DIV_ROUND_UP((12 + 2 + 4 +
> > + horizontal_sync_active_byte), dsi-
> > > lanes) + da_hs_trail + 1)
> >
> > + * dsi->lanes / 6 - 1;
> > + hstx_cklp_wc_max = (DIV_ROUND_UP((20 + 6 + 4 +
> > + horizontal_sync_active_byte +
> > horizontal_backporch_byte +
> > + ps_wc), dsi->lanes) + da_hs_trail + 1)
> > * dsi->lanes / 6 - 1;
> > + } else {
> > + horizontal_sync_active_byte = vm->hsync_len *
> > dsi_tmp_buf_bpp - 4;
> > +
> > + horizontal_backporch_byte = (vm->hback_porch +
> > vm->hsync_len) *
> > + dsi_tmp_buf_bpp - 10;
> > + hstx_cklp_wc_min = (DIV_ROUND_UP(4, dsi-
> > >lanes)
> > + da_hs_trail + 1)
> > + * dsi->lanes / 6 - 1;
> > +
> > + if (dsi->mode_flags &
> > MIPI_DSI_MODE_VIDEO_BURST) {
> > + ps_wc = readl(dsi->regs + DSI_PSCTRL) &
> > 0x7fff;
> > + bllp_wc = readl(dsi->regs +
> > DSI_BLLP_WC) & 0xfff;
> > + horizontal_frontporch_byte = (vm-
> > > hfront_porch *
> >
> > + dsi_tmp_buf_bpp - 18);
> > +
> > + v_active_roundup = (28 +
> > horizontal_backporch_byte + ps_wc +
> > + horizontal_frontporch_byte +
> > bllp_wc) % dsi->lanes;
> > + if (v_active_roundup)
> > + horizontal_backporch_byte =
> > horizontal_backporch_byte +
> > + dsi->lanes - v_active_roundup;
> > + if (bllp_en) {
> > + hstx_cklp_wc_max =
> > (DIV_ROUND_UP((16 + 6 + 4 +
> > + horizontal_backporch_by
> > te + bllp_wc + ps_wc),
> > + dsi->lanes) +
> > da_hs_trail + 1) * dsi->lanes / 6 - 1;
> > + } else {
> > + hstx_cklp_wc_max =
> > (DIV_ROUND_UP((12 + 4 + 4 +
> > + horizontal_backporch_by
> > te + bllp_wc + ps_wc),
> > + dsi->lanes) +
> > da_hs_trail + 1) * dsi->lanes / 6 - 1;
> > + }
> > + } else {
> > + ps_wc = readl(dsi->regs + DSI_PSCTRL) &
> > 0x7fff;
> > + horizontal_frontporch_byte = (vm-
> > > hfront_porch *
> >
> > + dsi_tmp_buf_bpp - 12);
> > +
> > + v_active_roundup = (22 +
> > horizontal_backporch_byte + ps_wc +
> > + horizontal_frontporch_byte) %
> > dsi->lanes;
> > + if (v_active_roundup)
> > + horizontal_backporch_byte =
> > horizontal_backporch_byte +
> > + dsi->lanes - v_active_roundup;
> > +
> > + hstx_cklp_wc_max = (DIV_ROUND_UP((12 +
> > 4 + 4 +
> > + horizontal_backporch_byte +
> > ps_wc),
> > + dsi->lanes) + da_hs_trail + 1)
> > * dsi->lanes / 6 - 1;
> > + }
> > + }
> > + hstx_cklp_wc = (readl(dsi->regs + DSI_HSTX_CKL_WC) >>
> > 2) & 0x3fff;
>
> Hardware register is set according to software variable, so you could
> get this value from software variable. DSI_HSTX_CKL_WC is set in
> mtk_dsi_ps_control_vact() as ps_wc, so you could use ps_wc instead of
> read it back from register.
>
> Regards,
> CK
>
> > + if (hstx_cklp_wc <= hstx_cklp_wc_min ||
> > + hstx_cklp_wc >= hstx_cklp_wc_max) {
> > + hstx_cklp_wc = (hstx_cklp_wc_max / 2) << 2;
> > + writel(hstx_cklp_wc, dsi->regs +
> > DSI_HSTX_CKL_WC);
> > + }
> > + hstx_cklp_wc = hstx_cklp_wc >> 2;
> > + if (hstx_cklp_wc <= hstx_cklp_wc_min ||
> > + hstx_cklp_wc >= hstx_cklp_wc_max) {
> > + DRM_WARN("Wrong setting of hstx_ckl_wc\n");
> > + }
> > +
> > + lpx = readl(dsi->regs + DSI_PHY_TIMECON0) & 0xff;
> > + da_hs_exit = (readl(dsi->regs + DSI_PHY_TIMECON1) >>
> > 24) & 0xff;
> > + da_hs_prep = (readl(dsi->regs + DSI_PHY_TIMECON0) >> 8)
> > & 0xff;
> > + da_hs_zero = (readl(dsi->regs + DSI_PHY_TIMECON0) >>
> > 16) & 0xff;
> > + ps_wc = readl(dsi->regs + DSI_PSCTRL) & 0x7fff;
> > + hs_vb_ps_wc = ps_wc -
> > + (lpx + da_hs_exit + da_hs_prep + da_hs_zero +
> > 2)
> > + * dsi->lanes;
> > + horizontal_frontporch_byte = (1 << 31)
> > + | (hs_vb_ps_wc << 16)
> > + | (horizontal_frontporch_byte);
> > + }
> > writel(horizontal_sync_active_byte, dsi->regs + DSI_HSA_WC);
> > writel(horizontal_backporch_byte, dsi->regs + DSI_HBP_WC);
> > writel(horizontal_frontporch_byte, dsi->regs + DSI_HFP_WC);
> > @@ -1246,6 +1345,7 @@ static const struct mtk_dsi_driver_data
> > mt8188_dsi_driver_data = {
> > .has_shadow_ctl = true,
> > .has_size_ctl = true,
> > .cmdq_long_packet_ctl = true,
> > + .support_per_frame_lp = true,
> > };
> >
> > static const struct of_device_id mtk_dsi_of_match[] = {
prev parent reply other threads:[~2024-04-24 9:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-14 9:41 [PATCH] mediatek: dsi: Add dsi per-frame lp code for mt8188 Shuijing Li
2024-03-14 10:10 ` AngeloGioacchino Del Regno
2024-04-24 9:14 ` Shuijing Li (李水静)
2024-03-20 6:03 ` CK Hu (胡俊光)
2024-04-24 9:14 ` Shuijing Li (李水静) [this message]
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=6a817e32cb2c2c9a65b6878a49f98578e7478b72.camel@mediatek.com \
--to=shuijing.li@mediatek.com \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=airlied@gmail.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=chunkuang.hu@kernel.org \
--cc=ck.hu@mediatek.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=jitao.shi@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=p.zabel@pengutronix.de \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).