talos-obmc-linux/drivers/gpu/drm/exynos, branch dev-4.13

Merge tag 'drm-for-v4.14' into dev-4.13

2018-04-19T02:00:20+00:00

This is the DRM tree that was merged into the mainline 4.14 kernel. The ASPEED GFX DRM driver requires functionaliy that was included in this tree, so we merge it back into the 4.13 OpenBMC tree. This should have no impact on other parts of the BMC. Signed-off-by: Joel Stanley

drm/exynos: Fix locking in the suspend/resume paths

2017-10-05T07:47:27+00:00

commit 5baf6bb0fd2388742a0846cc7bcacee6dec78235 upstream. Commit 48a92916729b ("drm/exynos: use drm_for_each_connector_iter()") replaced unsafe drm_for_each_connector() with drm_for_each_connector_iter() and removed surrounding drm_modeset_lock calls. However, that lock was there not only to protect unsafe drm_for_each_connector(), but it was also required to be held by the dpms code which was called from the loop body. This patch restores those drm_modeset_lock calls to fix broken suspend and resume of Exynos DRM subsystem in v4.13 kernel. Fixes: 48a92916729b ("drm/exynos: use drm_for_each_connector_iter()") Signed-off-by: Marek Szyprowski Acked-by: Krzysztof Kozlowski Signed-off-by: Inki Dae Signed-off-by: Greg Kroah-Hartman

drm/exynos: simplify set_pixfmt() in DECON and FIMD drivers

2017-08-25T05:30:27+00:00

DRM core already checks the validity of the pixelformat. Signed-off-by: Tobias Jakobi Signed-off-by: Inki Dae

drm/exynos: consistent use of cpp

2017-08-25T05:06:48+00:00

A recent commit (272725c7db4da1fd3229d944fc76d2e98e3a144e) has removed the use of 'bits_per_pixel' in DRM. However the corresponding Exynos driver code still uses the ambiguous 'bpp', even though it is now initialized from fb->cpp[0]. Consistenly use 'cpp' in FIMD, DECON7 and DECON5433 drivers. Signed-off-by: Tobias Jakobi

drm/exynos: mixer: remove src offset from mixer_graph_buffer()

2017-08-25T03:10:33+00:00

We always translate the dma address such that the offsets of the source image are zero. Hence we can remove manipulation of the MXR_GRAPHIC_SXY(win) register and just zero them once in mixer_win_reset(). Signed-off-by: Tobias Jakobi Signed-off-by: Inki Dae

drm/exynos: mixer: simplify mixer_graph_buffer()

2017-08-25T03:07:11+00:00

DRM core already checks in drm_atomic_plane_check() if the pixelformat is valid. Hence we can collapse the default case of the switch statement with the XRGB8888 case. No functional change. Signed-off-by: Tobias Jakobi Signed-off-by: Inki Dae

drm/exynos: mixer: simplify vp_video_buffer()

2017-08-25T03:05:56+00:00

DRM core already checks in drm_atomic_plane_check() if the pixelformat is valid. Hence we can drop the default case of the switch statement and collapse most of the code. Also rename the two booleans to reflect what true/false actually means, and to avoid mixing CrCb/NV21 descriptions. No functional change. Signed-off-by: Tobias Jakobi Signed-off-by: Inki Dae

drm/exynos: mixer: enable NV12MT support for the video plane

2017-08-25T03:04:51+00:00

The video processor supports a tiled version of the NV12 format, known as NV12MT in V4L2 terms. The support was removed in commit 083500baefd5f4c215a5a93aef2492c1aa775828 due to not being a real pixel format, but rather NV12 with a special memory layout. With the introduction of FB modifiers, we can now properly support this format again. Tested with a hacked up modetest from libdrm's test suite on an ODROID-X2 (Exynos4412). Signed-off-by: Tobias Jakobi Signed-off-by: Inki Dae

drm/exynos: mixer: fix chroma comment in vp_video_buffer()

2017-08-25T03:03:52+00:00

The current comment sounds like the division op is done to compensate for some hardware erratum. But the chroma plane having half the height of the luma plane is just the way NV12/NV21 is defined, so clarify this behaviour. Signed-off-by: Tobias Jakobi Signed-off-by: Inki Dae

drm/exynos/decon5433: use mode info stored in CRTC to detect i80 mode

2017-08-25T02:58:08+00:00

Since panel's mode of work is propagated properly from panel to DECON, there is no need to use redundant private device tree property. The only issue with such approach is that check for required interrupts should be postponed until panel communicate its requirements, ie to mode validation phase - mode_valid callback. Signed-off-by: Andrzej Hajda