aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2018-05-24drm/amdgpu: rework VM state machine lock handling v2Christian König2-49/+21
Only the moved state needs a separate spin lock protection. All other states are protected by reserving the VM anyway. v2: fix some more incorrect cases Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-24drm/amdgpu: Add runtime VCN PG supportRex Zhu2-18/+30
Enable support for dynamically powering up/down VCN on demand. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-24drm/amdgpu: Enable VCN static PG by default on RVRex Zhu1-1/+2
Enable static VCN powergating by default on Raven. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-24drm/amdgpu: Add VCN static PG support on RVRex Zhu2-1/+102
Implement static powergating suport on VCN. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-24drm/amdgpu: Enable VCN CG by default on RVRex Zhu1-1/+2
Enable VCN clockgating by default on Raven. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-24drm/amdgpu: Add static CG control for VCN on RVRex Zhu1-11/+39
Implement proper static clockgating support for VCN. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-24drm/i915: Look for an active kernel context before switchingChris Wilson6-15/+231
We were not very carefully checking to see if an older request on the engine was an earlier switch-to-kernel-context before deciding to emit a new switch. The end result would be that we could get into a permanent loop of trying to emit a new request to perform the switch simply to flush the existing switch. What we need is a means of tracking the completion of each timeline versus the kernel context, that is to detect if a more recent request has been submitted that would result in a switch away from the kernel context. To realise this, we need only to look in our syncmap on the kernel context and check that we have synchronized against all active rings. v2: Since all ringbuffer clients currently share the same timeline, we do have to use the gem_context to distinguish clients. As a bonus, include all the tracing used to debug the death inside suspend. v3: Test, test, test. Construct a selftest to exercise and assert the expected behaviour that multiple switch-to-contexts do not emit redundant requests. Reported-by: Mika Kuoppala <mika.kuoppala@intel.com> Fixes: a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual timelines") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180524081135.15278-1-chris@chris-wilson.co.uk
2018-05-24drm/i915: Pin the ring highChris Wilson1-0/+2
If we can use an unmappable ring, try to pin it out of the mappable aperture. This simple layout preference is to try and keep the mappable aperture reserved and available to handle GGTT mmapping requests from userspace without causing evictions and GPU stalls. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180521082131.13744-4-chris@chris-wilson.co.uk
2018-05-24drm/i915: Limit searching for PIN_HIGHChris Wilson1-1/+10
To no surprise (since we've flip-flopped over the use of PIN_HIGH a few times), doing a search by address over a pathologically fragmented address space is exceeding slow. To protect ourselves from nearly unbounded latency (think searching a million holes while under struct_mutex), limit the search for the highest available hole and fallback to best-fit if it fails. In the pathologically fragmented case, such as igt/gem_ctx_thrash, the effect is dramatic, bringing the runtime down from hours to seconds (depending on how many other slow searches you hit, e.g. alloc_iova() and alloc_vmap_area() both degrade to a slow rbtree walk after their small cache is exhausted). For the real world, the number of search steps is unlikely to be significant as we should only need to search once per new context. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180521082131.13744-3-chris@chris-wilson.co.uk
2018-05-24drm/mm: Add a search-by-address variant to only inspect a single holeChris Wilson3-2/+80
Searching for an available hole by address is slow, as there no guarantee that a hole will be available and so we must walk over all nodes in the rbtree before we determine the search was futile. In many cases, the caller doesn't strictly care for the highest available hole and was just opportunistically laying out the address space in a preferred order. In such cases, the caller can accept any address and would rather do so then do a slow walk. To be able to mix search strategies, the caller wants to tell the drm_mm how long to spend on the search. Without a good guide for what should be the best split, start with a request to try once at most. That is return the top-most (or lowest) hole if it fulfils the alignment and size requirements. v2: Documentation, by why of example (selftests) and kerneldoc. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180521082131.13744-2-chris@chris-wilson.co.uk
2018-05-24drm/mm: Reject over-sized allocation requests earlyChris Wilson1-25/+57
As we keep an rbtree of available holes sorted by their size, we can very easily determine if there is any hole large enough that might satisfy the allocation request. This helps when dealing with a highly fragmented address space and a request for a search by address. To cache the largest size, we convert into the cached rbtree variant which tracks the leftmost node for us. However, currently we sorted into ascending size order so the leftmost node is the smallest, and so to make it the largest hole we need to invert our sorting. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180521082131.13744-1-chris@chris-wilson.co.uk
2018-05-24drm/psr: Fix missed entry in PSR setup time table.Dhinakaran Pandiyan1-0/+1
Entry corresponding to 220 us setup time was missing. I am not aware of any specific bug this fixes, but this could potentially result in enabling PSR on a panel with a higher setup time requirement than supported by the hardware. I verified the value is present in eDP spec versions 1.3, 1.4 and 1.4a. Fixes: 6608804b3d7f ("drm/dp: Add drm_dp_psr_setup_time()") Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jose Roberto de Souza <jose.souza@intel.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Tarun Vyas <tarun.vyas@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-3-dhinakaran.pandiyan@intel.com
2018-05-24drm/i915/psr: Fix ALPM cap check for PSR2Dhinakaran Pandiyan1-10/+10
While touching the code around this, I noticed that absence of ALPM capability does not stop us from enabling PSR2. But, the spec unambiguously states that ALPM is required for PSR2 and so does this commit that introduced this code drm/i915/psr: enable ALPM for psr2 As per edp1.4 spec , alpm is required for psr2 operation as it's used for all psr2 main link power down management and alpm enable bit must be set for psr2 operation. Cc: Jose Roberto de Souza <jose.souza@intel.com> Cc: Vathsala Nagaraju <vathsala.nagaraju@intel.com> Reviewed-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com> Reviewed-by: Tarun Vyas <tarun.vyas@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-6-dhinakaran.pandiyan@intel.com
2018-05-24drm/i915/psr: Fall back to max. synchronization latency if DPCD read failsDhinakaran Pandiyan1-2/+2
Noticed that we assume the best case of 0 latency when the DPCD read fails, reasonable pessimism is safer. eDP spec does say that if latency is greater than 8, the panel supplier needs to provide it. I didn't see anything specific in the VBT for this, so let's go with 8 frames as a fallback. Cc: Jose Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-5-dhinakaran.pandiyan@intel.com
2018-05-24drm/i915/psr: Avoid unnecessary DPCD read of DP_PSR_CAPSDhinakaran Pandiyan1-10/+1
intel_dp->psr_dpcd already has the required values. Cc: Jose Roberto de Souza <jose.souza@intel.com> Reviewed-by: Tarun Vyas <tarun.vyas@intel.com> Reviewed-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-4-dhinakaran.pandiyan@intel.com
2018-05-24drm/i915/psr: Check for SET_POWER_CAPABLE bit at PSR init time.Dhinakaran Pandiyan2-8/+11
By moving the check from psr_compute_config() to psr_init_dpcd(), we get to set the dev_priv->psr.sink_support flag only when the panel is capable of changing power state. An additional benefit is that the check will be performed only at init time instead of every atomic_check. This should change the psr_basic IGT failures on HSW to skips. v2: Return early when SET_POWER_CAPABLE bit is 0 (Jose) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106217 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106346 Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-2-dhinakaran.pandiyan@intel.com
2018-05-24drm/i915/psr: Avoid DPCD reads when panel does not support PSRDhinakaran Pandiyan1-6/+8
Ville noticed that we are unncessarily reading DPCD's after knowing panel did not support PSR. Looks like this check that was present earlier got removed unintentionally, let's put it back. While we do this, add the PSR version number in the debug print. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Tarun Vyas <tarun.vyas@intel.com> Reviewed-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-1-dhinakaran.pandiyan@intel.com
2018-05-24drm/i915/psr: Nuke PSR support for VLV and CHVDhinakaran Pandiyan6-270/+27
PSR hardware and hence the driver code for VLV and CHV deviates a lot from their DDI counterparts. While the feature has been disabled for a long time now, retaining support for these platforms is a maintenance burden. There have been multiple refactoring commits to just keep the existing code for these platforms in line with the rest. There are known issues that need to be fixed to enable PSR on these platforms, and there is no PSR capable platform in CI to ensure the code does not break again if we get around to fixing the existing issues. On account of all these reasons, let's nuke this code for now and bring it back if a need arises in the future. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180511230059.19387-1-dhinakaran.pandiyan@intel.com
2018-05-24drm/i915/psr: vbt change for psrVathsala Nagaraju4-27/+72
For psr block #9, the vbt description has moved to options [0-3] for TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt structure. Since spec does not mention from which VBT version this change was added to vbt.bsf file, we cannot depend on bdb->version check to change for all the platforms. There is RCR inplace for GOP team to provide the version number to make generic change. Since Kabylake with bdb version 209 is having this change, limiting this change to gen9_bc and version 209+ to unblock google. Tested on skl(bdb version 203,without options) and kabylake(bdb version 209,212) having new options. bspec 20131 v2: (Jani and Rodrigo) move the 165 version check to intel_bios.c v3: Jani Move the abstraction to intel_bios. v4: Jani Rename tp*_wakeup_time to have "us" suffix. For values outside range[0-3],default to max 2500us. Old decimal value was wake up time in multiples of 100us. v5: Jani and Rodrigo Handle option 2 in default condition. Print oustide range value. For negetive values default to 2500us. v6: Jani Handle default first and then fall through for case 2. v7: Rodrigo Apply this change for IS_GEN9_BC and vbt version > 209 v8: Puthik Add new function vbt_psr_to_us. v9: Jani Change to v7 version as it's more readable. DK add comment /*fall through*/ after case2. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Puthikorn Voravootivat <puthik@chromium.org> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Maulik V Vaghela <maulik.v.vaghela@intel.com> Signed-off-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1526981243-2745-1-git-send-email-vathsala.nagaraju@intel.com
2018-05-24gpu: drm: vgem: Change return type to vm_fault_tSouptick Joarder1-3/+2
Use new return type vm_fault_t for fault handler. Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com> Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180416150232.GA26745@jordon-HP-15-Notebook-PC
2018-05-24drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReadsYunwei Zhang2-0/+39
L3Bank could be fused off in hardware for debug purpose, and it is possible that subslice is enabled while its corresponding L3Bank pairs are disabled. In such case, if MCR packet control register(0xFDC) is programed to point to a disabled bank pair, a MMIO read into L3Bank range will return 0 instead of correct values. However, this is not going to be the case in any production silicon. Therefore, we only check at initialization and issue a warning should this really happen. References: HSDES#1405586840 v2: - use fls instead of find_last_bit (Chris) - use is_power_of_2() instead of counting bit set (Chris) v3: - rebase on latest tip v5: - Added references (Mika) - Move local variable into scope where they are used (Ursulin) - use a new local variable to reduce long line of code (Ursulin) v6: - Some coding style and use more local variables for clearer logic (Ursulin) Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Yunwei Zhang <yunwei.zhang@intel.com> Reviewed-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1526683285-24861-1-git-send-email-yunwei.zhang@intel.com
2018-05-24drm/i915/icl: Enable WaProgramMgsrForCorrectSliceSpecificMmioReadsYunwei Zhang2-3/+12
WaProgramMgsrForCorrectSliceSpecificMmioReads applies for Icelake as well. References: HSD#1405586840, BSID#0575 v2: - GEN11 mask is different from its predecessors. (Oscar) - Better separate GEN10 and GEN11. (Oscar) Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Yunwei Zhang <yunwei.zhang@intel.com> Reviewed-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1526683232-24753-1-git-send-email-yunwei.zhang@intel.com
2018-05-24drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReadsYunwei Zhang3-5/+54
WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO read into Slice/Subslice specific registers, MCR packet control register(0xFDC) needs to be programmed to point to any enabled slice/subslice pair. Otherwise, incorrect value will be returned. However, that means each subsequent MMIO read will be forwarded to a specific slice/subslice combination as read is unicast. This is OK since slice/subslice specific register values are consistent in almost all cases across slice/subslice. There are rare occasions such as INSTDONE that this value will be dependent on slice/subslice combo, in such cases, we need to program 0xFDC and recover this after. This is already covered by read_subslice_reg. Also, 0xFDC will lose its information after TDR/engine reset/power state change. References: HSD#1405586840, BSID#0575 v2: - use fls() instead of find_last_bit() (Chris) - added INTEL_SSEU to extract sseu from device info. (Chris) v3: - rebase on latest tip v5: - Added references (Mika) - Change the ordered of passing arguments and etc. (Ursulin) v7: - Moved WA explanation Comments(Oscar) - Rebased. v8: - Renamed sanitize_mcr to calculate_s_ss_select. (Oscar) - calculate s/ss selector instead of whole mcr. (Oscar) v9: - Updated function name (Oscar) - Remove redundant variables (Oscar) v10: - Separate pre-GEN10 and GEN11 mask. (Oscar) Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Yunwei Zhang <yunwei.zhang@intel.com> Reviewed-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1526683197-24656-1-git-send-email-yunwei.zhang@intel.com
2018-05-24drm/exynos: Fix default value for zpos plane propertyMarek Szyprowski1-5/+4
The default zpos property for all planes in Exynos DRM was fixed as zero. Fix this by providing proper value provided by hardware drivers, which typically matches hardware window number. Reported-by: Seung-Woo Kim <sw0312.kim@samsung.com> Fixes: e47726a11e11 ("drm/exynos: use generic code for managing zpos plane property") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2018-05-24drm/exynos: Fix error value in exynos_drm_crtc_get_by_type()Marek Szyprowski1-1/+1
EPERM is not the correct error value when the driver is not able to get its resources. Change it to ENODEV. Reported-by: Russell King - ARM Linux <linux@armlinux.org.uk> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2018-05-24drm/exynos/dsi: mask frame-done interruptAndrzej Hajda1-3/+3
DSI driver is not really interested in this interrupt. It causes only unnecessary code execution of interrupt handler and could possibly cause FIFO overflow - as it triggers DSI interrupt handler to process next DSI transfer. With this patch we will get rid of about 30 IRQ handler calls per second. Fixes: e6f988a45857 ("drm/exynos: dsi: add support for Exynos5433") Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2018-05-24drm/amdgpu: Add SOC15_WAIT_ON_RREG macro defineRex Zhu1-0/+15
Add new macro to wait on a register field to be a specific value. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-24drm/amdgpu: Add CG/PG flags for VCNRex Zhu1-1/+2
Define new clock and powergating flags for VCN block. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-24drm/amd/pp: Add smu support for VCN powergating on RVRex Zhu1-1/+18
Add the powerplay callback for powergating VCN (same as UVD and VCE). Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-24drm/amdgpu: skip CG for VCN when late_init/finiRex Zhu1-0/+2
VCN clockgating is handled manually like VCE and UVD. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-24drm/amd/pp: fix a couple locking issuesRex Zhu1-12/+19
We should return unlock on the error path Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-24drm/amd/pp: Fix static checker warningRex Zhu3-19/+14
error: uninitialized symbol 'xxxx' Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-23drm/amdgpu/gmc9: disable partial wr rmw if ECC is not enabledAlex Deucher1-0/+1
The vbios mistakenly sets this bit on some boards without ECC. This can lead to reduced performance in some workloads. Disable the bit if the board does not have ECC. Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-23drm/amdgpu: add a df 1.7 implementation of enable_ecc_force_par_wr_rmwAlex Deucher1-0/+8
Needed for proper memory setup depending on whether ECC is enabled on a particular board. Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-23drm/amdgpu: add new DF callback for ECC setupAlex Deucher1-0/+2
The ForceParWrRMW setting needs to be enabled for ECC, but disabled when ECC is not enabled. Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-23drm/amdgpu: add new DF 1.7 register defsAlex Deucher2-0/+8
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-23Remove calls to suspend/resume atomic helpers from amdgpu_device_gpu_recover. (v2)Andrey Grodzovsky1-9/+1
First of all it's already being called from the display code from amd_ip_funcs.suspend/resume hooks. Second of all, the place in amdgpu_device_gpu_recover it's being called is wrong for GPU stalls since it is called BEFORE we cancel and force completion of all in flight jobs which were not yet processed. So, as Bas pointed in the ticket we will try to wait for fence in amdgpu_pm_compute_clocks but the pipe is hanged so we end up in deadlock. v2: remove unused variable Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106500 Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-05-24drm/exynos: decon: Add support for hardware windows no 4 and 5Marek Szyprowski1-9/+12
Enable support for 2 more hardware windows. This require enabling a few more clocks and set proper plane type for all windows. In the new configuration primary plane uses hardware window no 3 and cursor uses window no 5. The remaining hardware windows are used for overlays. This gives us an overlay plane both below and above primary plane for both Decon and DeconTV (which uses hardware window nr 0 for background). Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2018-05-23drm/i915/icl: Disable pipe CSC and gamma in cursor planeJosé Roberto de Souza1-4/+6
'Pipe CSC enable' bit is more than just deprecated in ICL+, it was disabled in commit 077ef1f09c25 ("drm/i915/icl: Don't set pipe CSC/Gamma in PLANE_COLOR_CTL") for primary and sprite planes as it was causing those planes to be rendered as always black but it was not disabled in cursor plane, also causing it to be rendered as black. As mentioned in the commit referenced above, this is a workaround too and the CSC and gamma per plane values needs to be setup before enable CSC and gamma again. BSpec: 4278 and 7635 Cc: James Ausmus <james.ausmus@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180518201547.15793-1-jose.souza@intel.com
2018-05-23drm/i915/selftests: Pin the mock kernel contextChris Wilson2-10/+14
The driver assumes that the kernel context is pinned and always available for use from any process or atomic context. Make it so for selftesting as well! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180523142346.27953-1-chris@chris-wilson.co.uk
2018-05-23drm/vmwgfx: Schedule an fb dirty update after resumeThomas Hellstrom3-21/+7
We have had problems displaying fbdev after a resume and as a workaround we have had to call vmw_fb_refresh(). This has had a number of unwanted side-effects. The root of the problem was, however that the coalesced fbdev dirty region was not empty on the first dirty_mark() after a resume, so a flush was never scheduled. Fix this by force scheduling an fbdev flush after resume, and remove the workaround. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com>
2018-05-23drm/i915: WARN if power sequencer is not connected to the LVDS port on pre-ilkVille Syrjälä1-0/+5
We don't support using the power sequencer with other ports besides LVDS on pre-ilk platforms. WARN if someone has mistakenly connected the power sequencer to the wrong port. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180518152931.13104-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2018-05-23drm/i915: Implement the missing bits of assert_panel_unlocked()Ville Syrjälä1-2/+16
Add the missing eDP port handling into assert_panel_unlocked(). We now have intel_dp_port_enabled() which makes this trivial. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180518152931.13104-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2018-05-23drm/i915: Allow eDP on port C in theoryVille Syrjälä1-2/+12
The power sequencer has bits to allow DP C to be used for eDP. Currently we assume this will never happen, but I guess it could theoretically be a thing. Make the code do the right thing in that case, and toss in a MISSING_CASE() for any other port. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180518152931.13104-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2018-05-23drm/i915: Clean up DP pipe select bitsVille Syrjälä4-95/+91
Clean up the DP pipe select bits. To make the whole situation a bit less ugly we'll start to share the same code between .get_hw_state(), the port state asserts, and the VLV power sequencer code. v2: Return PIPE_A for cpt/ppt when the port isn't selected by any transcoder. Returning INVALID_PIPE explodes *somewhere* on some machines (can't immediately see where though). This now matches the old behaviour. v3: Order the defines shift,mask,value (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180518152931.13104-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2018-05-23drm/i915: Nuke intel_trans_dp_port_sel()Ville Syrjälä1-25/+14
for_each_encoder_on_crtc() is legacy and shouldn't be used by atomic drivers. Let's throw out intel_trans_dp_port_sel() and replace it with intel_get_crtc_new_encoder() which looks the atomic state instead. Since we now have to call intel_get_crtc_new_encoder() during the commit phase we'll need to plumb in the top level atomic state. The crtc_state->state pointers are no longer valid at that point. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180518152931.13104-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2018-05-23drm/i915: Parametrize TRANS_DP_PORT_SELVille Syrjälä2-21/+11
Parametrize the TRANS_DP_PORT_SEL macros. v2: WARN for bogus ports (Jani) Order the defines mask,value (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180518152931.13104-2-ville.syrjala@linux.intel.com
2018-05-23drm/i915: Move intel_ddi_get_crtc_new_encoder() out from ddi codeVille Syrjälä3-32/+30
The ddi code no longer uses intel_ddi_get_crtc_new_encoder(). Move it elsewhere where we have some users left. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180518152931.13104-1-ville.syrjala@linux.intel.com
2018-05-23drm/vmwgfx: Fix host logging / guestinfo reading error pathsThomas Hellstrom1-17/+31
The error paths were leaking opened channels. Fix by using dedicated error paths. Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
2018-05-23drm/vmwgfx: Fix 32-bit VMW_PORT_HB_[IN|OUT] macrosThomas Hellstrom1-8/+17
Depending on whether the kernel is compiled with frame-pointer or not, the temporary memory location used for the bp parameter in these macros is referenced relative to the stack pointer or the frame pointer. Hence we can never reference that parameter when we've modified either the stack pointer or the frame pointer, because then the compiler would generate an incorrect stack reference. Fix this by pushing the temporary memory parameter on a known location on the stack before modifying the stack- and frame pointers. Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>