- 18 Jan, 2018 5 commits
-
-
Ramalingam C authored
HDCP compliant Repeaters can support max of 127 devices and max depth of 7 for downstream topology. If these max limits are exceeded, repeater will set the topology error flags MAX_CASCADE_EXCEEDED and/or MAX_DEVS_EXCEEDED in Bstatus followed by asserting READY/CP_IRQ for HDCP transmitter. This patch check for these error flags as soon as READY bit is asserted. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> [seanpaul fixed checkpatch alignment issue] Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1516254488-4971-5-git-send-email-ramalingam.c@intel.com
-
Ramalingam C authored
Second stage of HDCP authentication starts at CP_IRQ or at the assertion of READY bit from Repeater. Till then repeater will be authenticating with its downstream devices. So authenticated device count, depth and ksv_list readable from repeaters are valid only after assertion of READY/CP_IRQ. This patch makes sure that READY is polled before reading any topology information. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1516254488-4971-4-git-send-email-ramalingam.c@intel.com
-
Ramalingam C authored
Second stage of HDCP authentication required only if the HDCP sink is a repeater. This patch imposes above condition on second stage HDCP authentication. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1516254488-4971-3-git-send-email-ramalingam.c@intel.com
-
Ramalingam C authored
This patch extends the Key load process and hdcp initialization for few more capable intel platforms i.e. HSW, BDW and BXT+. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> [seanpaul fixed checkpatch issues] Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1516254488-4971-2-git-send-email-ramalingam.c@intel.com
-
Chris Wilson authored
drivers/gpu/drm/i915/intel_dp.c: In function ‘intel_dp_hdcp_check_link’: drivers/gpu/drm/i915/intel_dp.c:5191:26: error: ?: using integer constants in boolean context [-Werror=int-in-bool-context] return ret >= 0 ? -EIO : ret; Fixes: 20f24d77 ("drm/i915: Implement HDCP for DisplayPort") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180118161025.22700-1-chris@chris-wilson.co.uk
-
- 09 Jan, 2018 2 commits
-
-
Sean Paul authored
Instead of always trying to disable HDCP. Only run hdcp_disable when the state is not UNDESIRED. This will catch cases where it's enabled and also cases where enable failed and the state is left in DESIRED mode. Note that things won't blow up if disable is attempted while already disabled, it's just bad form. Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180109185330.16853-1-seanpaul@chromium.org
-
Sean Paul authored
Port E doesn't have HDCP support, and Port F is disabled. Don't setup the hdcp shim on those. Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180109185401.16911-1-seanpaul@chromium.org
-
- 08 Jan, 2018 9 commits
-
-
Sean Paul authored
This patch adds HDCP support for DisplayPort connectors by implementing the intel_hdcp_shim. Most of this is straightforward read/write from/to DPCD registers. One thing worth pointing out is the Aksv output bit. It wasn't easily separable like it's HDMI counterpart, so it's crammed in with the rest of it. Changes in v2: - Moved intel_hdcp_check_link out of intel_dp_check_link and only call it on short pulse. Since intel_hdcp_check_link does its own locking, this ensures we don't deadlock when intel_dp_check_link is called holding connection_mutex. - Rebased on drm-intel-next Changes in v3: - Initialize new worker Changes in v4: - Use intel_hdcp_init (Daniel) - Check for reauth requests in check_link (Ram) Changes in v5: - None Changes in v6: - Fix build warnings when printing ssize_t Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180108195545.218615-10-seanpaul@chromium.org
-
Sean Paul authored
This patch adds HDCP support for HDMI connectors by implementing the intel_hdcp_shim. Nothing too special, just a bunch of DDC reads/writes. Changes in v2: - Rebased on drm-intel-next Changes in v3: - Initialize new worker Changes in v4: - Remove SKL_ prefix from most register names (Daniel) - Wrap sanity checks in WARN_ON (Daniel) - Consolidate the enable/disable functions into one toggle fn - Use intel_hdcp_init (Daniel) Changes in v5: - checkpatch whitespace nits Changes in v6: - None Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180108195545.218615-9-seanpaul@chromium.org
-
Sean Paul authored
Once the Aksv is available in the PCH, we need to get it on the wire to the receiver via DDC. The hardware doesn't allow us to read the value directly, so we need to tell GMBUS to source the Aksv internally and send it to the right offset on the receiver. The way we do this is to initiate an indexed write where the index is the Aksv register offset. We write dummy values to GMBUS3 as if we were sending the key, and the hardware slips in the "real" values when it goes out. Changes in v2: - None Changes in v3: - Uses new index write feature (Ville) Changes in v4: - None Changes in v5: - checkpatch whitespace fix Changes in v6: - None Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180108195545.218615-8-seanpaul@chromium.org
-
Sean Paul authored
This patch enables the indexed write feature of the GMBUS to concatenate 2 consecutive messages into one. The criteria for an indexed write is that both messages are writes, the first is length == 1, and the second is length > 0. The first message is sent out by the GMBUS as the slave command, and the second one is sent via the GMBUS FIFO as usual. Changes in v3: - Added to series Changes in v4: - Combine indexed reads and writes (Ville) Changes in v5: - checkpatch whitespace nits Changes in v6: - None Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180108195545.218615-7-seanpaul@chromium.org
-
Sean Paul authored
This patch adds the framework required to add HDCP support to intel connectors. It implements Aksv loading from fuse, and parts 1/2/3 of the HDCP authentication scheme. Note that without shim implementations, this does not actually implement HDCP. That will come in subsequent patches. Changes in v2: - Don't open code wait_fors (Chris) - drm_hdcp.c under MIT license (Daniel) - Move intel_hdcp_disable() call above ddi_disable (Ram) - Fix // comments (I wore a cone of shame for 12 hours to atone) (Daniel) - Justify intel_hdcp_shim with comments (Daniel) - Fixed async locking issues by adding hdcp_mutex (Daniel) - Don't alter connector_state in enable/disable (Daniel) Changes in v3: - Added hdcp_mutex/hdcp_value to make async reasonable - Added hdcp_prop_work to separate link checking & property setting - Added new helper for atomic_check state tracking (Daniel) - Moved enable/disable into atomic_commit with matching helpers - Moved intel_hdcp_check_link out of all locks when called from dp - Bumped up ksv_fifo timeout (noticed failure on one of my dongles) Changes in v4: - Remove SKL_ prefix from most register names (Daniel) - Move enable/disable back to modeset path (Daniel) - s/get_random_long/get_random_u32/ (Daniel) - Remove mode_config.mutex lock in prop_work (Daniel) - Add intel_hdcp_init to handle init of conn components (Daniel) - Actually check return value of attach_property - Check Bksv is valid before trying to authenticate (Ram) Changes in v5: - checkpatch whitespace changes - s/DRM_MODE_CONTENT_PROTECTION_OFF/DRM_MODE_CONTENT_PROTECTION_UNDESIRED/ - Fix ksv list wait timeout (actually wait 5s) - Increase the R0 timeout to 300ms (Ram) Changes in v6: - SPDX license Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ramalingam C <ramalingm.c@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180108195545.218615-6-seanpaul@chromium.org
-
Sean Paul authored
In preparation for implementing HDCP in i915, add some HDCP related register offsets and defines. The dpcd register offsets will go in drm_dp_helper.h whereas the ddc offsets along with generic HDCP stuff will get stuffed in drm_hdcp.h, which is new. Changes in v2: - drm_hdcp.h gets MIT license (Daniel) Changes in v3: - None Changes in v4: - None Changes in v5: - None Changes in v6: - SPDX license Cc: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Ramalingam C <ramalingm.c@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180108195545.218615-5-seanpaul@chromium.org
-
Sean Paul authored
This patch adds a new optional connector property to allow userspace to enable protection over the content it is displaying. This will typically be implemented by the driver using HDCP. The property is a tri-state with the following values: - OFF: Self explanatory, no content protection - DESIRED: Userspace requests that the driver enable protection - ENABLED: Once the driver has authenticated the link, it sets this value The driver is responsible for downgrading ENABLED to DESIRED if the link becomes unprotected. The driver should also maintain the desiredness of protection across hotplug/dpms/suspend. If this looks familiar, I posted [1] this 3 years ago. We have been using this in ChromeOS across exynos, mediatek, and rockchip over that time. Changes in v2: - Pimp kerneldoc for content_protection_property (Daniel) - Drop sysfs attribute Changes in v3: - None Changes in v4: - Changed kerneldoc to recommend userspace polling (Daniel) - Changed kerneldoc to briefly describe how to attach the property (Daniel) Changes in v5: - checkpatch whitespace noise - Change DRM_MODE_CONTENT_PROTECTION_OFF to DRM_MODE_CONTENT_PROTECTION_UNDESIRED Changes in v6: - None Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org> [1] https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.html Link: https://patchwork.freedesktop.org/patch/msgid/20180108195545.218615-4-seanpaul@chromium.org
-
Sean Paul authored
This patch adds a little more control to a couple wait_for routines such that we can avoid open-coding read/wait/timeout patterns which: - need the value of the register after the wait_for - run arbitrary operation for the read portion This patch also chooses the correct sleep function (based on timers-howto.txt) for the polling interval the caller specifies. Changes in v2: - Added to the series Changes in v3: - Rebased on drm-intel-next-queued and the new Wmin/max _wait_for - Removed msleep option Changes in v4: - Removed ; for OP in _wait_for (Chris) - Moved reg_value definition above ret (Chris) Changes in v4: - checkpatch whitespace fix Changes in v5: - None Changes in v6: - None Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180108195545.218615-3-seanpaul@chromium.org
-
Sean Paul authored
I'm adding some stuff below it and it's killing my editor's vibe. Changes in v2: - Added to the series Changes in v3: - None Changes in v4: - None Changes in v5: - None Changes in v6: - None Cc: Manasi Navare <manasi.d.navare@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180108195545.218615-2-seanpaul@chromium.org
-
- 05 Jan, 2018 1 commit
-
-
git://git.pengutronix.de/git/pza/linuxDave Airlie authored
drm/imx: format modifier support - Add tiled prefetch support to PRE - Add format modifier support to PRG and imx-drm-core - Use runtime PM to control PRG clock - Allow building ipu-v3 under COMPILE_TEST * tag 'imx-drm-next-2018-01-02' of git://git.pengutronix.de/git/pza/linux: gpu: ipu-v3: allow to build with COMPILE_TEST drm/imx: advertise supported plane format modifiers drm/imx: add FB modifier support gpu: ipu-v3: prg: add modifier support gpu: ipu-v3: pre: add tiled prefetch support gpu: ipu-v3: prg: switch to runtime PM
-
- 04 Jan, 2018 4 commits
-
-
git://git.armlinux.org.uk/~rmk/linux-armDave Airlie authored
This series builds upon the set of fixes previously submitted to move Armada DRM closer to atomic modeset. We're nowhere near yet, but this series helps to get us closer by unifying some of the differences between the primary and overlay planes. New features added allows userspace to disable the primary plane if overlay is full screen and there's nothing obscuring the colorkey - this saves having to fetch an entire buffer containing nothing but colorkey when displaying full screen video. [airlied: fixup for atomic plane helper rename: a01cb8ba Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Nov 1 22:16:19 2017 +0200 drm: Move drm_plane_helper_check_state() into drm_atomic_helper.c ] * 'drm-armada-devel-4.15' of git://git.armlinux.org.uk/~rmk/linux-arm: (29 commits) drm/armada: expand overlay trace entry drm/armada: implement primary plane update drm/armada: extract register generation from armada_drm_primary_set() drm/armada: wait for previous work when moving overlay window drm/armada: move overlay plane register update generation drm/armada: re-organise overlay register update generation drm/armada: disable planes at next blanking period drm/armada: avoid work allocation drm/armada: allow armada_drm_plane_work_queue() to silently fail drm/armada: use drm_plane_helper_check_state() drm/armada: only enable HSMOOTH if scaling horizontally drm/armada: move writes of LCD_SPU_SRAM_PARA1 under lock drm/armada: move regs into armada_plane_work drm/armada: move event sending into armada_plane_work drm/armada: move fb retirement into armada_plane_work drm/armada: move overlay plane work out from under spinlock drm/armada: clear plane enable bit when disabling drm/armada: clean up armada_drm_crtc_plane_disable() drm/armada: allow the primary plane to be disabled drm/armada: wait and cancel any pending frame work at disable ...
-
https://git.pengutronix.de/git/lst/linuxDave Airlie authored
Highlights this time: 1. Fix for a nasty Kconfig dependency chain issue from Philipp. 2. Occlusion query buffer address added to the cmdstream validator by Christian. 3. Fixes and cleanups to the job handling from me. This allows us to turn on the GPU performance profiling added in the last cycle. It is also prep work for hooking in the DRM GPU scheduler, which I hope to land for the next cycle. * 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux: (32 commits) drm/etnaviv: use memset32 to init pagetable drm/etnaviv: move submit free out of critical section drm/etnaviv: re-enable perfmon support drm/etnaviv: couple runtime PM management to submit object lifetime drm/etnaviv: move GPU active handling to bo pin/unpin drm/etnaviv: move cmdbuf into submit object drm/etnaviv: use submit exec_state for perfmon sampling drm/etnaviv: move exec_state to submit object drm/etnaviv: move PMRs to submit object drm/etnaviv: refcount the submit object drm/etnaviv: move ww_acquire_ctx out of submit object drm/etnaviv: move object unpinning to submit cleanup drm/etnaviv: attach in fence to submit and move fence wait to fence_sync drm/etnaviv: rename submit fence to out_fence drm/etnaviv: move object fence attachment to gem_submit path drm/etnaviv: simplify submit_create drm/etnaviv: add lockdep annotations to buffer manipulation functions drm/etnaviv: hold GPU lock while inserting END command drm/etnaviv: move workqueue to be per GPU drm/etnaviv: remove switch_context member from etnaviv_gpu ...
-
Dave Airlie authored
Merge tag 'exynos-drm-next-for-v4.16' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next Remove lagacy IPP driver - This driver isn't used anymore so remove it. Marek is preparing new one which includes completely rewritten API so this driver will be replaced with the new version[1] later. And cleanups. [1] https://patches.linaro.org/cover/118386/ * tag 'exynos-drm-next-for-v4.16' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos: drm/exynos: ipp: Remove Exynos DRM IPP subsystem drm/exynos/decon: Add include guard to the Exynos7 header drm/exynos/decon: Move headers from global to local place drm/exynos: decon5433: Remove unnecessary platform_get_resource() error check
-
git://people.freedesktop.org/~gabbayo/linuxDave Airlie authored
- Add CWSR (compute wave save restore) support for GFX8 (Carrizo) - Fix SDMA user-mode queues support for GFX7 (Kaveri) - Add SDMA user-mode queues support for GFX8 (Carrizo) - Allow HWS (hardware scheduling) to schedule multiple processes concurrently - Add debugfs support - Simplify process locking and lock dependencies - Refactoring topology code to prepare for dGPU support + fixes to that code - Add option to generate dummy/virtual CRAT table when its missing or deformed - Recognize CPUs other then APUs as compute entities - Various clean ups and bug fixes I have not yet sent the dGPU topology code because it depends on a patch for the PCI subsystem that adds PCIe atomics support. Once that patch is upstreamed we can continue with the rest of the dGPU code. * tag 'drm-amdkfd-next-2017-12-24' of git://people.freedesktop.org/~gabbayo/linux: (53 commits) drm/amdgpu: Add support for reporting VRAM usage drm/amdkfd: Ignore ACPI CRAT for non-APU systems drm/amdkfd: Module option to disable CRAT table drm/amdkfd: Add AQL Queue Memory flag on topology drm/amdkfd: Fixup incorrect info in the CZ CRAT table drm/amdkfd: Add perf counters to topology drm/amdkfd: Add topology support for dGPUs drm/amdkfd: Add topology support for CPUs drm/amdkfd: Fix sibling_map[] size drm/amdkfd: Simplify counting of memory banks drm/amdkfd: Turn verbose topology messages into pr_debug drm/amdkfd: sync IOLINK defines to thunk spec drm/amdkfd: Support enumerating non-GPU devices drm/amdkfd: Decouple CRAT parsing from device list update drm/amdkfd: Reorganize CRAT fetching from ACPI drm/amdkfd: Group up CRAT related functions drm/amdkfd: Fix memory leaks in kfd topology drm/amdkfd: Topology: Fix location_id drm/amdkfd: Update number of compute unit from KGD drm/amd: Remove get_vmem_size from KGD-KFD interface ...
-
- 02 Jan, 2018 19 commits
-
-
Lucas Stach authored
Now that memset32 is available, the open-coded pagetable initialization loop can be replaced. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
-
Lucas Stach authored
There is no need to hold the GPU lock while freeing the submit object. Only move the retired submits from the GPU active list to a temporary retire list under the GPU lock. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
-
Lucas Stach authored
Now that the PMR lifetime issues are solved we can safely re-enable performance counter profiling support. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
-
Lucas Stach authored
As long as there is an active submit, we want the GPU to stay awake. This is slightly complicated by the fact that we really want to wake the GPU at the last possible moment to achieve maximum power savings. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
-
Lucas Stach authored
The active count is used to check if the BO is idle, where idle is defined as not active on the GPU and all VM mappings and reference counts dropped to the initial state. As the idling of the mappings and references now only happens in the submit cleanup, the active state handling must be moved to the same location in order to keep the userspace semantics. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
-
Lucas Stach authored
Less dynamic allocations and slims down the cmdbuf object to only the required information, as everything else is already available in the submit object. This also simplifies buffer and mappings lifetime management, as they are now exlusively attached to the submit object and not additionally to the cmdbuf. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
-
Lucas Stach authored
The GPU exec state may have changed at the time when the perfmon sampling is done, as it reflects the state of the last submission, not the current GPU execution state. So for proper sampling we must use the submit exec_state. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
-
Lucas Stach authored
We'll need this in some places where only the submit is available. Also this is a first step at slimming down the cmdbuf object. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
-
Lucas Stach authored
To make them available to the event worker even after the actual command stream execution has finished. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
-
Lucas Stach authored
The submit object lifetime will get extended to the actual GPU execution. As multiple users will depend on this, add a kref to properly control destruction of the object. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
-
Lucas Stach authored
The acquire_ctx is special in that it needs to be released from the same thread as has been used to initialize it. This collides with the intention to extend the submit lifetime beyond the gem_submit function with potentially other threads doing the final cleanup. Move the ww_acquire_ctx to the function local stack as suggested in the documentation. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
-
Lucas Stach authored
This is safe to call in all paths, as the BO_PINNED flag tells us if the BO needs unpinning. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
-
Lucas Stach authored
Simplifies the cleanup path and moves fence waiting to a central location. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
-
Lucas Stach authored
This is the fence passed out on a sucessful GPU submit. Make the name more clear. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
-
Lucas Stach authored
The object fencing has nothing to do with the actual GPU buffer submit, so move it to the gem submit path to have a cleaner split. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
-
Lucas Stach authored
Use kzalloc so other code doesn't need to worry about uninitialized members. Drop the non-standard GFP flags, as we really don't want to fail the submit when under slight memory pressure. Remove one level of indentation by using an early return if the allocation failed. Also remove the unused drm device member. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
-
Lucas Stach authored
When manipulating the kernel command buffer the GPU mutex must be held, as otherwise different callers might try to replace the same part of the buffer, wreacking havok in the GPU execution. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
-
Lucas Stach authored
Inserting the END command when suspending the GPU is changing the command buffer state, which requires the GPU to be held. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
-
Lucas Stach authored
While the etnaviv workqueue needs to be ordered, as we rely on work items being executed in queuing order, this is only true for a single GPU. Having a shared workqueue for all GPUs in the system limits concurrency artificially. Getting each GPU its own ordered workqueue still meets our ordering expectations and enables retire workers to run concurrently. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
-