From: "Heiko Stübner" <heiko@sntech.de>
To: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>,
Maxime Ripard <mripard@kernel.org>
Cc: Sandy Huang <hjc@rock-chips.com>,
Andy Yan <andy.yan@rock-chips.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
kernel@collabora.com, dri-devel@lists.freedesktop.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
FUKAUMI Naoki <naoki@radxa.com>
Subject: Re: [PATCH v2 3/5] drm/rockchip: vop2: Improve display modes handling on RK3588 HDMI0
Date: Wed, 11 Dec 2024 18:23:03 +0100 [thread overview]
Message-ID: <1820767.5KxKD5qtyk@diego> (raw)
In-Reply-To: <64vc5pkj44w3qxf5wkcxgghpwhvoagzemcsfqmi7fhsxt7vlqd@yfcgloi45ygh>
Am Mittwoch, 11. Dezember 2024, 18:07:57 CET schrieb Maxime Ripard:
> On Wed, Dec 11, 2024 at 12:15:07PM +0200, Cristian Ciocaltea wrote:
> > The RK3588 specific implementation is currently quite limited in terms
> > of handling the full range of display modes supported by the connected
> > screens, e.g. 2560x1440@75Hz, 2048x1152@60Hz, 1024x768@60Hz are just a
> > few of them.
> >
> > Additionally, it doesn't cope well with non-integer refresh rates like
> > 59.94, 29.97, 23.98, etc.
> >
> > Make use of HDMI0 PHY PLL as a more accurate DCLK source to handle
> > all display modes up to 4K@60Hz.
> >
> > Tested-by: FUKAUMI Naoki <naoki@radxa.com>
> > Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> > ---
> > drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 34 ++++++++++++++++++++++++++++
> > 1 file changed, 34 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > index 8b2f53ffefdbf1cc8737b3a86e630a03a7fd9348..393fe6aa170aaee9663c4a6d98c1cd6a5ef79392 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > @@ -158,6 +158,7 @@ struct vop2_video_port {
> > struct drm_crtc crtc;
> > struct vop2 *vop2;
> > struct clk *dclk;
> > + struct clk *dclk_src;
> > unsigned int id;
> > const struct vop2_video_port_data *data;
> >
> > @@ -212,6 +213,7 @@ struct vop2 {
> > struct clk *hclk;
> > struct clk *aclk;
> > struct clk *pclk;
> > + struct clk *pll_hdmiphy0;
> >
> > /* optional internal rgb encoder */
> > struct rockchip_rgb *rgb;
> > @@ -220,6 +222,8 @@ struct vop2 {
> > struct vop2_win win[];
> > };
> >
> > +#define VOP2_MAX_DCLK_RATE 600000 /* kHz */
> > +
> > #define vop2_output_if_is_hdmi(x) ((x) == ROCKCHIP_VOP2_EP_HDMI0 || \
> > (x) == ROCKCHIP_VOP2_EP_HDMI1)
> >
> > @@ -1033,6 +1037,9 @@ static void vop2_crtc_atomic_disable(struct drm_crtc *crtc,
> >
> > vop2_crtc_disable_irq(vp, VP_INT_DSP_HOLD_VALID);
> >
> > + if (vp->dclk_src)
> > + clk_set_parent(vp->dclk, vp->dclk_src);
> > +
> > clk_disable_unprepare(vp->dclk);
> >
> > vop2->enable_count--;
> > @@ -2049,6 +2056,27 @@ static void vop2_crtc_atomic_enable(struct drm_crtc *crtc,
> >
> > vop2_vp_write(vp, RK3568_VP_MIPI_CTRL, 0);
> >
> > + /*
> > + * Switch to HDMI PHY PLL as DCLK source for display modes up
> > + * to 4K@60Hz, if available, otherwise keep using the system CRU.
> > + */
> > + if (vop2->pll_hdmiphy0 && mode->crtc_clock <= VOP2_MAX_DCLK_RATE) {
> > + drm_for_each_encoder_mask(encoder, crtc->dev, crtc_state->encoder_mask) {
> > + struct rockchip_encoder *rkencoder = to_rockchip_encoder(encoder);
> > +
> > + if (rkencoder->crtc_endpoint_id == ROCKCHIP_VOP2_EP_HDMI0) {
> > + if (!vp->dclk_src)
> > + vp->dclk_src = clk_get_parent(vp->dclk);
> > +
> > + ret = clk_set_parent(vp->dclk, vop2->pll_hdmiphy0);
> > + if (ret < 0)
> > + drm_warn(vop2->drm,
> > + "Could not switch to HDMI0 PHY PLL: %d\n", ret);
> > + break;
> > + }
> > + }
> > + }
> > +
>
> It seems pretty fragile to do it at atomic_enable time, even more so
> since you don't lock the parent either.
>
> Any reason not to do it in the DRM or clock driver probe, and make sure
> you never change the parent somehow?
On rk3588 we have 3 dclk_s and 2 hdmi controllers. Each video-port can
use the clock generated from either the hdmi0phy or hdmi1phy, depending
on which hdmi-controller it uses.
So you actually need to know which vpX will output to which hdmiY to then
reparent that dclk to the hdmiphy output.
next prev parent reply other threads:[~2024-12-11 17:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-11 10:15 [PATCH v2 0/5] Improve Rockchip VOP2 display modes handling on RK3588 HDMI0 Cristian Ciocaltea
2024-12-11 10:15 ` [PATCH v2 1/5] dt-bindings: display: vop2: Add optional PLL clock properties Cristian Ciocaltea
2024-12-11 10:15 ` [PATCH v2 2/5] drm/rockchip: vop2: Drop unnecessary if_pixclk_rate computation Cristian Ciocaltea
2024-12-11 10:15 ` [PATCH v2 3/5] drm/rockchip: vop2: Improve display modes handling on RK3588 HDMI0 Cristian Ciocaltea
2024-12-11 17:07 ` Maxime Ripard
2024-12-11 17:23 ` Heiko Stübner [this message]
2024-12-11 17:47 ` Maxime Ripard
2024-12-11 18:01 ` Heiko Stübner
2024-12-17 15:00 ` Maxime Ripard
2024-12-17 16:36 ` Cristian Ciocaltea
2024-12-17 16:53 ` Maxime Ripard
2024-12-17 16:59 ` Cristian Ciocaltea
2024-12-18 1:36 ` Andy Yan
2025-01-08 22:27 ` Cristian Ciocaltea
2024-12-11 10:15 ` [PATCH v2 4/5] arm64: dts: rockchip: Enable HDMI0 PHY clk provider on RK3588 Cristian Ciocaltea
2024-12-11 10:15 ` [PATCH v2 5/5] arm64: dts: rockchip: Add HDMI0 PHY PLL clock source to VOP2 " Cristian Ciocaltea
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=1820767.5KxKD5qtyk@diego \
--to=heiko@sntech.de \
--cc=airlied@gmail.com \
--cc=andy.yan@rock-chips.com \
--cc=conor+dt@kernel.org \
--cc=cristian.ciocaltea@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=hjc@rock-chips.com \
--cc=kernel@collabora.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=naoki@radxa.com \
--cc=robh@kernel.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.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 NNTP newsgroup(s).