[PATCH v3 0/3] drm/rockchip: dw_hdmi: Add 4k@30 support

[PATCH v3 0/3] drm/rockchip: dw_hdmi: Add 4k@30 support

[Sascha Hauer]

It's been some time since I last sent this series. This version fixes
a regression Dan Johansen reported. The reason turned out to be simple,
I used the YUV420 register values instead of the RGB ones.

I realized that we cannot achieve several modes offered by my monitor
as these require pixelclocks that are slightly below the standard
pixelclocks. As these are lower than the standard clock rates the PLL
driver offers the clk driver falls back to a way lower frequency
which results in something the monitor can't display, so this series
now contains a patch to discard these unachievable modes.

Sascha

Changes since v2:
- Use correct register values for mpll_cfg
- Add patch to discard modes we cannot achieve

Changes since v1:
- Allow non standard clock rates only on Synopsys phy as suggested by
  Robin Murphy

Sascha Hauer (3):
  drm/rockchip: dw_hdmi: relax mode_valid hook
  drm/rockchip: dw_hdmi: Add support for 4k@30 resolution
  drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 40 ++++++++++++++++-----
 1 file changed, 32 insertions(+), 8 deletions(-)

-- 
2.30.2

[PATCH v3 1/3] drm/rockchip: dw_hdmi: relax mode_valid hook

[Sascha Hauer]

The driver checks if the pixel clock of the given mode matches an entry
in the mpll config table. At least for the Synopsys phy the frequencies
in the mpll table are meant as a frequency range up to which the entry
works, not as a frequency that must match the pixel clock. Return
MODE_OK when the pixelclock is smaller than one of the mpll frequencies
to allow for more display resolutions.
Limit this behaviour to the Synopsys phy at the moment and keep the
current behaviour of forcing exact pixelclock rates for the other phys
until it has been sorted out how and if the vendor specific phys work
with non standard clock rates.

Tested-by: Michael Riesch <michael.riesch@wolfvision.net>
Link: https://lore.kernel.org/r/20220926080435.259617-2-s.hauer@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 26 +++++++++++++++------
 1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 2f4b8f64cbad3..7d8bf292fedce 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -74,6 +74,7 @@ struct rockchip_hdmi {
 	struct regmap *regmap;
 	struct rockchip_encoder encoder;
 	const struct rockchip_hdmi_chip_data *chip_data;
+	const struct dw_hdmi_plat_data *plat_data;
 	struct clk *ref_clk;
 	struct clk *grf_clk;
 	struct dw_hdmi *hdmi;
@@ -241,23 +242,32 @@ static int rockchip_hdmi_parse_dt(struct rockchip_hdmi *hdmi)
 }
 
 static enum drm_mode_status
