mbox series

[v2,0/3] drm: rockchip: hdmi: enable higher resolutions than FHD

Message ID 20200922203107.2932-1-vicencb@gmail.com
Headers show
Series drm: rockchip: hdmi: enable higher resolutions than FHD | expand

Message

Vicente Bergas Sept. 22, 2020, 8:31 p.m. UTC
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(-)

Comments

Robin Murphy Sept. 23, 2020, 10:18 p.m. UTC | #1
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(-)
>
Doug Anderson Sept. 23, 2020, 11:25 p.m. UTC | #2
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