kernel/linux.git/drivers/gpu/drm/exynos, branch v4.19.39

drm/exynos/mixer: fix MIXER shadow registry synchronisation code

2019-04-20T07:15:58+00:00

[ Upstream commit 6a3b45ada960ac475ec2b4103d43e57943b2b8d3 ] MIXER on Exynos5 SoCs uses different synchronisation method than Exynos4 to update internal state (shadow registers). Apparently the driver implements it incorrectly. The rule should be as follows: - do not request updating registers until previous request was finished, ie. MXR_CFG_LAYER_UPDATE_COUNT must be 0. - before setting registers synchronisation on VSYNC should be turned off, ie. MXR_STATUS_SYNC_ENABLE should be reset, - after finishing MXR_STATUS_SYNC_ENABLE should be set again. The patch hopefully implements it correctly. Below sample kernel log from page fault caused by the bug: [ 25.670038] exynos-sysmmu 14650000.sysmmu: 14450000.mixer: PAGE FAULT occurred at 0x2247b800 [ 25.677888] ------------[ cut here ]------------ [ 25.682164] kernel BUG at ../drivers/iommu/exynos-iommu.c:450! [ 25.687971] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [ 25.693778] Modules linked in: [ 25.696816] CPU: 5 PID: 1553 Comm: fb-release_test Not tainted 5.0.0-rc7-01157-g5f86b1566bdd #136 [ 25.705646] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 25.711710] PC is at exynos_sysmmu_irq+0x1c0/0x264 [ 25.716470] LR is at lock_is_held_type+0x44/0x64 v2: added missing MXR_CFG_LAYER_UPDATE bit setting in mixer_enable_sync Reported-by: Marian Mihailescu Signed-off-by: Andrzej Hajda Signed-off-by: Inki Dae Signed-off-by: Sasha Levin

Revert "drm/exynos/decon5433: implement frame counter"

2018-11-27T15:13:04+00:00

[ Upstream commit 6ca469e22a30992b4478d2ab88737c70667c1e00 ] This reverts commit 0586feba322e1de05075700eb4b835c8b683e62b This patch makes it to need get_vblank_counter callback in crtc to get frame counter from decon driver. However, drm_dev->max_vblank_count is a member unique to vendor's DRM driver but in case of ARM DRM, some CRTC devices don't provide the frame counter value. As a result, this patch made extension and clone mode not working. Instead of this patch, we may need separated max_vblank_count which belongs to each CRTC device, or need to implement frame counter emulation for them who don't support HW frame counter. Signed-off-by: Inki Dae Signed-off-by: Sasha Levin

drm/exynos: Use selected dma_dev default iommu domain instead of a fake one

2018-10-01T00:25:31+00:00

Instead of allocating a fake IOMMU domain for all Exynos DRM components, simply reuse the default IOMMU domain of the already selected DMA device. This allows some design changes in IOMMU framework without breaking IOMMU support in Exynos DRM. Signed-off-by: Marek Szyprowski Reviewed-by: Robin Murphy Signed-off-by: Inki Dae

drm/exynos/mixer: Remove unused local variable priv

2018-07-24T07:28:53+00:00

Remove local variable 'priv' to fix GCC warning: drivers/gpu/drm/exynos/exynos_mixer.c: In function 'mixer_initialize': drivers/gpu/drm/exynos/exynos_mixer.c:840:29: warning: variable 'priv' set but not used [-Wunused-but-set-variable] Signed-off-by: Krzysztof Kozlowski Signed-off-by: Inki Dae

drm/exynos: Ensure suspended runtime PM state during system suspend

2018-07-24T07:28:53+00:00

Add calls to pm_runtime_force_{suspend,resume} as SYSTEM_SLEEP_PM_OPS for all drivers for the real Exynos DRM hardware modules. This ensures that the resources will be released for the system PM suspend/resume cycle. Exynos DRM core already takes care of suspending the whole display pipeline before PM callbacks of the real devices are called. Signed-off-by: Marek Szyprowski Signed-off-by: Inki Dae

drm/exynos: Suspend/resume display pipeline as early/late as possible

2018-07-24T07:28:47+00:00

In the current code, exynos_drm_suspend() function is called after all real devices (CRTCs, Encoders, etc) are suspended, because Exynos DRM virtual platform device is created as last device in the system (as a part of DRM registration). None of the devices for real hardware modules has its own system suspend/resume callbacks, so it doesn't change any order of the executed code, but it has a side-effect: runtime PM callbacks for real devices are not executed, because those devices are considered by PM core as already suspended. This might cause issues on boards with complex pipelines, where something depends on the runtime PM state of the given device. To ensure that exynos_drm_suspend() is called before any suspend callback from the real devices, assign it to .prepare callback. Same for exynos_drm_resume(), using .complete callback ensures that all real devices have been resumed when calling it. Signed-off-by: Marek Szyprowski Signed-off-by: Inki Dae

drm/exynos: Drop useless check from exynos_drm_{suspend,resume}

2018-07-24T07:19:02+00:00

The virtual Exynos DRM device has no runtime PM enabled, so checking for its runtime suspended state is useless. Signed-off-by: Marek Szyprowski Signed-off-by: Inki Dae

drm/exynos: Use common exynos_drm_gem_get()/put() functions for GEM lookup

2018-07-24T06:50:20+00:00

Use recently introduced common helpers to unify GEM handling code. Signed-off-by: Marek Szyprowski Signed-off-by: Inki Dae

drm/exynos: gem: Simplify access to exynos GEM objects

2018-07-24T06:46:46+00:00

Replace all calls to exynos_drm_gem_get_{dma_addr,size}, by a simpler function exynos_drm_gem_get(). This lets the caller to get access to exynos_drm_gem object and extract any information about GEM object without searching object tree for getting each parameter. Signed-off-by: Marek Szyprowski Signed-off-by: Inki Dae

drm/exynos: g2d: Convert to driver component API

2018-07-24T06:40:29+00:00

Exynos G2D driver is the last client of the custom Exynos 'sub-driver' framework. In the current state it doesn't really resolve any of the issues it has been designed for, as Exynos DRM is already built only as a single kernel module. Remove the custom 'sub-driver' framework and simply use generic component framework also in G2D driver. Signed-off-by: Marek Szyprowski Signed-off-by: Inki Dae