-dw_hdmi_rockchip_mode_valid(struct dw_hdmi *hdmi, void *data,
+dw_hdmi_rockchip_mode_valid(struct dw_hdmi *dw_hdmi, void *data,
 			    const struct drm_display_info *info,
 			    const struct drm_display_mode *mode)
 {
+	struct rockchip_hdmi *hdmi = data;
 	const struct dw_hdmi_mpll_config *mpll_cfg = rockchip_mpll_cfg;
 	int pclk = mode->clock * 1000;
-	bool valid = false;
+	bool exact_match = hdmi->plat_data->phy_force_vendor;
 	int i;
 
 	for (i = 0; mpll_cfg[i].mpixelclock != (~0UL); i++) {
-		if (pclk == mpll_cfg[i].mpixelclock) {
-			valid = true;
-			break;
-		}
+		/*
+		 * For vendor specific phys force an exact match of the pixelclock
+		 * to preserve the original behaviour of the driver.
+		 */
+		if (exact_match && pclk == mpll_cfg[i].mpixelclock)
+			return MODE_OK;
+		/*
+		 * The Synopsys phy can work with pixelclocks up to the value given
+		 * in the corresponding mpll_cfg entry.
+		 */
+		if (!exact_match && pclk <= mpll_cfg[i].mpixelclock)
+			return MODE_OK;
 	}
 
-	return (valid) ? MODE_OK : MODE_BAD;
+	return MODE_BAD;
 }
 
 static void dw_hdmi_rockchip_encoder_disable(struct drm_encoder *encoder)
@@ -546,8 +556,10 @@ static int dw_hdmi_rockchip_bind(struct device *dev, struct device *master,
 		return -ENOMEM;
 
 	hdmi->dev = &pdev->dev;
+	hdmi->plat_data = plat_data;
 	hdmi->chip_data = plat_data->phy_data;
 	plat_data->phy_data = hdmi;
+	plat_data->priv_data = hdmi;
 	encoder = &hdmi->encoder.encoder;
 
 	encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
-- 
2.30.2

[PATCH v3 2/3] drm/rockchip: dw_hdmi: Add support for 4k@30 resolution

[Sascha Hauer]

This adds the PLL/phy settings to support higher resolutions like 4k@30.
The values were taken from the Rockchip downstream Kernel.

Tested-by: Michael Riesch <michael.riesch@wolfvision.net>
Link: https://lore.kernel.org/r/20220926080435.259617-3-s.hauer@pengutronix.de
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---

Notes:
    Changes since v2:
    - Use correct mpll_cfg values, previously the 420 values were used

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 7d8bf292fedce..feba6b9becd6c 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -161,6 +161,12 @@ static const struct dw_hdmi_mpll_config rockchip_mpll_cfg[] = {
 			{ 0x214c, 0x0003},
 			{ 0x4064, 0x0003}
 		},
+	}, {
+		340000000, {
+			{ 0x0040, 0x0003 },
+			{ 0x3b4c, 0x0003 },
+			{ 0x5a64, 0x0003 },
+		},
 	}, {
 		~0UL, {
 			{ 0x00a0, 0x000a },
@@ -186,6 +192,8 @@ static const struct dw_hdmi_curr_ctrl rockchip_cur_ctr[] = {
 		146250000, { 0x0038, 0x0038, 0x0038 },
 	}, {
 		148500000, { 0x0000, 0x0038, 0x0038 },
+	}, {
+		600000000, { 0x0000, 0x0000, 0x0000 },
 	}, {
 		~0UL,      { 0x0000, 0x0000, 0x0000},
 	}
-- 
2.30.2

[PATCH v3 3/3] drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks

[Sascha Hauer]

The Rockchip PLL drivers are currently table based and support only
the most common pixelclocks. Discard all modes we cannot achieve
at all. Normally the desired pixelclocks have an exact match in the
PLL driver, nevertheless allow for a 0.1% error just in case.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---

Notes:
    Changes since v2:
    - new patch

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index feba6b9becd6c..725952811752b 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -256,10 +256,14 @@ dw_hdmi_rockchip_mode_valid(struct dw_hdmi *dw_hdmi, void *data,
 {
 	struct rockchip_hdmi *hdmi = data;
 	const struct dw_hdmi_mpll_config *mpll_cfg = rockchip_mpll_cfg;
-	int pclk = mode->clock * 1000;
+	int rpclk, pclk = mode->clock * 1000;
 	bool exact_match = hdmi->plat_data->phy_force_vendor;
 	int i;
 
+	rpclk = clk_round_rate(hdmi->ref_clk, pclk);
+	if (abs(rpclk - pclk) > pclk / 1000)
+		return MODE_NOCLOCK;
+
 	for (i = 0; mpll_cfg[i].mpixelclock != (~0UL); i++) {
 		/*
 		 * For vendor specific phys force an exact match of the pixelclock
-- 
2.30.2

Re: [PATCH v3 0/3] drm/rockchip: dw_hdmi: Add 4k@30 support

[Dan Johansen]

Tested the whole series on my Rock 3A, with my 1440p monitor. Works wonders!

Thank you.

Tested-by: Dan Johansen <strit@manjaro.org>

Den 18.01.2023 kl. 14.22 skrev Sascha Hauer:
> It's been some time since I last sent this series. This version fixes
> a regression Dan Johansen reported. The reason turned out to be simple,
> I used the YUV420 register values instead of the RGB ones.
>
> I realized that we cannot achieve several modes offered by my monitor
> as these require pixelclocks that are slightly below the standard
> pixelclocks. As these are lower than the standard clock rates the PLL
> driver offers the clk driver falls back to a way lower frequency
> which results in something the monitor can't display, so this series
> now contains a patch to discard these unachievable modes.
>
> Sascha
>
> Changes since v2:
> - Use correct register values for mpll_cfg
> - Add patch to discard modes we cannot achieve
>
> Changes since v1:
> - Allow non standard clock rates only on Synopsys phy as suggested by
>    Robin Murphy
>
> Sascha Hauer (3):
>    drm/rockchip: dw_hdmi: relax mode_valid hook
>    drm/rockchip: dw_hdmi: Add support for 4k@30 resolution
>    drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks
>
>   drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 40 ++++++++++++++++-----
>   1 file changed, 32 insertions(+), 8 deletions(-)
>
-- 
Kind regards
*Dan Johansen*
Project lead of the *Manjaro ARM* project
Manjaro-ARM <https://manjaro.org>

Re: [PATCH v3 0/3] drm/rockchip: dw_hdmi: Add 4k@30 support

[Michael Riesch]

Hi Sascha,

Thanks a lot for the v3, works great in my setup!

On 1/18/23 14:22, Sascha Hauer wrote:
> It's been some time since I last sent this series. This version fixes
> a regression Dan Johansen reported. The reason turned out to be simple,
> I used the YUV420 register values instead of the RGB ones.
> 
> I realized that we cannot achieve several modes offered by my monitor
> as these require pixelclocks that are slightly below the standard
> pixelclocks. As these are lower than the standard clock rates the PLL
> driver offers the clk driver falls back to a way lower frequency
> which results in something the monitor can't display, so this series
> now contains a patch to discard these unachievable modes.
> 
> Sascha
> 
> Changes since v2:
> - Use correct register values for mpll_cfg
> - Add patch to discard modes we cannot achieve
> 
> Changes since v1:
> - Allow non standard clock rates only on Synopsys phy as suggested by
>   Robin Murphy
> 
> Sascha Hauer (3):
>   drm/rockchip: dw_hdmi: relax mode_valid hook
>   drm/rockchip: dw_hdmi: Add support for 4k@30 resolution
>   drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks

For the complete series

Tested-by: Michael Riesch <michael.riesch@wolfvision.net>

Best regards,
Michael

> 
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 40 ++++++++++++++++-----
>  1 file changed, 32 insertions(+), 8 deletions(-)
> 

Re: [PATCH v3 0/3] drm/rockchip: dw_hdmi: Add 4k@30 support

[Nicolas Frattaroli]

On Wednesday, 18 January 2023 14:22:10 CET Sascha Hauer wrote:
> It's been some time since I last sent this series. This version fixes
> a regression Dan Johansen reported. The reason turned out to be simple,
> I used the YUV420 register values instead of the RGB ones.
> 
> I realized that we cannot achieve several modes offered by my monitor
> as these require pixelclocks that are slightly below the standard
> pixelclocks. As these are lower than the standard clock rates the PLL
> driver offers the clk driver falls back to a way lower frequency
> which results in something the monitor can't display, so this series
> now contains a patch to discard these unachievable modes.
> 
> Sascha
> 
> Changes since v2:
> - Use correct register values for mpll_cfg
> - Add patch to discard modes we cannot achieve
> 
> Changes since v1:
> - Allow non standard clock rates only on Synopsys phy as suggested by
>   Robin Murphy
> 
> Sascha Hauer (3):
>   drm/rockchip: dw_hdmi: relax mode_valid hook
>   drm/rockchip: dw_hdmi: Add support for 4k@30 resolution
>   drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks
> 
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 40 ++++++++++++++++-----
>  1 file changed, 32 insertions(+), 8 deletions(-)

For the whole series:

Tested-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>

Tested on two monitors:

Monitor 1 was an Iiyama ProLite G2773HS, which only does 1080p60 over HDMI.
Testing on it, I found no regressions; all the old modes still showed up
and the 1080p60 mode worked as expected.

Monitor 2 was a Philips 328P, which does 4K30 over HDMI. Without the patches,
the 4K modes were absent. With the patchset, the 4K modes are present,
functional and picked by default.

Great work!

Cheers,
Nicolas Frattaroli

Re: [PATCH v3 0/3] drm/rockchip: dw_hdmi: Add 4k@30 support

[Sascha Hauer]

Heiko, Sandy,

Ok to apply these patches?

Sascha

On Wed, Jan 18, 2023 at 02:22:10PM +0100, Sascha Hauer wrote:
> It's been some time since I last sent this series. This version fixes
> a regression Dan Johansen reported. The reason turned out to be simple,
> I used the YUV420 register values instead of the RGB ones.
> 
> I realized that we cannot achieve several modes offered by my monitor
> as these require pixelclocks that are slightly below the standard
> pixelclocks. As these are lower than the standard clock rates the PLL
> driver offers the clk driver falls back to a way lower frequency
> which results in something the monitor can't display, so this series
> now contains a patch to discard these unachievable modes.
> 
> Sascha
> 
> Changes since v2:
> - Use correct register values for mpll_cfg
> - Add patch to discard modes we cannot achieve
> 
> Changes since v1:
> - Allow non standard clock rates only on Synopsys phy as suggested by
>   Robin Murphy
> 
> Sascha Hauer (3):
>   drm/rockchip: dw_hdmi: relax mode_valid hook
>   drm/rockchip: dw_hdmi: Add support for 4k@30 resolution
>   drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks
> 
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 40 ++++++++++++++++-----
>  1 file changed, 32 insertions(+), 8 deletions(-)
> 
> -- 
> 2.30.2
> 
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH v3 0/3] drm/rockchip: dw_hdmi: Add 4k@30 support

[Sascha Hauer]

Hi,

On Wed, Feb 01, 2023 at 09:23:56AM +0900, FUKAUMI Naoki wrote:
> hi,
> 
> I'm trying this patch series with 6.1.x kernel. it works fine on rk356x
> based boards (ROCK 3), but it has a problem on rk3399 boards (ROCK 4).
> 
> on rk3399 with this patch, I can see large noise area (about one third right
> side of the screen) at 4k@30. 1080p works fine as same as before.
> 
> can someone reproduce this problem on rk3399?

I have a RK339 board here, I can try to reproduce this next week. Of
course I have no idea what the issue might be, in the downstream Kernel
I can't find anything that is handled specially for the RK3399.

What might be worth checking is the VOP clock rate. Does the VOP clock
in /sys/kernel/debug/clk/clk_summary (I don't know which one it is
though) match the pixelclock?

If nothing else helps I can change the code to only allow the higher
resolutions on RK3568 where we know it works.

Sascha

> 
> --
> FUKAUMI Naoki
> 
> On 1/31/23 17:09, Sascha Hauer wrote:
> > Heiko, Sandy,
> > 
> > Ok to apply these patches?
> > 
> > Sascha
> > 
> > On Wed, Jan 18, 2023 at 02:22:10PM +0100, Sascha Hauer wrote:
> > > It's been some time since I last sent this series. This version fixes
> > > a regression Dan Johansen reported. The reason turned out to be simple,
> > > I used the YUV420 register values instead of the RGB ones.
> > > 
> > > I realized that we cannot achieve several modes offered by my monitor
> > > as these require pixelclocks that are slightly below the standard
> > > pixelclocks. As these are lower than the standard clock rates the PLL
> > > driver offers the clk driver falls back to a way lower frequency
> > > which results in something the monitor can't display, so this series
> > > now contains a patch to discard these unachievable modes.
> > > 
> > > Sascha
> > > 
> > > Changes since v2:
> > > - Use correct register values for mpll_cfg
> > > - Add patch to discard modes we cannot achieve
> > > 
> > > Changes since v1:
> > > - Allow non standard clock rates only on Synopsys phy as suggested by
> > >    Robin Murphy
> > > 
> > > Sascha Hauer (3):
> > >    drm/rockchip: dw_hdmi: relax mode_valid hook
> > >    drm/rockchip: dw_hdmi: Add support for 4k@30 resolution
> > >    drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks
> > > 
> > >   drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 40 ++++++++++++++++-----
> > >   1 file changed, 32 insertions(+), 8 deletions(-)
> > > 
> > > -- 
> > > 2.30.2
> > > 
> > > 
> > 
> 
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH v3 0/3] drm/rockchip: dw_hdmi: Add 4k@30 support

[Jonas Karlman]

Hi,
On 2023-02-03 14:09, Sascha Hauer wrote:
> Hi,
> 
> On Wed, Feb 01, 2023 at 09:23:56AM +0900, FUKAUMI Naoki wrote:
>> hi,
>>
>> I'm trying this patch series with 6.1.x kernel. it works fine on rk356x
>> based boards (ROCK 3), but it has a problem on rk3399 boards (ROCK 4).
>>
>> on rk3399 with this patch, I can see large noise area (about one third right
>> side of the screen) at 4k@30. 1080p works fine as same as before.
>>
>> can someone reproduce this problem on rk3399?
> 
> I have a RK339 board here, I can try to reproduce this next week. Of
> course I have no idea what the issue might be, in the downstream Kernel
> I can't find anything that is handled specially for the RK3399.
> 
> What might be worth checking is the VOP clock rate. Does the VOP clock
> in /sys/kernel/debug/clk/clk_summary (I don't know which one it is
> though) match the pixelclock?
> 
> If nothing else helps I can change the code to only allow the higher
> resolutions on RK3568 where we know it works.

This series only seem to pick up part of the dw-hdmi related changes that
originates from an old chromium 4.4 kernel. Maybe that is the reason
this cause issues on other SoCs?

I have very recently resumed kernel coding after being away for the last
2-3 years and was planning on resuming work on a HDMI 2.0 series based on
old work at [1], [2] and [3]. Those patches never got any traction last
time around, maybe there is more interest now, seeing this series :-)

I was planning on basing such series on top of this, but seeing how this
seem to have issues on other SoCs I am not sure how to proceed.

With the patches at [3] (and related patches) HDMI 2.0 modes (4K@60hz)
is possible with at least RK3288, RK3328, RK3399 and RK3568 SoCs.
However, those patches needs to be cleaned up a bit before they will
hit the mailing list.

[1] https://lore.kernel.org/all/20200108210740.28769-1-jonas@kwiboo.se/
[2] https://lore.kernel.org/all/20200922205933.5540-1-jonas@kwiboo.se/
[3] https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/Rockchip/patches/linux/default/linux-1000-drm-rockchip.patch

Regards,
Jonas

> 
> Sascha
> 
>>
>> --
>> FUKAUMI Naoki
>>
>> On 1/31/23 17:09, Sascha Hauer wrote:
>>> Heiko, Sandy,
>>>
>>> Ok to apply these patches?
>>>
>>> Sascha
>>>
>>> On Wed, Jan 18, 2023 at 02:22:10PM +0100, Sascha Hauer wrote:
>>>> It's been some time since I last sent this series. This version fixes
>>>> a regression Dan Johansen reported. The reason turned out to be simple,
>>>> I used the YUV420 register values instead of the RGB ones.
>>>>
>>>> I realized that we cannot achieve several modes offered by my monitor
>>>> as these require pixelclocks that are slightly below the standard
>>>> pixelclocks. As these are lower than the standard clock rates the PLL
>>>> driver offers the clk driver falls back to a way lower frequency
>>>> which results in something the monitor can't display, so this series
>>>> now contains a patch to discard these unachievable modes.
>>>>
>>>> Sascha
>>>>
>>>> Changes since v2:
>>>> - Use correct register values for mpll_cfg
>>>> - Add patch to discard modes we cannot achieve
>>>>
>>>> Changes since v1:
>>>> - Allow non standard clock rates only on Synopsys phy as suggested by
>>>>    Robin Murphy
>>>>
>>>> Sascha Hauer (3):
>>>>    drm/rockchip: dw_hdmi: relax mode_valid hook
>>>>    drm/rockchip: dw_hdmi: Add support for 4k@30 resolution
>>>>    drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks
>>>>
>>>>   drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 40 ++++++++++++++++-----
>>>>   1 file changed, 32 insertions(+), 8 deletions(-)
>>>>
>>>> -- 
>>>> 2.30.2
>>>>
>>>>
>>>
>>
>>
> 

Re: [PATCH v3 0/3] drm/rockchip: dw_hdmi: Add 4k@30 support

[Sascha Hauer]

On Wed, Feb 01, 2023 at 09:23:56AM +0900, FUKAUMI Naoki wrote:
> hi,
> 
> I'm trying this patch series with 6.1.x kernel. it works fine on rk356x
> based boards (ROCK 3), but it has a problem on rk3399 boards (ROCK 4).
> 
> on rk3399 with this patch, I can see large noise area (about one third right
> side of the screen) at 4k@30. 1080p works fine as same as before.
> 
> can someone reproduce this problem on rk3399?

Ok, I could easily reproduce the problem here.

The RK3399 has two VOPs, vopb(ig) and vopl(ittle). Only the former can
do 4k@30 while the latter can only do 1080p. Unfortunately vopl is used
by default. We can force using vopb by disabling vopl in the device tree
and get a good 4k@30 picture then. The other possibility I found is to
use the other CRTC with modetest. I have no idea how we could set the
default to vopb.

I guess a first step would be to limit the maximum resolution of vopl
to what the hardware can do. We would likely end up with 1080p by
default then for the applications.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH v3 0/3] drm/rockchip: dw_hdmi: Add 4k@30 support

[Sascha Hauer]

On Mon, Feb 06, 2023 at 03:04:48PM +0100, Sascha Hauer wrote:
> On Wed, Feb 01, 2023 at 09:23:56AM +0900, FUKAUMI Naoki wrote:
> > hi,
> > 
> > I'm trying this patch series with 6.1.x kernel. it works fine on rk356x
> > based boards (ROCK 3), but it has a problem on rk3399 boards (ROCK 4).
> > 
> > on rk3399 with this patch, I can see large noise area (about one third right
> > side of the screen) at 4k@30. 1080p works fine as same as before.
> > 
> > can someone reproduce this problem on rk3399?
> 
> Ok, I could easily reproduce the problem here.
> 
> The RK3399 has two VOPs, vopb(ig) and vopl(ittle). Only the former can
> do 4k@30 while the latter can only do 1080p. Unfortunately vopl is used
> by default. We can force using vopb by disabling vopl in the device tree
> and get a good 4k@30 picture then. The other possibility I found is to
> use the other CRTC with modetest. I have no idea how we could set the
> default to vopb.
> 
> I guess a first step would be to limit the maximum resolution of vopl
> to what the hardware can do. We would likely end up with 1080p by
> default then for the applications.

I did that, but the result is not what I expected. Discarding a mode in
the connector means it won't show up in the connectors list of modes.
Discarding it in the CRTC though means the mode is still exposed by the
connector, but actually trying to use it then fails.

This means when discarding the mode in the CRTC the screen stays black.

I am not sure where I should go from here.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: [PATCH v3 0/3] drm/rockchip: dw_hdmi: Add 4k@30 support

[Daniel Stone]

Hi Sascha,

On Mon, 6 Feb 2023 at 15:49, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Mon, Feb 06, 2023 at 03:04:48PM +0100, Sascha Hauer wrote:
> > I guess a first step would be to limit the maximum resolution of vopl
> > to what the hardware can do. We would likely end up with 1080p by
> > default then for the applications.
>
> I did that, but the result is not what I expected. Discarding a mode in
> the connector means it won't show up in the connectors list of modes.
> Discarding it in the CRTC though means the mode is still exposed by the
> connector, but actually trying to use it then fails.
>
> This means when discarding the mode in the CRTC the screen stays black.
>
> I am not sure where I should go from here.

You've done the right thing. Userspace should detect this and try with
alternative CRTC routing. The kernel shouldn't be trying to solve this
problem.

Cheers,
Daniel