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  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

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- |

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- |

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-jo...@kwiboo.se/
[2] https://lore.kernel.org/all/20200922205933.5540-1-jo...@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]

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- |

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- |

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 

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

[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 

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

[Dan Johansen]

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

Thank you.

Tested-by: Dan Johansen 

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 

[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