aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2019-10-14drm/mxsfb: Update mxsfb to support a bridgeRobert Chiras4-21/+72
Currently, the MXSFB DRM driver only supports a panel. But, its output display signal can also be redirected to another encoder, like a DSI controller. In this case, that DSI controller may act like a drm_bridge. In order support this use-case too, this patch adds support for drm_bridge in mxsfb. Signed-off-by: Robert Chiras <robert.chiras@nxp.com> Tested-by: Guido Günther <agx@sigxcpu.org> Signed-off-by: Stefan Agner <stefan@agner.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1567078215-31601-2-git-send-email-robert.chiras@nxp.com
2019-10-14drm/i915/execlists: Assert tasklet is locked for process_csb()Chris Wilson3-3/+22
We rely on only the tasklet being allowed to call into process_csb(), so assert that is locked when we do. As the tasklet uses a simple bitlock, there is no strong lockdep checking so we must make do with a plain assertion that the tasklet is running and assume that we are the tasklet! v2: Fixup intel_gt_sanitize() to prepare each engine for the reset so that the locks are marked as held during the reset v3: Check for existent function pointers for very early sanitisation. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191014121336.30137-1-chris@chris-wilson.co.uk
2019-10-14drm/panfrost: Add missing GPU feature registersSteven Price1-0/+3
Three feature registers were declared but never actually read from the GPU. Add THREAD_MAX_THREADS, THREAD_MAX_WORKGROUP_SIZE and THREAD_MAX_BARRIER_SIZE so that the complete set are available. Fixes: 4bced8bea094 ("drm/panfrost: Export all GPU feature registers") Signed-off-by: Steven Price <steven.price@arm.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191014151515.13839-1-steven.price@arm.com
2019-10-14drm/dp-mst: fix warning on unused varLucas De Marchi1-2/+0
Fixes: 83fa9842afe7 ("drm/dp-mst: Drop connection_mutex check") Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191011010907.103309-8-lucas.demarchi@intel.com
2019-10-14drm/i915/ehl: Port C's hotplug interrupt is associated with TC1 bitsVivek Kasireddy2-4/+7
On platforms that have the MCC PCH, Port C's hotplug interrupt bits are mapped to TC1 bits. Suggested-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191011002618.3087-1-vivek.kasireddy@intel.com
2019-10-14drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pinVille Syrjälä1-6/+16
The first come first served apporoach to handling the VBT child device AUX ch conflicts has backfired. We have machines in the wild where the VBT specifies both port A eDP and port E DP (in that order) with port E being the real one. So let's try to flip the preference around and let the last child device win once again. Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@intel.com> Tested-by: Masami Ichikawa <masami256@gmail.com> Tested-by: Torsten <freedesktop201910@liggy.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111966 Fixes: 36a0f92020dc ("drm/i915/bios: make child device order the priority order") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191011202030.8829-1-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2019-10-14drm/i915/execlists: Tweak virtual unsubmissionChris Wilson2-4/+4
Since commit e2144503bf3b ("drm/i915: Prevent bonded requests from overtaking each other on preemption") we have restricted requests to run on their chosen engine across preemption events. We can take this restriction into account to know that we will want to resubmit those requests onto the same physical engine, and so can shortcircuit the virtual engine selection process and keep the request on the same engine during unwind. References: e2144503bf3b ("drm/i915: Prevent bonded requests from overtaking each other on preemption") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Ramlingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191013203012.25208-1-chris@chris-wilson.co.uk
2019-10-14drm/ttm: fix handling in ttm_bo_add_mem_to_lruChristian König1-2/+3
We should not add the BO to the swap LRU when the new mem is fixed and the TTM object about to be destroyed. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Kevin Wang <kevin1.wang@amd.com> Link: https://patchwork.freedesktop.org/patch/335246/
2019-10-14drm/omap: Remove set but not used variable 'err' in hdmi4_audio_configzhengbin1-2/+2
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/omapdrm/dss/hdmi4_core.c: In function hdmi4_audio_config: drivers/gpu/drm/omapdrm/dss/hdmi4_core.c:689:6: warning: variable err set but not used [-Wunused-but-set-variable] It is not used since commit f5bab2229190 ("OMAPDSS: HDMI: Add OMAP5 HDMI support") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/1570518949-47574-5-git-send-email-zhengbin13@huawei.com
2019-10-14drm/omap: Remove set but not used variable 'err' in hdmi5_audio_configzhengbin1-2/+2
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/omapdrm/dss/hdmi5_core.c: In function hdmi5_audio_config: drivers/gpu/drm/omapdrm/dss/hdmi5_core.c:812:6: warning: variable err set but not used [-Wunused-but-set-variable] It is not used since commit f5bab2229190 ("OMAPDSS: HDMI: Add OMAP5 HDMI support") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/1570518949-47574-4-git-send-email-zhengbin13@huawei.com
2019-10-14drm/omap: Remove set but not used variable 'tclk_trail'zhengbin1-2/+1
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/omapdrm/dss/dsi.c: In function dsi_proto_timings: drivers/gpu/drm/omapdrm/dss/dsi.c:3562:46: warning: variable tclk_trail set but not used [-Wunused-but-set-variable] It is not used since commit 9960aa7cb58c ("drm/omap: move omapdss & displays under omapdrm") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/1570518949-47574-3-git-send-email-zhengbin13@huawei.com
2019-10-14drm/omap: Remove set but not used variable 'plane'zhengbin1-3/+0
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/omapdrm/omap_fb.c: In function omap_framebuffer_update_scanout: drivers/gpu/drm/omapdrm/omap_fb.c:130:16: warning: variable plane set but not used [-Wunused-but-set-variable] It is not used since commit 2ecceeb53b19 ("drm/omap: Move buffer pitch/offset to drm_framebuffer") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: zhengbin <zhengbin13@huawei.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/1570518949-47574-2-git-send-email-zhengbin13@huawei.com
2019-10-14drm/ttm: Restore ttm prefaultingThomas Hellstrom1-9/+7
Commit 4daa4fba3a38 ("gpu: drm: ttm: Adding new return type vm_fault_t") broke TTM prefaulting. Since vmf_insert_mixed() typically always returns VM_FAULT_NOPAGE, prefaulting stops after the second PTE. Restore (almost) the original behaviour. Unfortunately we can no longer with the new vm_fault_t return type determine whether a prefaulting PTE insertion hit an already populated PTE, and terminate the insertion loop. Instead we continue with the pre-determined number of prefaults. Fixes: 4daa4fba3a38 ("gpu: drm: ttm: Adding new return type vm_fault_t") Cc: Souptick Joarder <jrdr.linux@gmail.com> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Christian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/330387/
2019-10-14drm/ttm: fix busy reference in ttm_mem_evict_firstChristian König1-2/+2
The busy BO might actually be already deleted, so grab only a list reference. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Thomas Hellström <thellstrom@vmware.com> Link: https://patchwork.freedesktop.org/patch/332877/
2019-10-14drm/i915/selftests: Check that GPR are cleared for new contextsChris Wilson1-19/+166
We want the general purpose registers to be clear in all new contexts so that we can be confident that no information is leaked from one to the next. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191014090757.32111-7-chris@chris-wilson.co.uk
2019-10-14drm/i915/selftests: Check known register values within the contextChris Wilson1-0/+126
Check the logical ring context by asserting that the registers hold expected start during execution. (It's a bit chicken-and-egg for how could we manage to execute our request if the registers were not being updated. Still, it's nice to verify that the HW is working as expected.) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191014090757.32111-6-chris@chris-wilson.co.uk
2019-10-14drm/i915/display: Squelch kerneldoc warningsChris Wilson1-2/+2
Just a parameter rename, drivers/gpu/drm/i915/display/intel_display.c:14425: warning: Function parameter or member '_new_plane_state' not described in 'intel_prepare_plane_fb' drivers/gpu/drm/i915/display/intel_display.c:14425: warning: Excess function parameter 'new_state' description in 'intel_prepare_plane_fb' drivers/gpu/drm/i915/display/intel_display.c:14534: warning: Function parameter or member '_old_plane_state' not described in 'intel_cleanup_plane_fb' drivers/gpu/drm/i915/display/intel_display.c:14534: warning: Excess function parameter 'old_state' description in 'intel_cleanup_plane_fb' Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191012080208.18774-1-chris@chris-wilson.co.uk
2019-10-14drm/i915/selftests: Fixup naked 64b divideChris Wilson1-5/+7
drivers/gpu/drm/i915/intel_memory_region.o: in function `igt_mock_contiguous': drivers/gpu/drm/i915/selftests/intel_memory_region.c:166: undefined reference to `__umoddi3' v2: promote target to u64 for consistency across all builds Reported-by: kbuild test robot <lkp@intel.com> Fixes: 2f0b97ca0211 ("drm/i915/region: support contiguous allocations") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191013114509.3405-1-chris@chris-wilson.co.uk
2019-10-13drm/rockchip: vop: add the definition of dclk_polNickey Yang3-22/+43
Some VOP's (such as px30) dclk_pol bit is at the last. So it is necessary to distinguish dclk_pol and pin_pol. Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com> Reviewed-by: Sandy Huang <hjc@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20191010034452.20260-2-nickey.yang@rock-chips.com
2019-10-13drm/rockchip: make rockchip_gem_alloc_object staticBen Dooks1-1/+1
The rockchip_gem_alloc_object function is not exported so make it static to avoid the following sparse warning: drivers/gpu/drm/rockchip/rockchip_drm_gem.c:297:28: warning: symbol 'rockchip_gem_alloc_object' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20191009121022.17478-1-ben.dooks@codethink.co.uk
2019-10-13drm/rockchip: include rockchip_drm_drv.hBen Dooks1-0/+1
Include rockchip_drm_drv.h for definition of vop_platform_driver to avoid the following sparse warning: drivers/gpu/drm/rockchip/rockchip_vop_reg.c:982:24: warning: symbol 'vop_platform_driver' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20191009132134.18384-1-ben.dooks@codethink.co.uk
2019-10-13drm/rockchip: rk3066_hdmi: Use devm_platform_ioremap_resource() in rk3066_hdmi_bind()Markus Elfring1-7/+1
Simplify this function implementation by using a known wrapper function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/0666bc0b-6624-21a0-47c4-b78e2a3b3ad5@web.de
2019-10-13drm/i915/perf: Avoid polluting the i915_oa_config with error pointersChris Wilson1-27/+25
Use a local variable to track the allocation errors to avoid polluting the struct and keep the free simple. Reported-by: kbuild test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191013095211.2922-1-chris@chris-wilson.co.uk
2019-10-12Merge tag 'for-linus-5.4-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tipLinus Torvalds1-10/+2
Pull xen fixes from Juergen Gross: - correct panic handling when running as a Xen guest - cleanup the Xen grant driver to remove printing a pointer being always NULL - remove a soon to be wrong call of of_dma_configure() * tag 'for-linus-5.4-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen: Stop abusing DT of_dma_configure API xen/grant-table: remove unnecessary printing x86/xen: Return from panic notifier
2019-10-12drm/i915/perf: Prefer using the pinned_ctx for emitting delays on configChris Wilson1-2/+7
When we are watching a particular context, we want the OA config to be applied inline with that context such that it takes effect before the next submission. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191012091056.28686-1-chris@chris-wilson.co.uk
2019-10-12drm/i915/perf: execute OA configuration from command streamLionel Landwerlin1-43/+156
We haven't run into issues with programming the global OA/NOA registers configuration from CPU so far, but HW engineers actually recommend doing this from the command streamer. On TGL in particular one of the clock domain in which some of that programming goes might not be powered when we poke things from the CPU. Since we have a command buffer prepared for the execbuffer side of things, we can reuse that approach here too. This also allows us to significantly reduce the amount of time we hold the main lock. v2: Drop the global lock as much as possible v3: Take global lock to pin global v4: Create i915 request in emit_oa_config() to avoid deadlocks (Lionel) v5: Move locking to the stream (Lionel) v6: Move active reconfiguration request into i915_perf_stream (Lionel) v7: Pin VMA outside request creation (Chris) Lock VMA before move to active (Chris) v8: Fix double free on stream->initial_oa_config_bo (Lionel) Don't allow interruption when waiting on active config request (Lionel) Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191012072308.30312-3-chris@chris-wilson.co.uk
2019-10-12drm/i915/perf: implement active wait for noa configurationsLionel Landwerlin8-2/+492
NOA configuration take some amount of time to apply. That amount of time depends on the size of the GT. There is no documented time for this. For example, past experimentations with powergating configuration changes seem to indicate a 60~70us delay. We go with 500us as default for now which should be over the required amount of time (according to HW architects). v2: Don't forget to save/restore registers used for the wait (Chris) v3: Name used CS_GPR registers (Chris) Fix compile issue due to rebase (Lionel) v4: Fix save/restore helpers (Umesh) v5: Move noa_wait from drm_i915_private to i915_perf_stream (Lionel) v6: Add missing struct declarations in i915_perf.h Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191012072308.30312-2-chris@chris-wilson.co.uk
2019-10-12drm/i915/perf: allow for CS OA configs to be created lazilyLionel Landwerlin4-53/+102
Here we introduce a mechanism by which the execbuf part of the i915 driver will be able to request that a batch buffer containing the programming for a particular OA config be created. We'll execute these OA configuration buffers right before executing a set of userspace commands so that a particular user batchbuffer be executed with a given OA configuration. This mechanism essentially allows the userspace driver to go through several OA configuration without having to open/close the i915/perf stream. v2: No need for locking on object OA config object creation (Chris) Flush cpu mapping of OA config (Chris) v3: Properly deal with the perf_metric lock (Chris/Lionel) v4: Fix oa config unref/put when not found (Lionel) v5: Allocate BOs for configurations on the stream instead of globally (Lionel) v6: Fix 64bit division (Chris) v7: Store allocated config BOs into the stream (Lionel) Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191012072308.30312-1-chris@chris-wilson.co.uk
2019-10-12drm/i915: Mark up "sentinel" requestsChris Wilson2-3/+13
Sometimes we want to emit a terminator request, a request that flushes the pipeline and allows no request to come after it. This can be used for a "preempt-to-idle" to ensure that upon processing the context-switch to that request, all other active contexts have been flushed. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191012070136.32058-1-chris@chris-wilson.co.uk
2019-10-12drm/i915/execlists: Prevent merging requests with conflicting flagsChris Wilson1-0/+3
We set out-of-bound parameters inside the i915_requests.flags field, such as disabling preemption or marking the end-of-context. We should not coalesce consecutive requests if they have differing instructions as we only inspect the last active request in a context. Thus if we allow a later request to be merged into the same execution context, it will mask any of the earlier flags. References: 2a98f4e65bba ("drm/i915: add infrastructure to hold off preemption on a request") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191011190325.10979-9-chris@chris-wilson.co.uk
2019-10-12drm/i915/perf: Replace global wakeref tracking with engine-pmChris Wilson2-10/+4
As we now have a specific engine to use OA on, exchange the top-level runtime-pm wakeref with the engine-pm. This still results in the same top-level runtime-pm, but with more nuances to keep the engine and its gt awake. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191011190325.10979-1-chris@chris-wilson.co.uk
2019-10-11drm/amdgpu/sdma5: fix mask value of POLL_REGMEM packet for pipe syncXiaojie Yuan1-1/+1
sdma will hang once sequence number to be polled reaches 0x1000_0000 Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Xiaojie Yuan <xiaojie.yuan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2019-10-11drm/amdgpu: Bail earlier when amdgpu.cik_/si_support is not set to 1Hans de Goede2-35/+35
Bail from the pci_driver probe function instead of from the drm_driver load function. This avoid /dev/dri/card0 temporarily getting registered and then unregistered again, sending unwanted add / remove udev events to userspace. Specifically this avoids triggering the (userspace) bug fixed by this plymouth merge-request: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59 Note that despite that being a userspace bug, not sending unnecessary udev events is a good idea in general. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490 Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2019-10-11Revert "drm/radeon: Fix EEH during kexec"Alex Deucher1-8/+0
This reverts commit 6f7fe9a93e6c09bf988c5059403f5f88e17e21e6. This breaks some boards. Maybe just enable this on PPC for now? Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205147 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2019-10-11drm/i915/selftests: Serialise write to scratch with its vma bindingChris Wilson1-0/+8
Add the missing serialisation on the request for a write into a vma to wait until that vma is bound before being executed by the GPU. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191011193620.14026-1-chris@chris-wilson.co.uk
2019-10-11drm/i915: Add an rcu_barrier option to i915_drop_cachesChris Wilson1-1/+6
Sometimes a test has to wait for RCU to complete a grace period and perform its callbacks, for example waiting for a close(fd) to actually perform the fput(filp) and so trigger all the callbacks such as closing GEM contexts. There is no trivial means of triggering an RCU barrier from userspace, so add one for our convenience in debugfs/i915_drop_caches Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.william.auld@gmail.com> Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191011173823.20432-1-chris@chris-wilson.co.uk
2019-10-11drm/msm/dsi: Implement reset correctlyJeffrey Hugo1-2/+4
On msm8998, vblank timeouts are observed because the DSI controller is not reset properly, which ends up stalling the MDP. This is because the reset logic is not correct per the hardware documentation. The documentation states that after asserting reset, software should wait some time (no indication of how long), or poll the status register until it returns 0 before deasserting reset. wmb() is insufficient for this purpose since it just ensures ordering, not timing between writes. Since asserting and deasserting reset occurs on the same register, ordering is already guaranteed by the architecture, making the wmb extraneous. Since we would define a timeout for polling the status register to avoid a possible infinite loop, lets just use a static delay of 20 ms, since 16.666 ms is the time available to process one frame at 60 fps. Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support") Cc: Hai Li <hali@codeaurora.org> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Reviewed-by: Sean Paul <sean@poorly.run> [seanpaul renamed RESET_DELAY to DSI_RESET_TOGGLE_DELAY_MS] Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191011133939.16551-1-jeffrey.l.hugo@gmail.com
2019-10-11drm/atmel-hlcdc: Use swap() where appropriateVille Syrjälä1-4/+1
@swap@ identifier TEMP; expression A,B; @@ - TEMP = A; - A = B; - B = TEMP; + swap(A, B); @@ type T; identifier swap.TEMP; @@ ( - T TEMP; | - T TEMP = {...}; ) ... when != TEMP Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Boris Brezillon <bbrezillon@kernel.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010131159.17346-3-ville.syrjala@linux.intel.com Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
2019-10-11drm/omap: add OMAP_BO flags to affect buffer allocationTomi Valkeinen1-2/+52
On SoCs with DMM/TILER, we have two ways to allocate buffers: normal dma_alloc or via DMM (which basically functions as an IOMMU). DMM can map 128MB at a time, and we only map the DMM buffers when they are used (i.e. not at alloc time). If DMM is present, omapdrm always uses DMM. There are use cases that require lots of big buffers that are being used at the same time by different IPs. At the moment the userspace has a hard maximum of 128MB. This patch adds three new flags that can be used by the userspace to solve the situation: OMAP_BO_MEM_CONTIG: The driver will use dma_alloc to get the memory. This can be used to avoid DMM if the userspace knows it needs more than 128M of memory at the same time. OMAP_BO_MEM_DMM: The driver will use DMM to get the memory. There's not much use for this flag at the moment, as on platforms with DMM it is used by default, but it's here for completeness. OMAP_BO_MEM_PIN: The driver will pin the memory at alloc time, and keep it pinned. This can be used to 1) get an error at alloc time if DMM space is full, and 2) get rid of the constant pin/unpin operations which may have some effect on performance. If none of the flags are given, the behavior is the same as currently. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010120000.1421-9-jjhiblot@ti.com
2019-10-11drm/omap: add omap_gem_validate_flags()Tomi Valkeinen1-5/+35
Add a helper function omap_gem_validate_flags() which validates the omap_bo flags passed from the userspace. Also drop the dev_err() message, as the userspace can cause that at will. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010120000.1421-8-jjhiblot@ti.com
2019-10-11drm/omap: cleanup OMAP_BO_SCANOUT useTomi Valkeinen1-4/+2
omap_gem_new() has a comment about OMAP_BO_SCANOUT which does not make sense. Also, for the TILER case, we drop OMAP_BO_SCANOUT flag for some reason. It's not clear what the original purpose of OMAP_BO_SCANOUT is, but presuming it means "scanout buffer, something that can be consumed by DSS", this patch cleans up the above issues. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010120000.1421-7-jjhiblot@ti.com
2019-10-11drm/omap: remove OMAP_BO_TILED defineTomi Valkeinen4-14/+14
OMAP_BO_TILED does not make sense, as OMAP_BO_TILED_* values are not bitmasks but normal values. As we already have OMAP_BO_TILED_MASK for the mask, we can remove OMAP_BO_TILED and use OMAP_BO_TILED_MASK instead. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010120000.1421-6-jjhiblot@ti.com
2019-10-11drm/omap: accept NULL for dma_addr in omap_gem_pinTomi Valkeinen1-2/+4
Allow NULL to be passed in 'dma_addr' for omap_gem_pin(), in case the caller does not need the dma_addr. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010120000.1421-4-jjhiblot@ti.com
2019-10-11drm/omap: add omap_gem_unpin_locked()Tomi Valkeinen1-7/+18
Add omap_gem_unpin_locked() which is a version of omap_gem_unpin() that expects the caller to hold the omap_obj lock. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010120000.1421-3-jjhiblot@ti.com
2019-10-11drm/omap: use refcount API to track the number of users of dma_addrJean-Jacques Hiblot1-22/+22
This would give us a WARN_ON() if the pin/unpin calls are unbalanced. Proposed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010120000.1421-2-jjhiblot@ti.com
2019-10-11drm/rockchip: Add optional support for CRTC gamma LUTEzequiel Garcia3-0/+124
Add an optional CRTC gamma LUT support, and enable it on RK3288. This is currently enabled via a separate address resource, which needs to be specified in the devicetree. The address resource is required because on some SoCs, such as RK3288, the LUT address is after the MMU address, and the latter is supported by a different driver. This prevents the DRM driver from requesting an entire register space. The current implementation works for RGB 10-bit tables, as that is what seems to work on RK3288. Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191010194351.17940-3-ezequiel@collabora.com
2019-10-11drm/i915/execlists: Only mark incomplete requests as -EIO on cancellingChris Wilson1-2/+6
Only the requests that have not completed do we want to change the status of to signal the -EIO when cancelling the inflight set of requests upon wedging. Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191011103345.26013-1-chris@chris-wilson.co.uk
2019-10-11drm/i915/execlists: Leave tell-tales as to why pending[] is badChris Wilson2-9/+32
Before we BUG out with bad pending state, leave a telltale as to which test failed. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010071434.31195-2-chris@chris-wilson.co.uk
2019-10-11drm/i915: Note the addition of timeslicing to the pretend schedulerChris Wilson1-0/+9
Since writing the comment that the scheduler is entirely passive, we've added minimal timeslicing which adds the most primitive of active elements (a timeout and reschedule). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010071434.31195-1-chris@chris-wilson.co.uk
2019-10-10drm/amdgpu/swSMU/navi: add feature toggles for more thingsAlex Deucher1-6/+18
Add toggles for more power features. Helpful in debugging. Reviewed-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Kevin Wang <kevin1.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.