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

drm/rockchip: Detach from ARM DMA domain in attach_device

2022-07-04T15:17:35+00:00

Since commit 1ea2a07a532b ("iommu: Add DMA ownership management interfaces") the Rockchip display driver on the Firefly RK3288 fails to initialise properly. This is because ARM DMA domain is still attached. Let's follow the lead of exynos and tegra and add code to explicitly remove the ARM domain before attaching a new one. Fixes: 1ea2a07a532b ("iommu: Add DMA ownership management interfaces") Suggested-by: Robin Murphy Signed-off-by: Steven Price Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220615154830.555422-1-steven.price@arm.com

drm/rockchip: Change register space names in vop2

2022-05-16T22:16:33+00:00

"regs" seems to generic when there are multiple register spaces, so rename that one to "vop". Also change "gamma_lut" to better looking "gamma-lut". Signed-off-by: Sascha Hauer Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220511082109.1110043-3-s.hauer@pengutronix.de

drm/rockchip: Add VOP2 driver

2022-05-04T12:05:47+00:00

The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568. It replaces the VOP unit found in the older Rockchip SoCs. This driver has been derived from the downstream Rockchip Kernel and heavily modified: - All nonstandard DRM properties have been removed - dropped struct vop2_plane_state and pass around less data between functions - Dropped all DRM_FORMAT_* not known on upstream - rework register access to get rid of excessively used macros - Drop all waiting for framesyncs The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB board. Overlay support is tested with the modetest utility. AFBC support on the cluster windows is tested with weston-simple-dmabuf-egl on weston using the (yet to be upstreamed) panfrost driver support. Signed-off-by: Andy Yan Co-Developed-by: Sascha Hauer Signed-off-by: Sascha Hauer Tested-by: Michael Riesch [dt-binding-header:] Acked-by: Rob Herring [moved dt-binding header from dt-nodes patch to here and made checkpatch --strict happier] Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-23-s.hauer@pengutronix.de

drm/rockchip: Make VOP driver optional

2022-05-04T12:05:47+00:00

With upcoming VOP2 support VOP won't be the only choice anymore, so make the VOP driver optional. This also adds a dependency from ROCKCHIP_ANALOGIX_DP to ROCKCHIP_VOP, because that driver currently only links and works with the VOP driver. Signed-off-by: Sascha Hauer Tested-by: Michael Riesch Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-22-s.hauer@pengutronix.de

drm/rockchip: dw_hdmi: add regulator support

2022-05-03T10:56:05+00:00

The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs needed for the HDMI port. add support for these to the driver for boards which have them supplied by switchable regulators. Signed-off-by: Sascha Hauer Reviewed-by: Dmitry Osipenko Tested-by: Michael Riesch Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-10-s.hauer@pengutronix.de

drm/rockchip: dw_hdmi: add rk3568 support

2022-05-03T10:56:04+00:00

Add a new dw_hdmi_plat_data struct and new compatible for rk3568. Signed-off-by: Benjamin Gaignard Signed-off-by: Sascha Hauer Tested-by: Michael Riesch Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-8-s.hauer@pengutronix.de

drm/rockchip: dw_hdmi: rename vpll clock to reference clock

2022-05-03T09:24:04+00:00

"vpll" is a misnomer. A clock input to a device should be named after the usage in the device, not after the clock that drives it. On the rk3568 the same clock is driven by the HPLL. To fix that, this patch renames the vpll clock to ref clock. The clock name "vpll" is left for compatibility to old device trees. Signed-off-by: Sascha Hauer Reviewed-by: Dmitry Osipenko Tested-by: Michael Riesch Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-5-s.hauer@pengutronix.de

drm/rockchip: Add crtc_endpoint_id to rockchip_encoder

2022-05-03T09:24:00+00:00

The VOP2 has an interface mux which decides to which encoder(s) a CRTC is routed to. The encoders and CRTCs are connected via of_graphs in the device tree. When given an encoder the VOP2 driver needs to know to which internal register setting this encoder matches. For this the VOP2 binding offers different endpoints, one for each possible encoder. The endpoint ids of these endpoints are used as a key from an encoders device tree description to the internal register setting. This patch adds the key aka endpoint id to struct rockchip_encoder plus a function to read the endpoint id starting from the encoders device node. Signed-off-by: Sascha Hauer Tested-by: Michael Riesch Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-4-s.hauer@pengutronix.de

drm/rockchip: Embed drm_encoder into rockchip_decoder

2022-05-03T09:23:47+00:00

The VOP2 driver needs rockchip specific information for a drm_encoder. This patch creates a struct rockchip_encoder with a struct drm_encoder embedded in it. This is used throughout the rockchip driver instead of struct drm_encoder directly. The information the VOP2 drivers needs is the of_graph endpoint node of the encoder. To ease bisectability this is added here. While at it convert the different encoder-to-driverdata macros to static inline functions in order to gain type safety and readability. Signed-off-by: Sascha Hauer Tested-by: Michael Riesch Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-3-s.hauer@pengutronix.de

drm/rockchip: Support YUV formats with U/V swapped

2022-05-02T22:04:17+00:00

The VOP in Rockchip SoCs that support YUV planes also support swapping of the U and V elements. Supporting the swapped variants, especially NV21, would be beneficial for multimedia applications, as the hardware video decoders only output NV21, and supporting this pixel format in the display pipeline would allow the decoded video frames to be output directly. Add support for this to support the various formats that have U/V swapped. Signed-off-by: Chen-Yu Tsai Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220114074038.2633848-1-wenst@chromium.org