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

[Doug Anderson]

Hi,

On Tue, Sep 22, 2020 at 1:31 PM Vicente Bergas <vicencb at 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 at 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