| Message ID | 20200922203107.2932-1-vicencb@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm: rockchip: hdmi: enable higher resolutions than FHD | expand |
On 2020-09-22 21:31, Vicente Bergas wrote: > This patch series enable a QHD HDMI monitor to work at native resolution. > Tested on a Sapphire board with RK3399 connected to a Q27q-10 monitor at 2560x1440@60 Indeed for RK3399 it also allows my 1920x1200 monitor (Dell U2415) to be driven at its native resolution with a 154MHz pixel clock. However, as predicted, it also breaks RK3328 for the same monitor - instead of rejecting the native mode and falling back to "standard" 1920x1080, it now tries to use it, which results in no signal and a spam of CRTC timeout warnings in dmesg :( I'll try to test RK3288 as well soon - I tried hacking a specific entry for 154MHz into the tables a while ago, and while it worked perfectly on RK3399, RK3288 gave a fairly glitchy picture as if the clock signal was unstable or slightly out of spec. I'm interested to see if patch #1 makes any difference there. Thanks, Robin. > > Changes since v1: > Use alternative clock rounding code proposed by Doug Anderson > > Vicente Bergas (3): > drm: rockchip: hdmi: fix clock rounding code > drm: rockchip: hdmi: allow any clock that is within the range > drm: rockchip: hdmi: add higher pixel clock frequencies > > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 8 +++++++- > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 ++----- > 2 files changed, 9 insertions(+), 6 deletions(-) >
Hi, On Tue, Sep 22, 2020 at 1:31 PM Vicente Bergas <vicencb@gmail.com> wrote: > > This patch series enable a QHD HDMI monitor to work at native resolution. > Tested on a Sapphire board with RK3399 connected to a Q27q-10 monitor at 2560x1440@60 > > Changes since v1: > Use alternative clock rounding code proposed by Doug Anderson > > Vicente Bergas (3): > drm: rockchip: hdmi: fix clock rounding code > drm: rockchip: hdmi: allow any clock that is within the range > drm: rockchip: hdmi: add higher pixel clock frequencies > > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 8 +++++++- > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 7 ++----- > 2 files changed, 9 insertions(+), 6 deletions(-) So I haven't looked at all this code in over a year and that was mostly just a quick re-hash of the work I did years and years ago... ...but: 1. On rk3288, which also uses dw-hdmi, things get super complicated because of the PLL sharing on the Rockchip platform. I don't _think_ this has all been worked out, has it? Specifically there is only one "free" PLL but two VOPs, so if you have two displays (like eDP and HDMI), one of those two has to make due with a very limited set of pixel clocks that it can make. On downstream Chrome OS tree we made the simplifying assumption that the internal panel was going to be the one to suffer (so we had to futz around w/ non-standard pixels clocks for all our panels) and added some not-so-generic code to then give the HDMI VOP full control of one of the PLLs. Without these tricks then you really shouldn't be advertising a lot of clock rates because the PLL won't be guaranteed to make them. I've never had time to find a wonderful solution myself and I've tried (at least 3 times) to convince others to solve this but failed. :( 2. In order to get all the clock rates working reliably across a large number of monitors on rk3288, I spent a lot of time tweaking all these parameters, and it mattered. You can see what's in the downstream tree at: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c Those numbers came from me staring at pages and pages or hardcoded numbers for different display modes until my eyes bled and then coming up with a script: https://chromium.googlesource.com/chromiumos/platform/drm-tests/+/f806cb7d7f14dd17087ae8ebed67bd3589708812/rk3288_hdmitables.py You are certainly free to totally ignore all that, but I figured I'd at last point you at it in case it helped make your rates more reliable. I spent many hours in a lab tweaking settings of dw_hdmi and various PLL settings for rk3288 to make sure we could actually produce a low enough jitter signal that plugging into a random monitor would actually work. NOTE: I only enabled this on rk3288. All rk3399 Chromebooks only supported DP out (through Type C), so I have zero idea about HDMI support on rk3399 or any other Rockchip SoCs and whether any of my work would actually be relevant there... Though I would have liked to get everything resolved with upstream last year, I just wasn't able to find the time to do it. I at least (hopefully) documented this in: https://crbug.com/970892 In any case, I'll probably step aside now and let upstream folks decide how they want to move forward. I don't think I have enough skin ihe game these days to really make stink about whatever you guys decide to do. ;-) -Doug