| Message ID | 20230118132213.2911418-1-s.hauer@pengutronix.de (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/rockchip: dw_hdmi: Add 4k@30 support | expand |
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(-) >
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(-) >
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
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 > >
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 > > > > > > > > > >
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 >>>> >>>> >>> >> >> >
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
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
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