- 08 Jan, 2018 5 commits
-
-
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 29 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>
-
Lucas Stach authored
There is no need to store this in the gpu struct. MMU flushes are triggered correctly in reaction to MMU maps and unmaps, independent of the current ctx. Any required pipe switches can be infered from the current and the desired GPU exec state. 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
There is no need to synchronize with oustanding retire jobs if the object has gone idle. Retire jobs only ever change the object state from active to idle, not the other way around. The IOVA put race is uncritical, as the GEM_WAIT ioctl itself is holding a reference to the GEM object, so the retire worker will not pull the object into the CPU domain, which is the thing we are trying to guard against with etnaviv_gpu_wait_obj_inactive. The ordering of the various counts and waits may change a bit, but the userspace visible behavior at the bounds of the syscall are unchanged. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
-
Lucas Stach authored
Flush and prefetch are properly handled in the buffer code, data endianess would need much wider changes than adding something to this single function. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
-
Lucas Stach authored
Now that the userptr BO handling doesn't rely on the userspace restarting the submit after object population, there is no need to special case the -EAGAIN return value anymore. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
-
Lucas Stach authored
All code paths which populate userptr BOs are fine with the get_pages function taking the mmap_sem lock. This allows to get rid of the pretty involved architecture with a worker being scheduled if the mmap_sem needs to be taken, but instead call GUP directly and allow it to take the lock if necessary. This simplifies the code a lot and removes the possibility of this function returning -EAGAIN, which complicates object population handling at the callers. A notable change in behavior is that we don't allow a process to populate objects with user pages from a foreign MM anymore. This would have been an invalid use before, as it breaks the assumptions made in the etnaviv kernel driver to enfore cache coherence. We now disallow this by rejecting the request to populate those objects. Well behaving userspace is unaffected by this change. Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
-
Lucas Stach authored
This function never fails, as it does nothing more than adding the GEM object to the global device list. Making this explicit through the void return type allows to drop some unnecessary error handling. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
-
Lucas Stach authored
This function has only one caller and it isn't expected that there will be any more in the future. Folding this function into the caller is helping the readability. 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
The current userptr page population will defer work to a work item if needed to avoid ever taking the mmap_sem in the direct call path. With the more fine-grained locking in etnaviv this isn't needed anymore, so a future commit will simplify this code. Add a lockdep annotation to validate the assumption that the mmap_sem can be taken in the direct call path. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
-
Lucas Stach authored
Userptr, prime and shmem buffer objects have different lock ordering requirements. This is mostly due to the fact that we don't allow to mmap userptr buffers, so we won't ever end up in our fault handler for those, so some of the code paths are never called with the mmap_sem held. To avoid lockdep false positives, split them up into different lock classes. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
-
Lucas Stach authored
If the FE is restarted before the sync point event is cleared, the GPU might trigger a completion IRQ for the next sync point, corrupting the state of the currently running worker. 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>
-
- 01 Jan, 2018 1 commit
-
-
Marek Szyprowski authored
Exynos DRM IPP subsystem is in fact non-functional and frankly speaking dead-code. This patch clearly marks that Exynos DRM IPP subsystem is broken and never really functional. It will be replaced by a completely rewritten API. Exynos DRM IPP user-space API can be obsoleted for the following reasons: 1. Exynos DRM IPP user-space API can be optional in Exynos DRM, so userspace should not rely that it is always available and should have a software fallback in case it is not there. 2. The only mode which was initially semi-working was memory-to-memory image processing. The remaining modes (LCD-"writeback" and "output") were never operational due to missing code (both in mainline and even vendor kernels). 3. Exynos DRM IPP mainline user-space API compatibility for memory-to-memory got broken very early by commit 083500ba ("drm: remove DRM_FORMAT_NV12MT", which removed the support for tiled formats, the main feature which made this API somehow useful on Exynos platforms (video codec that time produced only tiled frames, to implement xvideo or any other video overlay, one has to de-tile them for proper display). 4. Broken drivers. Especially once support for IOMMU has been added, it revealed that drivers don't configure DMA operations properly and in many cases operate outside the provided buffers trashing memory around. 5. Need for external patches. Although IPP user-space API has been used in some vendor kernels, but in such cases there were additional patches applied (like reverting mentioned 083500ba patch) what means that those userspace apps which might use it, still won't work with the mainline kernel version. We don't have time machines, so we cannot change it, but Exynos DRM IPP extension should never have been merged to mainline in that form. Exynos IPP subsystem and user-space API will be rewritten, so remove current IPP core code and mark existing drivers as BROKEN. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Daniel Stone <daniels@collabora.com> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Inki Dae <inki.dae@samsung.com>
-