summaryrefslogtreecommitdiffstats
path: root/include/uapi/drm
AgeCommit message (Collapse)AuthorFilesLines
2019-10-02drm/amdgpu: return tcc_disabled_mask to userspaceMarek Olšák1-0/+2
UMDs need this for correct programming of harvested chips. Signed-off-by: Marek Olšák <marek.olsak@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-08-22Merge branch 'etnaviv/next' of https://git.pengutronix.de/git/lst/linux into ↵Dave Airlie1-1/+9
drm-next Most importantly per-process address spaces on GPUs that are capable of providing proper isolation has finished baking. This is the base for our softpin implementation, which allows us to support the texture descriptor buffers used by GC7000 series GPUs without a major UAPI extension/rework. Shortlog of notable changes: - code cleanup from Fabio - fix performance counters on GC880 and GC2000 GPUs from Christian - drmP.h header removal from Sam - per process address space support on MMUv2 GPUs from me - softpin support from me Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/1565946875.2641.73.camel@pengutronix.de
2019-08-21Merge tag 'drm-misc-next-2019-08-19' of ↵Dave Airlie1-0/+25
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.4: UAPI Changes: Cross-subsystem Changes: Core Changes: - dma-buf: add reservation_object_fences helper, relax reservation_object_add_shared_fence, remove reservation_object seq number (and then restored) - dma-fence: Shrinkage of the dma_fence structure, Merge dma_fence_signal and dma_fence_signal_locked, Store the timestamp in struct dma_fence in a union with cb_list Driver Changes: - More dt-bindings YAML conversions - More removal of drmP.h includes - dw-hdmi: Support get_eld and various i2s improvements - gm12u320: Few fixes - meson: Global cleanup - panfrost: Few refactors, Support for GPU heap allocations - sun4i: Support for DDC enable GPIO - New panels: TI nspire, NEC NL8048HL11, LG Philips LB035Q02, Sharp LS037V7DW01, Sony ACX565AKM, Toppoly TD028TTEC1 Toppoly TD043MTEA1 Signed-off-by: Dave Airlie <airlied@redhat.com> [airlied: fixup dma_resv rename fallout] From: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190819141923.7l2adietcr2pioct@flea
2019-08-15drm/etnaviv: implement softpinLucas Stach1-1/+9
With softpin we allow the userspace to take control over the GPU virtual address space. The new capability is relected by a bump of the minor DRM version. There are a few restrictions for userspace to take into account: 1. The kernel reserves a bit of the address space to implement zero page faulting and mapping of the kernel internal ring buffer. Userspace can query the kernel for the first usable GPU VM address via ETNAVIV_PARAM_SOFTPIN_START_ADDR. 2. We only allow softpin on GPUs, which implement proper process separation via PPAS. If softpin is not available the softpin start address will be set to ~0. 3. Softpin is all or nothing. A submit using softpin must not use any address fixups via relocs. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Guido Günther <agx@sigxcpu.org>
2019-08-12drm/panfrost: Add support for GPU heap allocationsRob Herring1-0/+1
The midgard/bifrost GPUs need to allocate GPU heap memory which is allocated on GPU page faults and not pinned in memory. The vendor driver calls this functionality GROW_ON_GPF. This implementation assumes that BOs allocated with the PANFROST_BO_NOEXEC flag are never mmapped or exported. Both of those may actually work, but I'm unsure if there's some interaction there. It would cause the whole object to be pinned in memory which would defeat the point of this. On faults, we map in 2MB at a time in order to utilize huge pages (if enabled). Currently, once we've mapped pages in, they are only unmapped if the BO is freed. Once we add shrinker support, we can unmap pages with the shrinker. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Robin Murphy <robin.murphy@arm.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190808222200.13176-9-robh@kernel.org
2019-08-12drm/panfrost: Add a no execute flag for BO allocationsRob Herring1-0/+2
Executable buffers have an alignment restriction that they can't cross 16MB boundary as the GPU program counter is 24-bits. This restriction is currently not handled and we just get lucky. As current userspace assumes all BOs are executable, that has to remain the default. So add a new PANFROST_BO_NOEXEC flag to allow userspace to indicate which BOs are not executable. There is also a restriction that executable buffers cannot start or end on a 4GB boundary. This is mostly avoided as there is only 4GB of space currently and the beginning is already blocked out for NULL ptr detection. Add support to handle this restriction fully regardless of the current constraints. For existing userspace, all created BOs remain executable, but the GPU VA alignment will be increased to the size of the BO. This shouldn't matter as there is plenty of GPU VA space. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190808222200.13176-6-robh@kernel.org
2019-08-12Merge tag 'drm-next-5.4-2019-08-09' of ↵Dave Airlie1-0/+4
git://people.freedesktop.org/~agd5f/linux into drm-next drm-next-5.4-2019-08-09: Same as drm-next-5.4-2019-08-06, but with the readq/writeq stuff fixed and 5.3-rc3 backmerged. amdgpu: - Add navi14 support - Add navi12 support - Add Arcturus support - Enable mclk DPM for Navi - Misc DC display fixes - Add perfmon support for DF - Add scatter/gather display support for Raven - Improve SMU handling for GPU reset - RAS support for GFX - Drop last of drmP.h - Add support for wiping memory on buffer release - Allow cursor async updates for fb swaps - Misc fixes and cleanups amdkfd: - Add navi14 support - Add navi12 support - Add Arcturus support - CWSR trap handlers updates for gfx9, 10 - Drop last of drmP.h - Update MAINTAINERS radeon: - Misc fixes and cleanups - Make kexec more reliable by tearing down the GPU ttm: - Add release_notify callback uapi: - Add wipe memory on release flag for buffer creation Signed-off-by: Dave Airlie <airlied@redhat.com> [airlied: resolved conflicts with ttm resv moving] From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190809184807.3381-1-alexander.deucher@amd.com
2019-08-09Merge tag 'v5.3-rc3' into drm-next-5.4Alex Deucher1-3/+1
Linux 5.3-rc3 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-08-09Merge tag 'drm-misc-next-2019-08-08' of ↵Dave Airlie2-0/+40
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.4: UAPI Changes: - HDCP: Add a Content protection type property Cross-subsystem Changes: Core Changes: - Continue to rework the include dependencies - fb: Remove the unused drm_gem_fbdev_fb_create function - drm-dp-helper: Make the link rate calculation more tolerant to non-explicitly defined, yet supported, rates - fb-helper: Map DRM client buffer only when required, and instanciate a shadow buffer when the device has a dirty function or says so - connector: Add a helper to link the DDC adapter used by that connector to the userspace - vblank: Switch from DRM_WAIT_ON to wait_event_interruptible_timeout - dma-buf: Fix a stack corruption - ttm: Embed a drm_gem_object struct to make ttm_buffer_object a superclass of GEM, and convert drivers to use it. - hdcp: Improvements to report the content protection type to the userspace Driver Changes: - Remove drm_gem_prime_import/export from being defined in the drivers - Drop DRM_AUTH usage from drivers - Continue to drop drmP.h - Convert drivers to the connector ddc helper - ingenic: Add support for more panel-related cases - komeda: Support for dual-link - lima: Reduce logging - mpag200: Fix the cursor support - panfrost: Export GPU features register to userspace through an ioctl - pl111: Remove the CLD pads wiring support from the DT - rockchip: Rework to use DRM PSR helpers, fix a bug in the VOP_WIN_GET macro - sun4i: Improve support for color encoding and range - tinydrm: Rework SPI support, improve MIPI-DBI support, move to drm/tiny - vkms: Rework of the CRC tracking - bridges: - sii902x: Add support for audio graph card - tc358767: Rework AUX data handling code - ti-sn65dsi86: Add Debugfs and proper DSI mode flags support - panels - Support for GiantPlus GPM940B0, Sharp LQ070Y3DG3B, Ortustech COM37H3M, Novatek NT39016, Sharp LS020B1DD01D, Raydium RM67191, Boe Himax8279d, Sharp LD-D5116Z01B - Conversion of the device tree bindings to the YAML description - jh057n00900: Rework the enable / disable path - fbdev: - ssd1307fb: Support more devices based on that controller Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190808121423.xzpedzkpyecvsiy4@flea
2019-08-08drm/panfrost: Add madvise and shrinker supportRob Herring1-0/+22
Add support for madvise and a shrinker similar to other drivers. This allows userspace to mark BOs which can be freed when there is memory pressure. Unlike other implementations, we don't depend on struct_mutex. The driver maintains a list of BOs which can be freed when the shrinker is called. Access to the list is serialized with the shrinker_lock. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190805143358.21245-2-robh@kernel.org
2019-08-02drm/amdgpu: Add flag to wipe VRAM on releaseFelix Kuehling1-0/+4
This memory allocation flag will be used to indicate BOs containing sensitive data that should not be leaked to other processes. Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-07-29Merge drm/drm-next into drm-intel-next-queuedRodrigo Vivi2-4/+7
Catching up with 5.3-rc* Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-07-25drm/panfrost: Export all GPU feature registersSteven Price1-0/+39
Midgard/Bifrost GPUs have a bunch of feature registers providing details of what the hardware supports. Panfrost already reads these, this patch exports them all to user space so that the jobs created by the user space driver can be tuned for the particular hardware implementation. Signed-off-by: Steven Price <steven.price@arm.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190724105626.53552-1-steven.price@arm.com
2019-07-23drm: Add SPI connector typeNoralf Trønnes1-0/+1
tinydrm drivers announce DRM_MODE_CONNECTOR_VIRTUAL for its SPI drivers. Add a SPI connector type to match the actual connector. X will list the connector as Unknown: X.Org X Server 1.19.2 Release Date: 2017-03-02 <...> [ 53523.905] (II) modeset(0): Output Unknown19-1 has no monitor section [ 53523.908] (II) modeset(0): EDID for output Unknown19-1 [ 53523.910] (II) modeset(0): Printing probed modes for output Unknown19-1 [ 53523.911] (II) modeset(0): Modeline "320x240"x0.0 0.00 320 320 320 320 240 240 240 240 (0.0 kHz eP) [ 53523.911] (II) modeset(0): Output Unknown19-1 connected [ 53523.912] (II) modeset(0): Using exact sizes for initial modes [ 53523.912] (II) modeset(0): Output Unknown19-1 using initial mode 320x240 +0+0 The weston source shows that it will be listed as UNNAMED. v2: Split patch in core and driver changes, expand commit message (Daniel) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: David Lechner <david@lechnology.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190719155916.62465-2-noralf@tronnes.org
2019-07-19Merge tag 'drm-next-5.3-2019-07-18' of ↵Dave Airlie1-1/+6
git://people.freedesktop.org/~agd5f/linux into drm-next drm-next-5.3-2019-07-18: amdgpu: - Navi DC fix for secondary adapters - Fix Navi flickering with high res panels - Navi SMU fixes - Vega20 SMU fixes - Fixes for audio hotplug on HG systems - Fix for potential integer overflows on large buffer migrations - debugfs fixes for umr - Various other small fixes amdkfd: - Apply noretry setting consistently - Fix hang in eviction - Properly clean up GWS on uninit UAPI: - clarify a comment on ctx priority Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190718211525.3374-1-alexander.deucher@amd.com
2019-07-16drm/amdgpu: extend AMDGPU_CTX_PRIORITY_NORMAL commentEmil Velikov1-1/+6
Currently the AMDGPU_CTX_PRIORITY_* defines are used in both drm_amdgpu_ctx_in::priority and drm_amdgpu_sched_in::priority. Extend the comment to mention the CAP_SYS_NICE or DRM_MASTER requirement is only applicable with the former. Cc: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-07-16Revert "Merge branch 'vmwgfx-next' of ↵Dave Airlie1-3/+1
git://people.freedesktop.org/~thomash/linux into drm-next" This reverts commit 031e610a6a21448a63dff7a0416e5e206724caac, reversing changes made to 52d2d44eee8091e740d0d275df1311fb8373c9a9. The mm changes in there we premature and not fully ack or reviewed by core mm folks, I dropped the ball by merging them via this tree, so lets take em all back out. Signed-off-by: Dave Airlie <airlied@redhat.com>
2019-07-10Merge drm/drm-next into drm-intel-next-queuedRodrigo Vivi4-2/+126
Catch-up with 5.2. Specially to remove a drm-tip merge fixup around intel_workarounds. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-07-04drm/i915: Show support for accurate sw PMU busyness trackingChris Wilson1-0/+1
Expose whether or not we support the PMU software tracking in our scheduler capabilities, so userspace can query at runtime. v2: Use I915_SCHEDULER_CAP_ENGINE_BUSY_STATS for a less ambiguous capability name. 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/20190703143702.11339-1-chris@chris-wilson.co.uk
2019-06-25Merge branch 'drm-next' into drm-next-5.3Alex Deucher2-1/+27
Backmerge drm-next and fix up conflicts due to drmP.h removal. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-21drm/amdgpu: add pa_sc_tile_steering_override to drm_amdgpu_info_deviceHawking Zhang1-0/+2
the initial/default value of pa_sc_tile_steering_override need to be exposed to user mode driver Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-21Merge tag 'drm-misc-next-2019-06-20' of ↵Dave Airlie1-0/+24
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v5.3: UAPI Changes: - Give each dma-buf their own inode, add DMA_BUF_SET_NAME ioctl and a show_fdinfo handler. Cross-subsystem Changes: - Pull in the topic/remove-fbcon-notifiers branch: * remove fbdev notifier usage for fbcon, as prep work to clean up the fbcon locking * assorted locking checks in vt/console code * assorted notifier and cleanups in fbdev and backlight code Core Changes: - Make drm_debugfs_create_files() never fail. - add debug print to update_vblank_count. - Add DP_DPCD_QUIRK_NO_SINK_COUNT quirk. - Add todo item for drm_gem_objects. - Unexport drm_gem_(un)pin/v(un)map. - Document struct drm_cmdline_mode. - Rewrite the command handler for mode names, and add support to specify rotation, reflection and overscan. With a new selftest! :) - Fixes to drm/client for improving rotation support, and fixing variable scope. - Small fixes to self refresh helper. Driver Changes: - Add rockchip RK3328 support. - Assorted driver fixes to rockchip, vc4, rcar-du, vkms. - Expose panfrost performance counters through unstable ioctl's, hidden behind a module parameter. - Enumerate CRC sources list in vkms. - Add a basic kms driver for the Ingenic JZ47xx SoC, which will be expanded soon with more advanced features. - Suspend/resume fix for stm. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/18e22ec1-adf3-3a75-34a3-9fe09a91eef5@linux.intel.com
2019-06-20drm/amdgpu: add GDDR6 vram typeHuang Rui1-0/+1
New vram type. Signed-off-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-20drm/amdgpu: add NV series gpu family idHuang Rui1-0/+1
Signed-off-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-06-18drm/panfrost: Expose performance counters through unstable ioctlsBoris Brezillon1-0/+24
Expose performance counters through 2 driver specific ioctls: one to enable/disable the perfcnt block, and one to dump the counter values. There are discussions to expose global performance monitors (those counters that can't be retrieved on a per-job basis) in a consistent way, but this is likely to take time to settle on something that works for various HW/users. The ioctls are marked unstable so we can get rid of them when the time comes. We initally went for a debugfs-based interface, but this was making the transition to per-FD address space more complicated (we need to specify the namespace the GPU has to use when dumping the perf counters), hence the decision to switch back to driver specific ioctls which are passed the FD they operate on and thus will have a dedicated address space attached to them. Other than that, the implementation is pretty simple: it basically dumps all counters and copy the values to a userspace buffer. The parsing is left to userspace which has to know the specific layout that's used by the GPU (layout differs on a per-revision basis). Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190618081648.17297-5-boris.brezillon@collabora.com
2019-06-18drm/vmwgfx: Add surface dirty-tracking callbacksThomas Hellstrom1-1/+3
Add the callbacks necessary to implement emulated coherent memory for surfaces. Add a flag to the gb_surface_create ioctl to indicate that surface memory should be coherent. Also bump the drm minor version to signal the availability of coherent surfaces. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Deepak Rawat <drawat@vmware.com>
2019-06-04drm: Fix docbook warnings in hdr metadata helper structuresUma Shankar1-1/+73
Fixes the following warnings: ./include/drm/drm_mode_config.h:841: warning: Incorrect use of kernel-doc format: * hdr_output_metadata_property: Connector property containing hdr ./include/drm/drm_mode_config.h:918: warning: Function parameter or member 'hdr_output_metadata_property' not described in 'drm_mode_config' ./include/drm/drm_connector.h:1251: warning: Function parameter or member 'hdr_output_metadata' not described in 'drm_connector' ./include/drm/drm_connector.h:1251: warning: Function parameter or member 'hdr_sink_metadata' not described in 'drm_connector' Also adds some property documentation for HDR Metadata Connector Property in connector property create function. v2: Fixed Sean Paul's review comments. v3: Fixed Daniel Vetter's review comments, added the UAPI structure definition section in kernel docs. v4: Fixed Daniel Vetter's review comments. v5: Added structure member references as per Daniel's suggestion. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Ville Syrjä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: "Ville Syrjä" <ville.syrjala@linux.intel.com> Cc: Hans Verkuil <hansverk@cisco.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-fbdev@vger.kernel.org Reviewed-by: Sean Paul <sean@poorly.run> (v1) Signed-off-by: Uma Shankar <uma.shankar@intel.com> [danvet: Fix up markup: () for functions, & for structs. Style guide also recommends to prepend struct for structures.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1559647022-7336-1-git-send-email-uma.shankar@intel.com
2019-06-03drm: Fixed doc warnings in drm uapi headerUma Shankar1-0/+22
Fixed doc warnings in drm uapi header. All the UAPI structures are now documented in kernel doc. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/1559159944-21103-4-git-send-email-uma.shankar@intel.com
2019-05-28Merge tag 'drm-intel-next-2019-05-24' of ↵Dave Airlie1-3/+206
git://anongit.freedesktop.org/drm/drm-intel into drm-next Features: - Engine discovery query (Tvrtko) - Support for DP YCbCr4:2:0 outputs (Gwan-gyeong) - HDCP revocation support, refactoring (Ramalingam) - Remove DRM_AUTH from IOCTLs which also have DRM_RENDER_ALLOW (Christian König) - Asynchronous display power disabling (Imre) - Perma-pin uC firmware and re-enable global reset (Fernando) - GTT remapping for display, for bigger fb size and stride (Ville) - Enable pipe HDR mode on ICL if only HDR planes are used (Ville) - Kconfig to tweak the busyspin durations for i915_wait_request (Chris) - Allow multiple user handles to the same VM (Chris) - GT/GEM runtime pm improvements using wakerefs (Chris) - Gen 4&5 render context support (Chris) - Allow userspace to clone contexts on creation (Chris) - SINGLE_TIMELINE flags for context creation (Chris) - Allow specification of parallel execbuf (Chris) Refactoring: - Header refactoring (Jani) - Move GraphicsTechnology files under gt/ (Chris) - Sideband code refactoring (Chris) Fixes: - ICL DSI state readout and checker fixes (Vandita) - GLK DSI picture corruption fix (Stanislav) - HDMI deep color fixes (Clinton, Aditya) - Fix driver unbinding from a device in use (Janusz) - Fix clock gating with pipe scaling (Radhakrishna) - Disable broken FBC on GLK (Daniel Drake) - Miscellaneous GuC fixes (Michal) - Fix MG PHY DP register programming (Imre) - Add missing combo PHY lane power setup (Imre) - Workarounds for early ICL VBT issues (Imre) - Fix fastset vs. pfit on/off on HSW EDP transcoder (Ville) - Add readout and state check for pch_pfit.force_thru (Ville) - Miscellaneous display fixes and refactoring (Ville) - Display workaround fixes (Ville) - Enable audio even if ELD is bogus (Ville) - Fix use-after-free in reporting create.size (Chris) - Sideband fixes to avoid BYT hard lockups (Chris) - Workaround fixes and improvements (Chris) Maintainer shortcomings: - Failure to adequately describe and give credit for all changes (Jani) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87sgt3n45z.fsf@intel.com
2019-05-22drm: Add HDR source metadata propertyUma Shankar1-0/+23
This patch adds a blob property to get HDR metadata information from userspace. This will be send as part of AVI Infoframe to panel. It also implements get() and set() functions for HDR output metadata property.The blob data is received from userspace and saved in connector state, the same is returned as blob in get property call to userspace. v2: Rebase and modified the metadata structure elements as per Ville's POC changes. v3: No Change v4: Addressed Shashank's review comments v5: Rebase. v6: Addressed Brian Starkey's review comments, defined new structure with header for dynamic metadata scalability. Merge get/set property functions for metadata in this patch. v7: Addressed Jonas Karlman review comments and defined separate structure for infoframe to better align with CTA 861.G spec. Added Shashank's RB. v8: Addressed Ville's review comments. Moved sink metadata structure out of uapi headers as suggested by Jonas Karlman. v9: Rebase and addressed Jonas Karlman review comments. v10: Addressed Ville's review comments, dropped the metdata_changed state variable as its not needed anymore. Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1558015817-12025-2-git-send-email-uma.shankar@intel.com
2019-05-22drm/i915: Engine discovery queryTvrtko Ursulin1-0/+42
Engine discovery query allows userspace to enumerate engines, probe their configuration features, all without needing to maintain the internal PCI ID based database. A new query for the generic i915 query ioctl is added named DRM_I915_QUERY_ENGINE_INFO, together with accompanying structure drm_i915_query_engine_info. The address of latter should be passed to the kernel in the query.data_ptr field, and should be large enough for the kernel to fill out all known engines as struct drm_i915_engine_info elements trailing the query. As with other queries, setting the item query length to zero allows userspace to query minimum required buffer size. Enumerated engines have common type mask which can be used to query all hardware engines, versus engines userspace can submit to using the execbuf uAPI. Engines also have capabilities which are per engine class namespace of bits describing features not present on all engine instances. v2: * Fixed HEVC assignment. * Reorder some fields, rename type to flags, increase width. (Lionel) * No need to allocate temporary storage if we do it engine by engine. (Lionel) v3: * Describe engine flags and mark mbz fields. (Lionel) * HEVC only applies to VCS. v4: * Squash SFC flag into main patch. * Tidy some comments. v5: * Add uabi_ prefix to engine capabilities. (Chris Wilson) * Report exact size of engine info array. (Chris Wilson) * Drop the engine flags. (Joonas Lahtinen) * Added some more reserved fields. * Move flags after class/instance. v6: * Do not check engine info array was zeroed by userspace but zero the unused fields for them instead. v7: * Simplify length calculation loop. (Lionel Landwerlin) v8: * Remove MBZ comments where not applicable. * Rename ABI flags to match engine class define naming. * Rename SFC ABI flag to reflect it applies to VCS and VECS. * SFC is wired to even _logical_ engine instances. * SFC applies to VCS and VECS. * HEVC is present on all instances on Gen11. (Tony) * Simplify length calculation even more. (Chris Wilson) * Move info_ptr assigment closer to loop for clarity. (Chris Wilson) * Use vdbox_sfc_access from runtime info. * Rebase for RUNTIME_INFO. * Refactor for lower indentation. * Rename uAPI class/instance to engine_class/instance to avoid C++ keyword. v9: * Rebase for s/num_rings/num_engines/ in RUNTIME_INFO. v10: * Use new copy_query_item. v11: * Consolidate with struct i915_engine_class_instnace. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tony Ye <tony.ye@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> # v7 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190522090054.6007-1-tvrtko.ursulin@linux.intel.com
2019-05-22drm/i915: Allow specification of parallel execbufChris Wilson1-1/+16
There is a desire to split a task onto two engines and have them run at the same time, e.g. scanline interleaving to spread the workload evenly. Through the use of the out-fence from the first execbuf, we can coordinate secondary execbuf to only become ready simultaneously with the first, so that with all things idle the second execbufs are executed in parallel with the first. The key difference here between the new EXEC_FENCE_SUBMIT and the existing EXEC_FENCE_IN is that the in-fence waits for the completion of the first request (so that all of its rendering results are visible to the second execbuf, the more common userspace fence requirement). Since we only have a single input fence slot, userspace cannot mix an in-fence and a submit-fence. It has to use one or the other! This is not such a harsh requirement, since by virtue of the submit-fence, the secondary execbuf inherit all of the dependencies from the first request, and for the application the dependencies should be common between the primary and secondary execbuf. Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Testcase: igt/gem_exec_fence/parallel Link: https://github.com/intel/media-driver/pull/546 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/20190521211134.16117-10-chris@chris-wilson.co.uk
2019-05-22drm/i915/execlists: Virtual engine bondingChris Wilson1-0/+44
Some users require that when a master batch is executed on one particular engine, a companion batch is run simultaneously on a specific slave engine. For this purpose, we introduce virtual engine bonding, allowing maps of master:slaves to be constructed to constrain which physical engines a virtual engine may select given a fence on a master engine. For the moment, we continue to ignore the issue of preemption deferring the master request for later. Ideally, we would like to then also remove the slave and run something else rather than have it stall the pipeline. With load balancing, we should be able to move workload around it, but there is a similar stall on the master pipeline while it may wait for the slave to be executed. At the cost of more latency for the bonded request, it may be interesting to launch both on their engines in lockstep. (Bubbles abound.) Opens: Also what about bonding an engine as its own master? It doesn't break anything internally, so allow the silliness. v2: Emancipate the bonds v3: Couple in delayed scheduling for the selftests v4: Handle invalid mutually exclusive bonding v5: Mention what the uapi does v6: s/nbond/num_bonds/ 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/20190521211134.16117-9-chris@chris-wilson.co.uk
2019-05-22drm/i915: Load balancing across a virtual engineChris Wilson1-0/+39
Having allowed the user to define a set of engines that they will want to only use, we go one step further and allow them to bind those engines into a single virtual instance. Submitting a batch to the virtual engine will then forward it to any one of the set in a manner as best to distribute load. The virtual engine has a single timeline across all engines (it operates as a single queue), so it is not able to concurrently run batches across multiple engines by itself; that is left up to the user to submit multiple concurrent batches to multiple queues. Multiple users will be load balanced across the system. The mechanism used for load balancing in this patch is a late greedy balancer. When a request is ready for execution, it is added to each engine's queue, and when an engine is ready for its next request it claims it from the virtual engine. The first engine to do so, wins, i.e. the request is executed at the earliest opportunity (idle moment) in the system. As not all HW is created equal, the user is still able to skip the virtual engine and execute the batch on a specific engine, all within the same queue. It will then be executed in order on the correct engine, with execution on other virtual engines being moved away due to the load detection. A couple of areas for potential improvement left! - The virtual engine always take priority over equal-priority tasks. Mostly broken up by applying FQ_CODEL rules for prioritising new clients, and hopefully the virtual and real engines are not then congested (i.e. all work is via virtual engines, or all work is to the real engine). - We require the breadcrumb irq around every virtual engine request. For normal engines, we eliminate the need for the slow round trip via interrupt by using the submit fence and queueing in order. For virtual engines, we have to allow any job to transfer to a new ring, and cannot coalesce the submissions, so require the completion fence instead, forcing the persistent use of interrupts. - We only drip feed single requests through each virtual engine and onto the physical engines, even if there was enough work to fill all ELSP, leaving small stalls with an idle CS event at the end of every request. Could we be greedy and fill both slots? Being lazy is virtuous for load distribution on less-than-full workloads though. Other areas of improvement are more general, such as reducing lock contention, reducing dispatch overhead, looking at direct submission rather than bouncing around tasklets etc. sseu: Lift the restriction to allow sseu to be reconfigured on virtual engines composed of RENDER_CLASS (rcs). v2: macroize check_user_mbz() v3: Cancel virtual engines on wedging v4: Commence commenting v5: Replace 64b sibling_mask with a list of class:instance v6: Drop the one-element array in the uabi v7: Assert it is an virtual engine in to_virtual_engine() v8: Skip over holes in [class][inst] so we can selftest with (vcs0, vcs2) Link: https://github.com/intel/media-driver/pull/283 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/20190521211134.16117-6-chris@chris-wilson.co.uk
2019-05-22drm/i915: Allow userspace to clone contexts on creationChris Wilson1-0/+15
A usecase arose out of handling context recovery in mesa, whereby they wish to recreate a context with fresh logical state but preserving all other details of the original. Currently, they create a new context and iterate over which bits they want to copy across, but it would much more convenient if they were able to just pass in a target context to clone during creation. This essentially extends the setparam during creation to pull the details from a target context instead of the user supplied parameters. The ideal here is that we don't expose control over anything more than can be obtained via CONTEXT_PARAM. That is userspace retains explicit control over all features, and this api is just convenience. For example, you could replace struct context_param p = { .param = CONTEXT_PARAM_VM }; param.ctx_id = old_id; gem_context_get_param(&p.param); new_id = gem_context_create(); param.ctx_id = new_id; gem_context_set_param(&p.param); gem_vm_destroy(param.value); /* drop the ref to VM_ID handle */ with struct create_ext_param p = { { .name = CONTEXT_CREATE_CLONE }, .clone_id = old_id, .flags = CLONE_FLAGS_VM } new_id = gem_context_create_ext(&p); and not have to worry about stray namespace pollution etc. 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/20190521211134.16117-5-chris@chris-wilson.co.uk
2019-05-22drm/i915: Re-expose SINGLE_TIMELINE flags for context creationChris Wilson1-1/+2
The SINGLE_TIMELINE flag can be used to create a context such that all engine instances within that context share a common timeline. This can be useful for mixing operations between real and virtual engines, or when using a composite context for a single client API context. 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/20190521211134.16117-4-chris@chris-wilson.co.uk
2019-05-22drm/i915: Extend I915_CONTEXT_PARAM_SSEU to support local ctx->engine[]Chris Wilson1-1/+2
Allow the user to specify a local engine index (as opposed to class:index) that they can use to refer to a preset engine inside the ctx->engine[] array defined by an earlier I915_CONTEXT_PARAM_ENGINES. This will be useful for setting SSEU parameters on virtual engines that are local to the context and do not have a valid global class:instance lookup. Note that due to the ambiguity in using class:instance with ctx->engines[], if a user supplied engine map is active the user must specify the engine to alter by its index into the ctx->engines[]. 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/20190521211134.16117-3-chris@chris-wilson.co.uk
2019-05-22drm/i915: Allow a context to define its set of enginesChris Wilson1-0/+31
Over the last few years, we have debated how to extend the user API to support an increase in the number of engines, that may be sparse and even be heterogeneous within a class (not all video decoders created equal). We settled on using (class, instance) tuples to identify a specific engine, with an API for the user to construct a map of engines to capabilities. Into this picture, we then add a challenge of virtual engines; one user engine that maps behind the scenes to any number of physical engines. To keep it general, we want the user to have full control over that mapping. To that end, we allow the user to constrain a context to define the set of engines that it can access, order fully controlled by the user via (class, instance). With such precise control in context setup, we can continue to use the existing execbuf uABI of specifying a single index; only now it doesn't automagically map onto the engines, it uses the user defined engine map from the context. v2: Fixup freeing of local on success of get_engines() v3: Allow empty engines[] v4: s/nengine/num_engines/ v5: Replace 64 limit on num_engines with a note that execbuf is currently limited to only using the first 64 engines. v6: Actually use the engines_mutex to guard the ctx->engines. Testcase: igt/gem_ctx_engines 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/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22drm/i915: Restore control over ppgtt for context creation ABIChris Wilson1-0/+15
Having hid the partially exposed new ABI from the PR, put it back again for completion of context recovery. A significant part of context recovery is the ability to reuse as much of the old context as is feasible (to avoid expensive reconstruction). The biggest chunk kept hidden at the moment is fine-control over the ctx->ppgtt (the GPU page tables and associated translation tables and kernel maps), so make control over the ctx->ppgtt explicit. This allows userspace to create and share virtual memory address spaces (within the limits of a single fd) between contexts they own, along with the ability to query the contexts for the vm state. 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/20190521211134.16117-1-chris@chris-wilson.co.uk
2019-05-16drm: Fix drm.h uapi header for GNU/kFreeBSDJames Clarke1-0/+1
Like GNU/Linux, GNU/kFreeBSD's sys/types.h does not define the uintX_t types, which differs from the BSDs' headers. Thus we should include stdint.h to ensure we have all the required integer types. Signed-off-by: James Clarke <jrtc27@jrtc27.com> Signed-off-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190115150418.68080-1-jrtc27@jrtc27.com Reviewed-by: Eric Anholt <eric@anholt.net>
2019-05-09Merge remote-tracking branch 'drm/drm-next' into drm-misc-nextMaarten Lankhorst4-2/+36
Requested for backmerging airlied's drm-legacy cleanup. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2019-05-02drm: introduce a capability flag for syncobj timeline supportLionel Landwerlin1-0/+1
Unfortunately userspace users of this API cannot be publicly disclosed yet. This commit effectively disables timeline syncobj ioctls for all drivers. Each driver wishing to support this feature will need to expose DRIVER_SYNCOBJ_TIMELINE. v2: Add uAPI capability check (Christian) Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> (v1) Cc: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Christian König <christian.koenig@amd.com> Cc: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190416125750.31370-1-lionel.g.landwerlin@intel.com
2019-04-24Merge tag 'drm-msm-next-2019-04-21' of ↵Dave Airlie1-0/+14
https://gitlab.freedesktop.org/drm/msm into drm-next This time around it is a bunch of cleanup and fixes, expanding gpu "zap" shader support (so we can take the GPU out of secure mode on boot) to a6xx, and small UABI extension to support robustness (see mesa MR 673). Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGsHwsEfi4y2LYKSqeqDEYvffwVgKhiP8jHcHpxp13J5LQ@mail.gmail.com
2019-04-24Merge branch 'drm-next-5.2' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie1-0/+8
into drm-next - Add the amdgpu specific bits for timeline support - Add internal interfaces for xgmi pstate support - DC Z ordering fixes for planes - Add support for NV12 planes in DC - Add colorspace properties for planes in DC - eDP optimizations if the GOP driver already initialized eDP - DC bandwidth validation tracing support Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190419150034.3473-1-alexander.deucher@amd.com
2019-04-24Merge tag 'drm-misc-next-2019-04-18' of ↵Dave Airlie1-0/+142
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v5.2: UAPI Changes: - Document which feature flags belong to which command in virtio_gpu.h - Make the FB_DAMAGE_CLIPS available for atomic userspace only, it's useless for legacy. Cross-subsystem Changes: - Add device tree bindings for lg,acx467akm-7 panel and ST-Ericsson Multi Channel Display Engine MCDE - Add parameters to the device tree bindings for tfp410 - iommu/io-pgtable: Add ARM Mali midgard MMU page table format - dma-buf: Only do a 64-bits seqno compare when driver explicitly asks for it, else wraparound. - Use the 64-bits compare for dma-fence-chains Core Changes: - Make the fb conversion functions use __iomem dst. - Rename drm_client_add to drm_client_register - Move intel_fb_initial_config to core. - Add a drm_gem_objects_lookup helper - Add drm_gem_fence_array helpers, and use it in lima. - Add drm_format_helper.c to kerneldoc. Driver Changes: - Add panfrost driver for mali midgard/bitfrost. - Converts bochs to use the simple display type. - Small fixes to sun4i, tinydrm, ti-fp410. - Fid aspeed's Kconfig options. - Make some symbols/functions static in lima, sun4i and meson. - Add a driver for the lg,acx467akm-7 panel. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/737ad994-213d-45b5-207a-b99d795acd21@linux.intel.com
2019-04-24Merge tag 'drm-intel-next-2019-04-17' of ↵Dave Airlie1-2/+13
git://anongit.freedesktop.org/drm/drm-intel into drm-next UAPI Changes: - uAPI "Fixes:" patch for the upcoming kernel 5.1, included here too We have an Ack from the media folks (only current user) for this late tweak Cross-subsystem Changes: - ALSA: hda: Fix racy display power access (Takashi, Chris) Driver Changes: - DDI and MIPI-DSI clocks fixes for Icelake (Vandita) - Fix Icelake frequency change/locking (RPS) (Mika) - Temporarily disable ppGTT read-only bit on Icelake (Mika) - Add missing Icelake W/As (Mika) - Enable 12 deep CSB status FIFO on Icelake (Mika) - Inherit more Icelake code for Elkhartlake (Bob, Jani) - Handle catastrophic error on engine reset (Mika) - Shortcut readiness to reset check (Mika) - Regression fix for GEM_BUSY causing us to report a mixed uabi-class request as not busy (Chris) - Revert back to max link rate and lane count on eDP (Jani) - Fix pipe BPP readout for BXT/GLK DSI (Ville) - Set DP min_bpp to 8*3 for non-RGB output formats (Ville) - Enable coarse preemption boundaries for Gen8 (Chris) - Do not enable FEC without DSC (Ville) - Restore correct BXT DDI latency optim setting calculation (Ville) - Always reset context's RING registers to avoid running workload twice during reset (Chris) - Set GPU wedged on driver unload (Janusz) - Consolidate two similar barries from timeline into one (Chris) - Only reset the pinned kernel contexts on resume (Chris) - Wakeref tracking improvements (Chris, Imre) - Lockdep fixes for shrinker interactions (Chris) - Bump ready tasks ahead of busywaits in prep of semaphore use (Chris) - Huge step in splitting display code into fine grained files (Jani) - Refactor the IRQ init/reset macros for code saving (Paulo) - Convert IRQ initialization code to uncore MMIO access (Paulo) - Convert workarounds code to use uncore MMIO access (Chris) - Nuke drm_crtc_state and use intel_atomic_state instead (Manasi) - Update SKL clock-gating WA (Radhakrishna, Ville) - Isolate GuC reset code flow (Chris) - Expose force_dsc_enable through debugfs (Manasi) - Header standalone compile testing framework (Jani) - Code cleanups to reduce driver footprint (Chris) - PSR code fixes and cleanups (Jose) - Sparse and kerneldoc updates (Chris) - Suppress spurious combo PHY B warning (Vile) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190418080426.GA6409@jlahtine-desk.ger.corp.intel.com
2019-04-19drm/msm/gpu: Add submit queue queriesJordan Crouse1-0/+12
Add the capability to query information from a submit queue. The first available parameter is for querying the number of GPU faults (hangs) that can be attributed to the queue. This is useful for implementing context robustness. A user context can regularly query the number of faults to see if it is responsible for any and if so it can invalidate itself. This is also helpful for testing by confirming to the user driver if a particular command stream caused a fault (or not as the case may be). Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org>
2019-04-19drm/msm: add param to retrieve # of GPU faults (global)Rob Clark1-0/+1
For KHR_robustness, userspace wants to know two things, the count of GPU faults globally, and the count of faults attributed to a given context. This patch providees the former, and the next patch provides the latter. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
2019-04-19drm/msm/gpu: add per-process pagetables paramRob Clark1-0/+1
For now it always returns '0' (false), but once the iommu work is in place to enable per-process pagetables we can update the value returned. Userspace needs to know this to make an informed decision about exposing KHR_robustness. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
2019-04-18drm/v3d: Add support for compute shader dispatch.Eric Anholt1-0/+28
The compute shader dispatch interface is pretty simple -- just pass in the regs that userspace has passed us, with no CLs to run. However, with no CL to run it means that we need to do manual cache flushing of the L2 after the HW execution completes (for SSBO, atomic, and image_load_store writes that are the output of compute shaders). This doesn't yet expose the L2 cache's ability to have a region of the address space not write back to memory (which could be used for shared_var storage). So far, the Mesa side has been tested on V3D v4.2 simpenrose (passing the ES31 tests), and on the kernel side on 7278 (failing atomic compswap tests in a way that doesn't reproduce on simpenrose). v2: Fix excessive allocation for the clean_job (reported by Dan Carpenter). Keep refs on jobs until clean_job is finished, to avoid spurious MMU errors if the output BOs are freed by userspace before L2 cleaning is finished. Signed-off-by: Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190416225856.20264-4-eric@anholt.net Acked-by: Rob Clark <robdclark@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-17 15:32:19 +0000