kernel/linux.git/drivers/gpu/drm/rockchip, branch v5.5.10

drm/rockchip: fix integer type used for storing dp data rate

2020-01-13T13:31:59+00:00

commit 2589c4025f13 ("drm/rockchip: Avoid drm_dp_link helpers") changes the type of variables used to store the display port data rate and number of lanes to u8. However u8 is not sufficient to store the link data rate of the display port. This commit reverts the type of data rate to unsigned int. Fixes: 2589c4025f13 ("drm/rockchip: Avoid drm_dp_link helpers") Signed-off-by: Tobias Schramm Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20200109073129.378507-2-t.schramm@manjaro.org

drm/rockchip: Avoid drm_dp_link helpers

2019-10-23T16:21:01+00:00

During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. Start pushing the equivalent code into individual drivers to ultimately remove them. Signed-off-by: Thierry Reding Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20191021143437.1477719-13-thierry.reding@gmail.com

drm/rockchip: vop: add the definition of dclk_pol

2019-10-13T21:56:17+00:00

Some VOP's (such as px30) dclk_pol bit is at the last. So it is necessary to distinguish dclk_pol and pin_pol. Signed-off-by: Nickey Yang Reviewed-by: Sandy Huang Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20191010034452.20260-2-nickey.yang@rock-chips.com

drm/rockchip: make rockchip_gem_alloc_object static

2019-10-13T21:53:42+00:00

The rockchip_gem_alloc_object function is not exported so make it static to avoid the following sparse warning: drivers/gpu/drm/rockchip/rockchip_drm_gem.c:297:28: warning: symbol 'rockchip_gem_alloc_object' was not declared. Should it be static? Signed-off-by: Ben Dooks Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20191009121022.17478-1-ben.dooks@codethink.co.uk

drm/rockchip: include rockchip_drm_drv.h

2019-10-13T21:53:26+00:00

Include rockchip_drm_drv.h for definition of vop_platform_driver to avoid the following sparse warning: drivers/gpu/drm/rockchip/rockchip_vop_reg.c:982:24: warning: symbol 'vop_platform_driver' was not declared. Should it be static? Signed-off-by: Ben Dooks Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20191009132134.18384-1-ben.dooks@codethink.co.uk

drm/rockchip: rk3066_hdmi: Use devm_platform_ioremap_resource() in rk3066_hdmi_bind()

2019-10-13T21:52:55+00:00

Simplify this function implementation by using a known wrapper function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/0666bc0b-6624-21a0-47c4-b78e2a3b3ad5@web.de

drm/rockchip: Add optional support for CRTC gamma LUT

2019-10-11T13:24:29+00:00

Add an optional CRTC gamma LUT support, and enable it on RK3288. This is currently enabled via a separate address resource, which needs to be specified in the devicetree. The address resource is required because on some SoCs, such as RK3288, the LUT address is after the MMU address, and the latter is supported by a different driver. This prevents the DRM driver from requesting an entire register space. The current implementation works for RGB 10-bit tables, as that is what seems to work on RK3288. Tested-by: Heiko Stuebner Signed-off-by: Ezequiel Garcia Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20191010194351.17940-3-ezequiel@collabora.com

drm/rockchip: Enable DRM InfoFrame support on RK3328 and RK3399

2019-10-10T10:50:01+00:00

This patch enables Dynamic Range and Mastering InfoFrame on RK3328 and RK3399. Cc: Sandy Huang Cc: Heiko Stuebner Signed-off-by: Jonas Karlman Reviewed-by: Heiko Stuebner Reviewed-by: Andrzej Hajda Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/HE1PR06MB4011C9579CA6BBCD96C87810AC9B0@HE1PR06MB4011.eurprd06.prod.outlook.com

drm/rockchip: Round up _before_ giving to the clock framework

2019-10-09T19:13:58+00:00

I'm embarassed to say that even though I've touched vop_crtc_mode_fixup() twice and I swear I tested it, there's still a stupid glaring bug in it. Specifically, on veyron_minnie (with all the latest display timings) we want to be setting our pixel clock to 66,666,666.67 Hz and we tell userspace that's what we set, but we're actually choosing 66,000,000 Hz. This is confirmed by looking at the clock tree. The problem is that in drm_display_mode_from_videomode() we convert from Hz to kHz with: dmode->clock = vm->pixelclock / 1000; ...and drm_display_mode_from_videomode() is called from panel-simple when we have an "override_mode" like we do on veyron_minnie. See commit 123643e5c40a ("ARM: dts: rockchip: Specify rk3288-veyron-minnie's display timings"). ...so when the device tree specifies a clock of 66666667 for the panel then DRM translates that to 66666000. The clock framework will always pick a clock that is _lower_ than the one requested, so it will refuse to pick 66666667 and we'll end up at 66000000. While we could try to fix drm_display_mode_from_videomode() to round to the nearest kHz and it would fix our problem, it wouldn't help if the clock we actually needed was 60,000,001 Hz. We could alternatively have DRM always round up, but maybe this would break someone else who already baked in the assumption that DRM rounds down. Specifically note that clock drivers are not consistent about whether they round up or round down when you call clk_set_rate(). We know how Rockchip's clock driver works, but (for instance) you can see that on most Qualcomm clocks the default is clk_rcg2_ops which rounds up. Let's solve this by just adding 999 Hz before calling clk_round_rate(). This should be safe and work everywhere. As discussed in more detail in comments in the commit, Rockchip's PLLs are configured in a way that there shouldn't be another PLL setting that is only a few kHz off so we won't get mixed up. NOTE: if this is picked to stable, it's probably easiest to first pick commit 527e4ca3b6d1 ("drm/rockchip: Base adjustments of the mode based on prev adjustments") which shouldn't hurt in stable. Fixes: b59b8de31497 ("drm/rockchip: return a true clock rate to adjusted_mode") Signed-off-by: Douglas Anderson Reviewed-by: Sean Paul Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20191003114726.v2.1.Ib233b3e706cf6317858384264d5b0ed35657456e@changeid

Merge drm/drm-next into drm-misc-next

2019-10-03T14:38:50+00:00

We haven't done any backmerge for a while due to the merge window, and it starts to become an issue for komeda. Let's bring 5.4-rc1 in. Signed-off-by: Maxime Ripard