- 15 Feb, 2016 11 commits
-
-
Andrzej Hajda authored
Decon requires that clocks should be disabled in reverse order. Otherwise system hangs. Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
Inki Dae <inki.dae@samsung.com>
-
Marek Szyprowski authored
dma_mmap_attrs() should be called with cpu address returned by dma_alloc_attrs(). Existing code however passed pages array base as cpu address. This worked only by a pure luck on ARM architecture. This patch fixes this issue. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
Marek Szyprowski authored
BIT_IRQS_ENABLED was never set because of incorrect test in decon_vlank_enable() function, what resulted in lack of enabling vblank support. This patch fixes this issue. Signed-off-by:
-
Marek Szyprowski authored
Patch ebf3fd40 ("drm/exynos: add pm_runtime to DECON 5433") removed some code from decon_enable() function, but it left set_bit(BIT_SUSPENDED, &ctx->flags) call, which was earlier called only in error path. This patch removes it, what finally lets driver to go out of suspended state. Signed-off-by:
-
Marek Szyprowski authored
This patch fixes issue introduced by commit cf67cc9a ("drm/exynos: remove struct exynos_drm_display"), which removed assigning of drm bridge to drm encoder. Lack of it caused that no bridge callbacks were called on encoder enable/disable actions. Signed-off-by:
-
Marek Szyprowski authored
There is no point exposing all internal functions to global kernel name space, so make all internals functions static. Signed-off-by:
-
Marek Szyprowski authored
MIC is SoC component and important part of kms pipeline on Exynos5433, so convert it to use component framework like other KMS/CRTC drivers. MIC driver is already listed on KMS component driver list in Exynos DRM core, so without this conversion, initialization of Exynos DRM core fails on Exynos 5433 SoC. Signed-off-by:
-
Marek Szyprowski authored
Drivers should use devm_clk* interface instead of of_clk* functions. Signed-off-by:
-
Marek Szyprowski authored
This patch fixes compilation warnings (on 64bit architectures) and bugs related to casting pointers through 32bit integers. Signed-off-by:
-
Marek Szyprowski authored
Drivers should use %p for printing pointers instead of hardcoding them as hexadecimal integers. This patch fixes compilation warnings on 64bit architectures. Signed-off-by:
-
Joonyoung Shim authored
Because PLAT_SAMSUNG isn't include exynos SoCs for arm64, but ARCH_EXYNOS can do it. And it also needs to add ARCH_S3C64XX instead of PLAT_SAMSUNG. Signed-off-by:
Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by:
-
- 14 Feb, 2016 1 commit
-
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
i915 display fixes mostly. * tag 'drm-intel-fixes-2016-02-12' of git://anongit.freedesktop.org/drm-intel: drm/i915: fix error path in intel_setup_gmbus() drm/i915/skl: Fix typo in DPLL_CFGCR1 definition drm/i915/skl: Don't skip mst encoders in skl_ddi_pll_select() drm/i915: Pretend cursor is always on for ILK-style WM calculations (v2) drm/i915/dp: reduce missing TPS3 support errors to debug logging drm/i915/dp: abstract training pattern selection drm/i915/dsi: skip gpio element execution when not supported drm/i915/dsi: don't pass arbitrary data to sideband drm/i915/dsi: defend gpio table against out of bounds access drm/i915/bxt: Don't save/restore eDP panel power during suspend (v3) drm/i915: Allow i915_gem_object_get_page() on userptr as well
-
- 10 Feb, 2016 9 commits
-
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
radeon and amdgpu fixes for 4.5. Highlights: - powerplay fixes for amdgpu - race fixes in the sub-allocator in radeon and amdgpu - hibernate fix for amdgpu - fix a possible circular locking in userptr handling in amdgpu * 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux: (21 commits) drm/amdgpu: fix issue with overlapping userptrs drm/radeon: hold reference to fences in radeon_sa_bo_new drm/amdgpu: remove unnecessary forward declaration drm/amdgpu: hold reference to fences in amdgpu_sa_bo_new (v2) drm/amdgpu: fix s4 resume drm/amdgpu/cz: plumb pg flags through to powerplay drm/amdgpu/tonga: plumb pg flags through to powerplay drma/dmgpu: move cg and pg flags into shared headers drm/amdgpu: remove unused cg defines drm/amdgpu: add a cgs interface to fetch cg and pg flags drm/amd/powerplay/tonga: disable vce pg drm/amd/powerplay/tonga: disable uvd pg drm/amd/powerplay/cz: disable vce pg drm/amd/powerplay/cz: disable uvd pg drm/amdgpu: be consistent with uvd cg flags drm/amdgpu: clean up vce pg flags for cz/st drm/amdgpu: handle vce pg flags properly drm/amdgpu: handle uvd pg flags properly drm/amdgpu/dpm/ci: switch over to the common pcie caps interface drm/amdgpu/cik: don't mess with aspm if gpu is root bus ...
-
Christian König authored
Otherwise we could try to evict overlapping userptr BOs in get_user_pages(), leading to a possible circular locking dependency. Signed-off-by:
Christian König <christian.koenig@amd.com> Acked-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
Nicolai Hähnle authored
An arbitrary amount of time can pass between spin_unlock and radeon_fence_wait_any, so we need to ensure that nobody frees the fences from under us. Based on the analogous fix for amdgpu. Signed-off-by:
Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-by:
-
Nicolai Hähnle authored
Signed-off-by:
-
Nicolai Hähnle authored
An arbitrary amount of time can pass between spin_unlock and fence_wait_any_timeout, so we need to ensure that nobody frees the fences from under us. A stress test (rapidly starting and killing hundreds of glxgears instances) ran into a deadlock in fence_wait_any_timeout after about an hour, and this race condition appears to be a plausible cause. v2: agd: rebase on upstream Signed-off-by:
-
Flora Cui authored
No need to re-init asic if it's already been initialized. Skip IB tests since kernel processes are frozen in thaw. Signed-off-by:
Flora Cui <Flora.Cui@amd.com> Reviewed-by:
-
Rasmus Villemoes authored
This fails to undo the setup for pin==0; moreover, something interesting happens if the setup failed already at pin==0. Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Fixes: f899fc64 ("drm/i915: use GMBUS to manage i2c links") Cc: stable@vger.kernel.org Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455048677-19882-3-git-send-email-linux@rasmusvillemoes.dk (cherry picked from commit 2417c8c0) Signed-off-by:
-
Lyude authored
We accidentally point both cfgcr registers for the second shared DPLL to the same location in i915_reg.h. This results in a lot of hw pipe state mismatches whenever we try to do a modeset that requires allocating the DPLL to a CRTC: [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr1 (expected 0x80000168, found 0x000004a5) [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in base.adjusted_mode.crtc_clock (expected 108000, found 49500) [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in port_clock (expected 108000, found 49500) This usually ends up causing blank monitors, since the DPLL never can get set to the right clock. Fixes: 086f8e84 ("drm/i915: Prefix raw register defines with underscore") Signed-off-by:
Lyude <cpaul@redhat.com> Cc: drm-intel-fixes@lists.freedesktop.org Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1454600601-21900-1-git-send-email-cpaul@redhat.com (cherry picked from commit da3b891b) Signed-off-by:
-
Lyude authored
We don't actually check for INTEL_OUTPUT_DP_MST at all in here, as a result we skip assigning a DPLL to any DP MST ports, which makes link training fail: [ 1442.933896] [drm:intel_power_well_enable] enabling DDI D power well [ 1442.933905] [drm:skl_set_power_well] Enabling DDI D power well [ 1442.933957] [drm:intel_mst_pre_enable_dp] 0 [ 1442.935474] [drm:intel_dp_set_signal_levels] Using signal levels 00000000 [ 1442.935477] [drm:intel_dp_set_signal_levels] Using vswing level 0 [ 1442.935480] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0 [ 1442.936190] [drm:intel_dp_set_signal_levels] Using signal levels 05000000 [ 1442.936193] [drm:intel_dp_set_signal_levels] Using vswing level 1 [ 1442.936195] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 1 [ 1442.936858] [drm:intel_dp_set_signal_levels] Using signal levels 08000000 [ 1442.936862] [drm:intel_dp_set_signal_levels] Using vswing level 2 … [ 1442.998253] [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up [ 1442.998512] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to train DP, aborting After which the pipe state goes completely out of sync: [ 70.075596] [drm:check_crtc_state] [CRTC:25] [ 70.075696] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in ddi_pll_sel (expected 0x00000000, found 0x00000001) [ 70.075747] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in shared_dpll (expected -1, found 0) [ 70.075798] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.ctrl1 (expected 0x00000000, found 0x00000021) [ 70.075840] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr1 (expected 0x00000000, found 0x80400173) [ 70.075884] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr2 (expected 0x00000000, found 0x000003a5) [ 70.075954] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in base.adjusted_mode.crtc_clock (expected 262750, found 72256) [ 70.075999] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in port_clock (expected 540000, found 148500) And if you're especially lucky, it keeps going downhill: [ 83.309256] Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler [ 83.309265] [ 83.309265] ================================= [ 83.309266] [ INFO: inconsistent lock state ] [ 83.309267] 4.5.0-rc1Lyude-Test #265 Not tainted [ 83.309267] --------------------------------- [ 83.309268] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. [ 83.309270] Xorg/1194 [HC0[1]:SC0[0]:HE1:SE1] takes: [ 83.309293] (&(&dev_priv->uncore.lock)->rlock){?.-...}, at: [<ffffffffa02a6073>] gen9_write32+0x63/0x400 [i915] [ 83.309293] {IN-HARDIRQ-W} state was registered at: [ 83.309297] [<ffffffff810e84f4>] __lock_acquire+0x9c4/0x1d00 [ 83.309299] [<ffffffff810ea1be>] lock_acquire+0xce/0x1c0 [ 83.309302] [<ffffffff8177d936>] _raw_spin_lock_irqsave+0x56/0x90 [ 83.309321] [<ffffffffa02a5492>] gen9_read32+0x52/0x3d0 [i915] [ 83.309332] [<ffffffffa024beea>] gen8_irq_handler+0x27a/0x6a0 [i915] [ 83.309337] [<ffffffff810fdbc1>] handle_irq_event_percpu+0x41/0x300 [ 83.309339] [<ffffffff810fdeb9>] handle_irq_event+0x39/0x60 [ 83.309341] [<ffffffff811010b4>] handle_edge_irq+0x74/0x130 [ 83.309344] [<ffffffff81009073>] handle_irq+0x73/0x120 [ 83.309346] [<ffffffff817805f1>] do_IRQ+0x61/0x120 [ 83.309348] [<ffffffff8177e6d6>] ret_from_intr+0x0/0x20 [ 83.309351] [<ffffffff815f5105>] cpuidle_enter_state+0x105/0x330 [ 83.309353] [<ffffffff815f5367>] cpuidle_enter+0x17/0x20 [ 83.309356] [<ffffffff810dbe1a>] call_cpuidle+0x2a/0x50 [ 83.309358] [<ffffffff810dc1dd>] cpu_startup_entry+0x26d/0x3a0 [ 83.309360] [<ffffffff817701da>] rest_init+0x13a/0x140 [ 83.309363] [<ffffffff81f2af8e>] start_kernel+0x475/0x482 [ 83.309365] [<ffffffff81f2a315>] x86_64_start_reservations+0x2a/0x2c [ 83.309367] [<ffffffff81f2a452>] x86_64_start_kernel+0x13b/0x14a Fixes: 82d35437 ("drm/i915/skl: Implementation of SKL DPLL programming") Signed-off-by:
-
- 09 Feb, 2016 1 commit
-
-
Matt Roper authored
Due to our lack of two-step watermark programming, our driver has historically pretended that the cursor plane is always on for the purpose of watermark calculations; this helps avoid serious flickering when the cursor turns off/on (e.g., when the user moves the mouse pointer to a different screen). That workaround was accidentally dropped as we started working toward atomic watermark updates. Since we still aren't quite there yet with two-stage updates, we need to resurrect the workaround and treat the cursor as always active. v2: Tweak cursor width calculations slightly to more closely match the logic we used before the atomic overhaul began. (Ville) Cc: simdev11@outlook.com Cc: manfred.kitzbichler@gmail.com Cc: drm-intel-fixes@lists.freedesktop.org Reported-by: simdev11@outlook.com Reported-by: manfred.kitzbichler@gmail.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93892 Fixes: 43d59eda ("drm/i915: Eliminate usage of plane_wm_parameters from ILK-style WM code (v2)") Signed-off-by:Matt Roper <matthew.d.roper@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1454479611-6804-1-git-send-email-matthew.d.roper@intel.com (cherry picked from commit b2435692) Signed-off-by:
-
- 08 Feb, 2016 18 commits
-
-
Alex Deucher authored
Enable vce and uvd pg based on single set of pg flags. Reviewed-by:
Eric Huang <JinHuiEric.Huang@amd.com> Signed-off-by:
-
Alex Deucher authored
Enable vce and uvd pg based on single set of pg flags. Reviewed-by:
-
Alex Deucher authored
So they can be used by powerplay. Reviewed-by:
-
Alex Deucher authored
Leftover from radeon. Reviewed-by:
-
Alex Deucher authored
Needed to pass the cg and pg info to powerplay. Reviewed-by:
-
Alex Deucher authored
Not working reliably yet. Reviewed-by:
-
Alex Deucher authored
Not working reliably yet. Reviewed-by:
-
Alex Deucher authored
Not working reliably yet. Reviewed-by:
-
Alex Deucher authored
Not working reliably yet. Reviewed-by:
-
Alex Deucher authored
Don't do anything if the uvd cg flags are not set. Reviewed-by:
-
Alex Deucher authored
It was already disabled elsewhere, make it offical. Reviewed-by:
-
Alex Deucher authored
Don't attempt to start/stop the vce block if pg is disabled. Reviewed-by:
-
Alex Deucher authored
Don't attempt to start/stop the uvd block if pg is disabled. Reviewed-by:
-
Alex Deucher authored
We already query this at driver init, so use that info. Also handles virtualization cases. Reviewed-by:
monk liu <monk.liu@amd.com> Signed-off-by:
-
Alex Deucher authored
Pcie registers may not be available in a virtualized environment. Reviewed-by:
-
Alex Deucher authored
Allows the user to force the supported pcie gen and lane config on both the asic and the chipset. Useful for debugging pcie problems and for virtualization where we may not be able to query the pcie bridge caps. Default to: gen: chipset 1/2, asic 1/2/3 lanes: 1/2/4/8/16 v2: fix bare metal case Reviewed-by:
-
Jani Nikula authored
Per spec, TPS3 support is mandatory for downstream devices that support HBR2. We've therefore logged errors on HBR2 without TPS3 since commit 1da7d713 Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Sep 3 11:16:08 2015 +0300 drm/i915: ignore link rate in TPS3 selection However, it seems there are real world devices out there that just aren't spec compliant, and still work at HBR2 using TPS2. So reduce the error message to debug logging. Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Reviewed-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92932 Fixes: 1da7d713 ("drm/i915: ignore link rate in TPS3 selection") Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by:
-
Jani Nikula authored
Make it cleaner to add more checks in the function. No functional changes. Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Reviewed-by:
-
