drm/core: Do not preserve framebuffer on rmfb, v4.
It turns out that preserving framebuffers after the rmfb call breaks
vmwgfx userspace. This was originally introduced because it was thought
nobody relied on the behavior, but unfortunately it seems there are
exceptions.
drm_framebuffer_remove may fail with -EINTR now, so a straight revert
is impossible. There is no way to remove the framebuffer from the lists
and active planes without introducing a race because of the different
locking requirements. Instead call drm_framebuffer_remove from a
workqueue, which is unaffected by signals.
Changes since v1:
- Add comment.
Changes since v2:
- Add fastpath for refcount = 1. (danvet)
Changes since v3:
- Rebased.
- Restore lastclose framebuffer removal too.
Cc: stable@vger.kernel.org #v4.4+ Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.")
Testcase: kms_rmfb_basic
References: https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Thomas Hellstrom <thellstrom@vmware.com> #v3 Tested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/6c63ca37-0e7e-ac7f-a6d2-c7822e3d611f@linux.intel.com
Dave Airlie [Wed, 4 May 2016 23:56:30 +0000 (09:56 +1000)]
Merge tag 'topic/drm-misc-2016-05-04' of git://anongit.freedesktop.org/drm-intel into drm-next
Ofc I promise just a few leftovers for drm-misc and somehow it's the
biggest pull. But really mostly trivial stuff:
- MAINTAINERS updates from Emil
- rename async to nonblock in atomic_commit to avoid the confusion between
nonblocking ioctl and async flip (= not vblank synced), from Maarten.
Needs to be regened with newer drivers, but probably only after -rc1 to
catch them all.
- actually lockless gem_object_free, plus acked driver conversion patches.
All the trickier prep stuff already is in drm-next.
- Noralf's nice work for generic defio support in our fbdev emulation.
Keeps the udl hack, and qxl is tested by Gerd.
* tag 'topic/drm-misc-2016-05-04' of git://anongit.freedesktop.org/drm-intel: (47 commits)
drm: Fixup locking WARN_ON mistake around gem_object_free_unlocked
drm/etnaviv: Use lockless gem BO free callback
drm/imx: Use lockless gem BO free callback
drm/radeon: Use lockless gem BO free callback
drm/amdgpu: Use lockless gem BO free callback
drm/gem: support BO freeing without dev->struct_mutex
MAINTAINERS: Add myself for the new VC4 (RPi GPU) graphics driver.
MAINTAINERS: Add a bunch of legacy (UMS) DRM drivers
MAINTAINERS: Add a few DRM drivers by Dave Airlie
MAINTAINERS: List the correct git repo for the Renesas DRM drivers
MAINTAINERS: Update the files list for the Renesas DRM drivers
MAINTAINERS: Update the files list for the Armada DRM driver
MAINTAINERS: Update the files list for the Rockchip DRM driver
MAINTAINERS: Update the files list for the Exynos DRM driver
MAINTAINERS: Add maintainer entry for the VMWGFX DRM driver
MAINTAINERS: Add maintainer entry for the MSM DRM driver
MAINTAINERS: Add maintainer entry for the Nouveau DRM driver
MAINTAINERS: Update the files list for the Etnaviv DRM driver
MAINTAINERS: Remove unneded wildcard for the i915 DRM driver
drm/atomic: Add WARN_ON when state->acquire_ctx is not set.
...
Daniel Vetter [Wed, 4 May 2016 12:10:44 +0000 (14:10 +0200)]
drm: Fixup locking WARN_ON mistake around gem_object_free_unlocked
Embarrassingly while fixing up the old paths for i915 I managed to
misplace a locking check for the new _unlocked paths. That's what I
get for not retesting on radeon.
Fixes: 9f0ba539d13a ("drm/gem: support BO freeing without dev->struct_mutex") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Daniel Vetter [Tue, 26 Apr 2016 17:29:49 +0000 (19:29 +0200)]
drm/etnaviv: Use lockless gem BO free callback
No dev->struct_mutex anywhere to be seen.
Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Acked-by: Lucas Stach <l.stach@pengutronix.de> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-17-git-send-email-daniel.vetter@ffwll.ch
Daniel Vetter [Mon, 2 May 2016 08:40:51 +0000 (10:40 +0200)]
drm/gem: support BO freeing without dev->struct_mutex
Finally all the core gem and a lot of drivers are entirely free of
dev->struct_mutex depencies, and we can start to have an entirely
lockless unref path.
To make sure that no one who touches the core code accidentally breaks
existing drivers which still require dev->struct_mutex I've made the
might_lock check unconditional.
While at it de-inline the ref/unref functions, they've become a bit
too big.
v2: Make it not leak like a sieve.
v3: Review from Lucas:
- drop != NULL in pointer checks.
- fixup copypasted kerneldoc to actually match the functions.
v4:
Add __drm_gem_object_unreference as a fastpath helper for drivers who
abolished dev->struct_mutex, requested by Chris.
v5: Fix silly mistake in drm_gem_object_unreference_unlocked caught by
intel-gfx CI - I checked for gem_free_object instead of
gem_free_object_unlocked ...
Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> (v3) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v4) Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1462178451-1765-1-git-send-email-daniel.vetter@ffwll.ch
Dave Airlie [Wed, 4 May 2016 07:43:23 +0000 (17:43 +1000)]
Merge tag 'drm-amdkfd-next-2016-05-04' of git://people.freedesktop.org/~gabbayo/linux into drm-next
Here are a few amdkfd patches for 4.7, all of them fixes according to
the Coccinelle tool.
* tag 'drm-amdkfd-next-2016-05-04' of git://people.freedesktop.org/~gabbayo/linux:
amdkfd: Trim unnescessary intermediate err var in kfd_chardev.c
amdkfd: Trim off unnescessary semicolon from kfd_packet_manager.c
amdkfd: Use the canonical form in branch predicates
Dave Airlie [Wed, 4 May 2016 07:37:20 +0000 (17:37 +1000)]
Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
Summary:
- Support for pipeline clock between KMS drivers.
. Exynos SoC is required to control clocks across KMS drivers
according to Exynos SoC version. So this patch refactos
some relevant codes and provides generic solution for it.
- Add Exynos5433 SoC support to HDMI parts - HDMI and DECON-TV.
- Add HW trigger mode support to CRTC drivers.
. In case of using i80 Panel, some Exynos SoC supports HW trigger
mode so this patch makes trigger mode - HW or SW trigger - to be
set according to SoC version properly.
- And some cleanups and regression fixups.
* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: (39 commits)
drm/exynos: clean up register definions for fimd and decon
drm/exynos: decon: clean up interface type
drm/exynos: fimd: add HW trigger support
drm/exynos: clean up wait_for_vblank
drm/exynos: mixer: use generic of_device_get_match_data helper
drm/exynos: mixer: remove support for non-dt platforms
drm/exynos: hdmi: use generic of_device_get_match_data helper
drm/exynos: rotator: use generic of_device_get_match_data helper
drm/exynos: fimd: use generic of_device_get_match_data helper
drm/exynos: dsi: use generic of_device_get_match_data helper
drm/exynos: exynos5433_decon: use generic of_device_get_match_data helper
drm/exynos: convert clock_enable crtc callback to pipeline clock
drm/exynos/mixer: enable HDMI-PHY before configuring MIXER
drm/exynos/decon5433: enable HDMI-PHY before configuring DECON
drm/exynos: add support for pipeline clock to the framework
drm/exynos: add helper to get crtc from pipe
drm/exynos/decon5433: do not protect window in plane disable
drm/exynos/decon5433: reset decon on start
drm/exynos/decon5433: fix DECON standalone update
drm/exynos/hdmi: remove registry dump
...
Dave Airlie [Wed, 4 May 2016 07:30:53 +0000 (17:30 +1000)]
Merge tag 'drm-vc4-next-2016-05-02' of https://github.com/anholt/linux into drm-next
This pull request brings in DPI panel support, gamma ramp support, and
render nodes for vc4.
* tag 'drm-vc4-next-2016-05-02' of https://github.com/anholt/linux:
drm/vc4: Add missing render node support
drm/vc4: Add support for gamma ramps.
drm/vc4: Fix NULL deref in HDMI init error path
drm/vc4: Add DPI driver
drm: Add an encoder and connector type enum for DPI.
Dave Airlie [Wed, 4 May 2016 07:28:09 +0000 (17:28 +1000)]
Merge tag 'topic/drm-misc-2016-04-29' of git://anongit.freedesktop.org/drm-intel into drm-next
- prep work for struct_mutex-less gem_free_object
- more invasive/tricky mst fixes from Lyude for broken hw. I discussed
this with Ville/Jani and we all agreed more soaking in -next would be
real good this late in the -rc cycle. They're cc: stable too to make
sure they're not getting lost. Feel free to cherry-pick those four if
you disagree.
- few small things all over
* tag 'topic/drm-misc-2016-04-29' of git://anongit.freedesktop.org/drm-intel:
drm/atomic: Add missing drm_crtc_internal.h include
drm/dp: Allow signals to interrupt drm_aux-dev reads/writes
drm: Quiet down drm_mode_getresources
drm: Quiet down drm_mode_getconnector
drm: Protect dev->filelist with its own mutex
drm: Make drm_vm_open/close_locked private to drm_vm.c
drm: Hide master MAP cleanup in drm_bufs.c
drm: Forbid legacy MAP functions for DRIVER_MODESET
drm: Push struct_mutex into ->master_destroy
drm: Move drm_getmap into drm_bufs.c and give it a legacy prefix
drm: Put legacy lastclose work into drm_legacy_dev_reinit
drm: Give drm_agp_clear drm_legacy_ prefix
drm/sysfs: Annote lockless show functions with READ_ONCE
MAINTAINERS: Update the files list for the GMA500 DRM driver
drm: rcar-du: Fix compilation warning
drm/i915: Get rid of intel_dp_dpcd_read_wake()
drm/dp_helper: Perform throw-away read before actual read in drm_dp_dpcd_read()
drm/dp_helper: Retry aux transactions on all errors
drm/dp_helper: Always wait before retrying native aux transactions
Dave Airlie [Wed, 4 May 2016 07:25:30 +0000 (17:25 +1000)]
Merge tag 'drm-intel-next-2016-04-25' of git://anongit.freedesktop.org/drm-intel into drm-next
- more userptr cornercase fixes from Chris
- clean up and tune forcewake handling (Tvrtko)
- more underrun fixes from Ville, mostly for ilk to appeas CI
- fix unclaimed register warnings on vlv/chv and enable the debug code to catch
them by default (Ville)
- skl gpu hang fixes for gt3/4 (Mika Kuoppala)
- edram improvements for gen9+ (Mika again)
- clean up gpu reset corner cases (Chris)
- fix ctx/ring machine deaths on snb/ilk (Chris)
- MOCS programming for all engines (Peter Antoine)
- robustify/clean up vlv/chv irq handler (Ville)
- split gen8+ irq handlers into ack/handle phase (Ville)
- tons of bxt rpm fixes (mostly around firmware interactions), from Imre
- hook up panel fitting for dsi panels (Ville)
- more runtime PM fixes all over from Imre
- shrinker polish (Chris)
- more guc fixes from Alex Dai and Dave Gordon
- tons of bugfixes and small polish all over (but with a big focus on bxt)
* tag 'drm-intel-next-2016-04-25' of git://anongit.freedesktop.org/drm-intel: (142 commits)
drm/i915: Update DRIVER_DATE to 20160425
drm/i915/bxt: Explicitly clear the Turbo control register
drm/i915: Correct the i915_frequency_info debugfs output
drm/i915: Macros to convert PM time interval values to microseconds
drm/i915: Make RPS EI/thresholds multiple of 25 on SNB-BDW
drm/i915: Fake HDMI live status
drm/i915/bxt: Force reprogramming a PHY with invalid HW state
drm/i915/bxt: Wait for PHY1 GRC done if PHY0 was already enabled
drm/i915/bxt: Use PHY0 GRC value for HW state verification
drm/i915: use dev_priv directly in gen8_ppgtt_notify_vgt
drm/i915/bxt: Enable DC5 during runtime resume
drm/i915/bxt: Sanitize DC state tracking during system resume
drm/i915/bxt: Don't uninit/init display core twice during system suspend/resume
drm/i915: Inline intel_suspend_complete
drm/i915/kbl: Don't WARN for expected secondary MISC IO power well request
drm/i915: Fix eDP low vswing for Broadwell
drm/i915: check for ERR_PTR from i915_gem_object_pin_map()
drm/i915/guc: local optimisations and updating comments
drm/i915/guc: drop cached copy of 'wq_head'
drm/i915/guc: keep GuC doorbell & process descriptor mapped in kernel
...
Emil Velikov [Thu, 21 Apr 2016 23:03:54 +0000 (00:03 +0100)]
MAINTAINERS: Update the files list for the Etnaviv DRM driver
Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@arm.linux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1461279842-28695-7-git-send-email-emil.l.velikov@gmail.com
drm/atomic: Add WARN_ON when state->acquire_ctx is not set.
When I was writing an atomic wrapper for rmfb, I ran into the
following backtrace from lockdep:
=============================================
[ INFO: possible recursive locking detected ]
4.5.0-patser+ #4696 Tainted: G U
---------------------------------------------
kworker/2:2/2608 is trying to acquire lock:
(crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffc00c9ddc>] drm_modeset_lock+0x7c/0x120 [drm]
but task is already holding lock:
(crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffc00c98cd>] modeset_backoff+0x8d/0x220 [drm]
other info that might help us debug this:
Possible unsafe locking scenario:
Arnd Bergmann [Mon, 2 May 2016 11:00:26 +0000 (13:00 +0200)]
drm/fsl-dcu: add COMMON_CLK dependency
The fsl dcu now uses the clk-provider interfaces, which are not available
when CONFIG_COMMON_CLK is disabled:
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c: In function 'fsl_dcu_drm_probe':
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c:362:20: error: implicit declaration of function '__clk_get_name' [-Werror=implicit-function-declaration]
pix_clk_in_name = __clk_get_name(pix_clk_in);
This adds a Kconfig dependency to prevent the driver from being enabled
in this case.
Mark Yao [Fri, 29 Apr 2016 03:37:20 +0000 (11:37 +0800)]
drm/rockchip: vop: fix iommu crash with async atomic
After async atomic_commit callback, drm_atomic_clean_old_fb will
clean all old fb, but because async, the old fb may be also on
the vop hardware, dma will access the old fb buffer, clean old
fb will cause iommu page fault.
Reference the fb and unreference it when the fb actuall swap out
from vop hardware.
Mark Yao [Tue, 19 Apr 2016 02:13:27 +0000 (10:13 +0800)]
drm/rockchip: support non-iommu buffer path
Some rockchip vop not support iommu, need use non-iommu
buffer for it. And if we get iommu issues, we can compare
the issues with non-iommu path, that would help the debug.
John Keeping [Tue, 5 Apr 2016 13:50:32 +0000 (14:50 +0100)]
drm/rockchip: don't leak iommu mapping
arm_iommu_attach_device() takes its own reference to the mapping we give
it. Since we do not keep a reference to the mapping ourselves, we must
release it before returning.
Also fix the error path, which fails to release the mapping if it has
called arm_iommu_detach_device() since that clears archdata.mapping.
Eric Anholt [Fri, 15 Apr 2016 06:16:05 +0000 (23:16 -0700)]
drm/vc4: Add missing render node support
There shouldn't be any other driver support necessary, since none of
the driver-specific ioctls ever required auth, and none of them deal
with modesetting.
Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Eric Anholt [Fri, 1 Apr 2016 01:38:20 +0000 (18:38 -0700)]
drm/vc4: Add support for gamma ramps.
We could possibly save a bit of power by not requesting gamma
conversion when the ramp happens to be 1:1, but at least if all the
CRTCs are off the SRAM will be disabled.
This should fix brightness sliders in a lot of fullscreen games.
drm/atomic: Rename async parameter to nonblocking.
This is the first step of renaming async commit to nonblocking commit.
The flag passed by userspace is NONBLOCKING, and async has a different
meaning for page flips, where it means as soon as possible.
Fixing up comments in drm core is done manually, to make sure I didn't
miss anything.
For drivers, the following cocci script is used to rename bool async to bool
nonblock:
@@
identifier I =~ "^async";
identifier func;
@@
func(..., bool
- I
+ nonblock
, ...)
{
<...
- I
+ nonblock
...>
}
@@
identifier func;
type T;
identifier I =~ "^async";
@@
T func(..., bool
- I
+ nonblock
, ...);
Use the fbdev deferred io support in drm_fb_helper.
The (struct fb_ops *)->fb_{fillrect,copyarea,imageblit} functions will
now schedule a worker instead of being flushed directly like it was
previously (recorded when in atomic).
This adds fbdev deferred io support if CONFIG_FB_DEFERRED_IO is enabled.
The driver has to provide a (struct drm_framebuffer_funcs *)->dirty()
callback to get notification of fbdev framebuffer changes.
If the dirty() hook is set, then fb_deferred_io is set up automatically
by the helper.
Two functions have been added so that the driver can provide a dirty()
function:
- drm_fbdev_cma_init_with_funcs()
This makes it possible for the driver to provided a custom
(struct drm_fb_helper_funcs *)->fb_probe() function.
- drm_fbdev_cma_create_with_funcs()
This is used by the .fb_probe hook to set a driver provided
(struct drm_framebuffer_funcs *)->dirty() function.
Export fb_deferred_io_mmap so drivers can change vma->vm_page_prot.
When the framebuffer memory is allocated using dma_alloc_writecombine()
instead of vmalloc(), I get cache syncing problems on ARM.
This solves it:
Could this have been done in the core?
Drivers that don't set (struct fb_ops *)->fb_mmap, gets a call to
fb_pgprotect() at the end of the default fb_mmap implementation
(drivers/video/fbdev/core/fbmem.c). This is an architecture specific
function that on many platforms uses pgprot_writecombine(), but not on
all. And looking at some of the fb_mmap implementations, some of them
sets vm_page_prot to nocache for instance, so I think the safest bet is
to do this in the driver and not in the fbdev core. And we can't call
fb_pgprotect() from fb_deferred_io_mmap() either because we don't have
access to the file pointer that powerpc needs.
This adds deferred io support to drm_fb_helper.
The fbdev framebuffer changes are flushed using the callback
(struct drm_framebuffer *)->funcs->dirty() by a dedicated worker
ensuring that it always runs in process context.
For those wondering why we need to be able to handle atomic calling
contexts: Both panic paths and cursor code and fbcon blanking can run
from atomic. See
drm/qxl: Change drm_fb_helper_sys_*() calls to sys_*()
Now that drm_fb_helper gets deferred io support, the
drm_fb_helper_sys_{fillrect,copyarea,imageblit} functions will schedule
a worker that will call the (struct drm_framebuffer *)->funcs->dirty()
function. This will break this driver so use the
sys_{fillrect,copyarea,imageblit} functions directly.
drm/udl: Change drm_fb_helper_sys_*() calls to sys_*()
Now that drm_fb_helper gets deferred io support, the
drm_fb_helper_sys_{fillrect,copyarea,imageblit} functions will schedule
a worker that will call the (struct drm_framebuffer *)->funcs->dirty()
function. This will break this driver so use the
sys_{fillrect,copyarea,imageblit} functions directly.
This patch cleans up interface type relevant codes.
Trigger mode is determinded only by i80 mode, which isn't
related to Display types - HDMI or Display controller.
So this patch makes the trigger mode to be set only in case of
i80 mode - For DECON-TV, HW Trigger mode is flaged mandatorily
because HDMI Timing Generator generates VSYNC signal
which works as a hardware trigger.
Changelog v2.
- If interface type is HDMI then set out_type to I80.
- fix compile warning.
Until now, Exynos DRM only supported SW trigger which was set
SWTRGCMD bit of TRIGCON register by CPU to transfer scanout
buffer to Display bus device or panel.
With this patch, the transmission to Display bus device or
panel will be initiated by FIMD controller.
This patch cleans up wait_for_vblank relevant codes.
wait_for_vblank callback isn't used anymore in Exynos drm driver
so it removes relevant codes. However, display controllers -
FIMD and DECON - still use this function driver internally
to ensure shadow registers to be updated, which resolves
page fault issue so keep it.
Andrzej Hajda [Wed, 23 Mar 2016 13:25:58 +0000 (14:25 +0100)]
drm/exynos: add support for pipeline clock to the framework
Components belonging to the same pipeline often requires
synchronized clocks. Such clocks are sometimes provided
by external clock controller, but they can be also provided by
pipeline components. In latter case there should be a way
to access them from another component belonging to the same pipeline.
This is the case of:
- DECON,FIMD -> HDMI and HDMI-PHY clock,
- FIMD -> DP and DP clock in FIMD.
The latter case has been solved by clock_enable callback
in exynos_drm_crtc_ops. This solutin will not work with
HDMI path as in this case clock is provided by encoder.
This patch provides more generic solution allowing to register
pipeline clock during initialization in exynos_drm_crtc structure.
This way the clock will be easily accessible from both components.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
Andrzej Hajda [Wed, 23 Mar 2016 13:15:13 +0000 (14:15 +0100)]
drm/exynos/hdmi: add PHY power off signal handling
HDMI-PHY power off bit defaults to 0 in older HDMI versions.
In case of Exynos5433 it defaults to 1. To make code
consistent across all versions this bit is always unset/set in
power on/off sequences.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
Andrzej Hajda [Wed, 23 Mar 2016 13:15:12 +0000 (14:15 +0100)]
drm/exynos/hdmi: fix PHY configuration sequence
Proper PHY configuration should be as follow:
1. set HDMI clock parents to OSCCLK.
2. reconfigure PHY.
3. set HDMI clock parents to PHY.
4. wait for PLL stabilization.
The patch fixes it and consolidates the code.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
projects / karo-tx-linux.git / log