linux/Documentation/DocBook/gpu.tmpl

3540 lines
139 KiB

drm: implement experimental render nodes Render nodes provide an API for userspace to use non-privileged GPU commands without any running DRM-Master. It is useful for offscreen rendering, GPGPU clients, and normal render clients which do not perform modesetting. Compared to legacy clients, render clients no longer need any authentication to perform client ioctls. Instead, user-space controls render/client access to GPUs via filesystem access-modes on the render-node. Once a render-node was opened, a client has full access to the client/render operations on the GPU. However, no modesetting or ioctls that affect global state are allowed on render nodes. To prevent privilege-escalation, drivers must explicitly state that they support render nodes. They must mark their render-only ioctls as DRM_RENDER_ALLOW so render clients can use them. Furthermore, they must support clients without any attached master. If filesystem access-modes are not enough for fine-grained access control to render nodes (very unlikely, considering the versaitlity of FS-ACLs), you may still fall-back to fd-passing from server to client (which allows arbitrary access-control). However, note that revoking access is currently impossible and unlikely to get implemented. Note: Render clients no longer have any associated DRM-Master as they are supposed to be independent of any server state. DRM core highly depends on file_priv->master to be non-NULL for modesetting/ctx/etc. commands. Therefore, drivers must be very careful to not require DRM-Master if they support DRIVER_RENDER. So far render-nodes are protected by "drm_rnodes". As long as this module-parameter is not set to 1, a driver will not create render nodes. This allows us to experiment with the API a bit before we stabilize it. v2: drop insecure GEM_FLINK to force use of dmabuf Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-25 18:29:00 +02:00
drm: Global atomic state handling Some differences compared to Rob's patches again: - Dropped the committed and checked booleans. Checking will be internally enforced by always calling ->atomic_check before ->atomic_commit. And async handling needs to be solved differently because the current scheme completely side-steps ww mutex deadlock avoidance (and so either reinvents a new deadlock avoidance wheel or like the current code just deadlocks). - State for connectors needed to be added, since now they have a full-blown drm_connector_state (so that drivers have something to attach their own stuff to). - Refcounting is gone. I plane to solve async updates differently, since the lock-passing scheme doesn't cut it (since it abuses ww mutexes). Essentially what we need for async is a simple ownership transfer from the caller to the driver. That doesn't need full-blown refcounting. - The acquire ctx is a pointer. Real atomic callers should have that on their stack, legacy entry points need to put the right one (obtained by drm_modeset_legacy_acuire_ctx) in there. - I've dropped all hooks except check/commit. All the begin/end handling is done by core functions and is the same. - commit/check are just thin wrappers that ensure that ->check is always called. - To help out with locking in the legacy implementations I've added a helper to just grab all locks in the backoff case. v2: Add notices that check/commit can fail with EDEADLK. v3: - More consistent naming for state_alloc. - Add state_clear which is needed for backoff and retry. v4: Planes/connectors can switch between crtcs, and we need to be careful that we grab the state (and locks) for both the old and new crtc. Improve the interface functions to ensure this. v5: Add functions to grab affected connectors for a crtc and to recompute the crtc->enable state. This is useful for both helper and atomic ioctl code when e.g. removing a connector. v6: Squash in fixup from Fengguang to use ERR_CAST. v7: Add debug output. v8: Make checkpatch happy about kcalloc argument ordering. v9: Improve kerneldoc in drm_crtc.h v10: - Fix another kcalloc argument misorder I've missed. - More polish for kerneldoc. v11: Clarify the ownership rules for the state object. The new rule is that a successful drm_atomic_commit (whether synchronous or asnyc) always inherits the state and is responsible for the clean-up. That way async and sync ->commit functions are more similar. v12: A few bugfixes: - Assign state->state pointers correctly when grabbing state objects - we need to link them up with the global state. - Handle a NULL crtc in set_crtc_for_plane to simplify code flow a bit for the callers of this function. v13: Review from Sean: - kerneldoc spelling fixes - Don't overallocate states->planes. - Handle NULL crtc in set_crtc_for_connector. v14: Sprinkle __must_check over all functions which do wait/wound locking to make sure callers don't forget this. Since I have ;-) v15: Be more explicit in the kerneldoc when functions can return -EDEADLK what to do. And that every other -errno is fatal. v16: Indent with tabs instead of space, spotted by Ander. v17: Review from Thierry, small kerneldoc and other naming polish. Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com> Cc: Daniel Thompson <daniel.thompson@linaro.org> Cc: Fengguang Wu <fengguang.wu@intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-07-25 21:30:38 +02:00
drm: Add helper for DP++ adaptors Add a helper which aids in the identification of DP dual mode (aka. DP++) adaptors. There are several types of adaptors specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors may go as high as 300MHz and they provide a register informing the source device what the actual limit is. Supposedly also type 1 adaptors may optionally implement this register. This TMDS clock limit is the main reason why we need to identify these adaptors. Type 1 adaptors provide access to their internal registers and the sink DDC bus through I2C. Type 2 adaptors provide this access both via I2C and I2C-over-AUX. A type 2 source device may choose to implement either of these methods. If a source device implements the I2C-over-AUX method, then the driver will obviously need specific support for such adaptors since the port is driven like an HDMI port, but DDC communication happes over the AUX channel. This helper should be enough to identify the adaptor type (some type 1 DVI adaptors may be a slight exception) and the maximum TMDS clock limit. Another feature that may be available is control over the TMDS output buffers on the adaptor, possibly allowing for some power saving when the TMDS link is down. Other user controllable features that may be available in the adaptors are downstream i2c bus speed control when using i2c-over-aux, and some control over the CEC pin. I chose not to provide any helper functions for those since I have no use for them in i915 at this time. The rest of the registers in the adaptor are mostly just information, eg. IEEE OUI, hardware and firmware revision, etc. v2: Pass adaptor type to helper functions to ease driver implementation Fix a bunch of typoes (Paulo) Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know the type (Paulo) Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo) Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to ease future LSPCON enabling Remove the unused DP_DUAL_MODE_LAST_RESERVED define v3: Fix kernel doc function argument descriptions (Jani) s/NONE/UNKNOWN/ in drm_dp_dual_mode_detect() docs Add kernel doc for enum drm_dp_dual_mode_type Actually build the docs Fix more typoes v4: Adjust code indentation of type2 adaptor detection (Shashank) Add debug messages for failurs cases (Shashank) v5: EXPORT_SYMBOL(drm_dp_dual_mode_read) (Paulo) Cc: stable@vger.kernel.org Cc: Tore Anderson <tore@fud.no> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> (v4) Link: http://patchwork.freedesktop.org/patch/msgid/1462542412-25533-1-git-send-email-ville.syrjala@linux.intel.com (cherry picked from commit ede53344dbfd1dd43bfd73eb6af743d37c56a7c3) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-05-06 16:46:52 +03:00
drm/helper: add Displayport multi-stream helper (v0.6) This is the initial import of the helper for displayport multistream. It consists of a topology manager, init/destroy/set mst state It supports DP 1.2 MST sideband msg protocol handler - via hpd irqs connector detect and edid retrieval interface. It supports i2c device over DP 1.2 sideband msg protocol (EDID reads only) bandwidth manager API via vcpi allocation and payload updating, along with a helper to check the ACT status. Objects: MST topology manager - one per toplevel MST capable GPU port - not sure if this should be higher level again MST branch unit - one instance per plugged branching unit - one at top of hierarchy - others hanging from ports MST port - one port per port reported by branching units, can have MST units hanging from them as well. Changes since initial posting: a) add a mutex responsbile for the queues, it locks the sideband and msg slots, and msgs to transmit state b) add worker to handle connection state change events, for MST device chaining and hotplug c) add a payload spinlock d) add path sideband msg support e) fixup enum path resources transmit f) reduce max dpcd msg to 16, as per DP1.2 spec. g) separate tx queue kicking from irq processing and move irq acking back to drivers. Changes since v0.2: a) reorganise code, b) drop ACT forcing code c) add connector naming interface using path property d) add topology dumper helper e) proper reference counting and lookup for ports and mstbs. f) move tx kicking into a workq g) add aux locking - this should be redone h) split teardown into two parts i) start working on documentation on interface. Changes since v0.3: a) vc payload locking and tracking fixes b) add hotplug callback into driver - replaces crazy return 1 scheme c) txmsg + mst branch device refcount fixes d) don't bail on mst shutdown if device is gone e) change irq handler to take all 4 bytes of SINK_COUNT + ESI vectors f) make DP payload updates timeout longer - observed on docking station redock g) add more info to debugfs dumper Changes since v0.4: a) suspend/resume support b) more debugging in debugfs Changes since v0.5: a) use byte * to avoid unnecessary stack usage b) fix num_sdp_streams interpretation. c) init payload state for unplug events d) remove lenovo dock sink count hack e) drop aux lock - post rebase f) call hotplug on port destroy TODO: misc features Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-06-05 14:01:32 +10:00
drm: introduce pipe color correction properties Patch based on a previous series by Shashank Sharma. This introduces optional properties to enable color correction at the pipe level. It relies on 3 transformations applied to every pixels displayed. First a lookup into a degamma table, then a multiplication of the rgb components by a 3x3 matrix and finally another lookup into a gamma table. The following properties can be added to a pipe : - DEGAMMA_LUT : blob containing degamma LUT - DEGAMMA_LUT_SIZE : number of elements in DEGAMMA_LUT - CTM : transformation matrix applied after the degamma LUT - GAMMA_LUT : blob containing gamma LUT - GAMMA_LUT_SIZE : number of elements in GAMMA_LUT DEGAMMA_LUT_SIZE and GAMMA_LUT_SIZE are read only properties, set by the driver to tell userspace applications what sizes should be the lookup tables in DEGAMMA_LUT and GAMMA_LUT. A helper is also provided so legacy gamma correction is redirected through these new properties. v2: Register LUT size properties as range v3: Fix round in drm_color_lut_get_value() helper More docs on how degamma/gamma properties are used v4: Update contributors v5: Rename CTM_MATRIX property to CTM (Doh!) Add legacy gamma_set atomic helper Describe CTM/LUT acronyms in the kernel doc v6: Fix missing blob unref in drm_atomic_helper_crtc_reset Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Kumar, Kiran S <kiran.s.kumar@intel.com> Signed-off-by: Kausal Malladi <kausalmalladi@gmail.com> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Acked-by: Rob Bradford <robert.bradford@intel.com> [danvet: CrOS maintainers are also happy with the userspacde side: https://codereview.chromium.org/1182063002/ ] Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1456506302-640-4-git-send-email-lionel.g.landwerlin@intel.com
2016-02-26 17:05:00 +00:00
drm: introduce pipe color correction properties Patch based on a previous series by Shashank Sharma. This introduces optional properties to enable color correction at the pipe level. It relies on 3 transformations applied to every pixels displayed. First a lookup into a degamma table, then a multiplication of the rgb components by a 3x3 matrix and finally another lookup into a gamma table. The following properties can be added to a pipe : - DEGAMMA_LUT : blob containing degamma LUT - DEGAMMA_LUT_SIZE : number of elements in DEGAMMA_LUT - CTM : transformation matrix applied after the degamma LUT - GAMMA_LUT : blob containing gamma LUT - GAMMA_LUT_SIZE : number of elements in GAMMA_LUT DEGAMMA_LUT_SIZE and GAMMA_LUT_SIZE are read only properties, set by the driver to tell userspace applications what sizes should be the lookup tables in DEGAMMA_LUT and GAMMA_LUT. A helper is also provided so legacy gamma correction is redirected through these new properties. v2: Register LUT size properties as range v3: Fix round in drm_color_lut_get_value() helper More docs on how degamma/gamma properties are used v4: Update contributors v5: Rename CTM_MATRIX property to CTM (Doh!) Add legacy gamma_set atomic helper Describe CTM/LUT acronyms in the kernel doc v6: Fix missing blob unref in drm_atomic_helper_crtc_reset Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Kumar, Kiran S <kiran.s.kumar@intel.com> Signed-off-by: Kausal Malladi <kausalmalladi@gmail.com> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Acked-by: Rob Bradford <robert.bradford@intel.com> [danvet: CrOS maintainers are also happy with the userspacde side: https://codereview.chromium.org/1182063002/ ] Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1456506302-640-4-git-send-email-lionel.g.landwerlin@intel.com
2016-02-26 17:05:00 +00:00
drm: implement experimental render nodes Render nodes provide an API for userspace to use non-privileged GPU commands without any running DRM-Master. It is useful for offscreen rendering, GPGPU clients, and normal render clients which do not perform modesetting. Compared to legacy clients, render clients no longer need any authentication to perform client ioctls. Instead, user-space controls render/client access to GPUs via filesystem access-modes on the render-node. Once a render-node was opened, a client has full access to the client/render operations on the GPU. However, no modesetting or ioctls that affect global state are allowed on render nodes. To prevent privilege-escalation, drivers must explicitly state that they support render nodes. They must mark their render-only ioctls as DRM_RENDER_ALLOW so render clients can use them. Furthermore, they must support clients without any attached master. If filesystem access-modes are not enough for fine-grained access control to render nodes (very unlikely, considering the versaitlity of FS-ACLs), you may still fall-back to fd-passing from server to client (which allows arbitrary access-control). However, note that revoking access is currently impossible and unlikely to get implemented. Note: Render clients no longer have any associated DRM-Master as they are supposed to be independent of any server state. DRM core highly depends on file_priv->master to be non-NULL for modesetting/ctx/etc. commands. Therefore, drivers must be very careful to not require DRM-Master if they support DRIVER_RENDER. So far render-nodes are protected by "drm_rnodes". As long as this module-parameter is not set to 1, a driver will not create render nodes. This allows us to experiment with the API a bit before we stabilize it. v2: drop insecure GEM_FLINK to force use of dmabuf Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-25 18:29:00 +02:00
drm: implement experimental render nodes Render nodes provide an API for userspace to use non-privileged GPU commands without any running DRM-Master. It is useful for offscreen rendering, GPGPU clients, and normal render clients which do not perform modesetting. Compared to legacy clients, render clients no longer need any authentication to perform client ioctls. Instead, user-space controls render/client access to GPUs via filesystem access-modes on the render-node. Once a render-node was opened, a client has full access to the client/render operations on the GPU. However, no modesetting or ioctls that affect global state are allowed on render nodes. To prevent privilege-escalation, drivers must explicitly state that they support render nodes. They must mark their render-only ioctls as DRM_RENDER_ALLOW so render clients can use them. Furthermore, they must support clients without any attached master. If filesystem access-modes are not enough for fine-grained access control to render nodes (very unlikely, considering the versaitlity of FS-ACLs), you may still fall-back to fd-passing from server to client (which allows arbitrary access-control). However, note that revoking access is currently impossible and unlikely to get implemented. Note: Render clients no longer have any associated DRM-Master as they are supposed to be independent of any server state. DRM core highly depends on file_priv->master to be non-NULL for modesetting/ctx/etc. commands. Therefore, drivers must be very careful to not require DRM-Master if they support DRIVER_RENDER. So far render-nodes are protected by "drm_rnodes". As long as this module-parameter is not set to 1, a driver will not create render nodes. This allows us to experiment with the API a bit before we stabilize it. v2: drop insecure GEM_FLINK to force use of dmabuf Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-25 18:29:00 +02:00
drm: implement experimental render nodes Render nodes provide an API for userspace to use non-privileged GPU commands without any running DRM-Master. It is useful for offscreen rendering, GPGPU clients, and normal render clients which do not perform modesetting. Compared to legacy clients, render clients no longer need any authentication to perform client ioctls. Instead, user-space controls render/client access to GPUs via filesystem access-modes on the render-node. Once a render-node was opened, a client has full access to the client/render operations on the GPU. However, no modesetting or ioctls that affect global state are allowed on render nodes. To prevent privilege-escalation, drivers must explicitly state that they support render nodes. They must mark their render-only ioctls as DRM_RENDER_ALLOW so render clients can use them. Furthermore, they must support clients without any attached master. If filesystem access-modes are not enough for fine-grained access control to render nodes (very unlikely, considering the versaitlity of FS-ACLs), you may still fall-back to fd-passing from server to client (which allows arbitrary access-control). However, note that revoking access is currently impossible and unlikely to get implemented. Note: Render clients no longer have any associated DRM-Master as they are supposed to be independent of any server state. DRM core highly depends on file_priv->master to be non-NULL for modesetting/ctx/etc. commands. Therefore, drivers must be very careful to not require DRM-Master if they support DRIVER_RENDER. So far render-nodes are protected by "drm_rnodes". As long as this module-parameter is not set to 1, a driver will not create render nodes. This allows us to experiment with the API a bit before we stabilize it. v2: drop insecure GEM_FLINK to force use of dmabuf Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-25 18:29:00 +02:00
drm: implement experimental render nodes Render nodes provide an API for userspace to use non-privileged GPU commands without any running DRM-Master. It is useful for offscreen rendering, GPGPU clients, and normal render clients which do not perform modesetting. Compared to legacy clients, render clients no longer need any authentication to perform client ioctls. Instead, user-space controls render/client access to GPUs via filesystem access-modes on the render-node. Once a render-node was opened, a client has full access to the client/render operations on the GPU. However, no modesetting or ioctls that affect global state are allowed on render nodes. To prevent privilege-escalation, drivers must explicitly state that they support render nodes. They must mark their render-only ioctls as DRM_RENDER_ALLOW so render clients can use them. Furthermore, they must support clients without any attached master. If filesystem access-modes are not enough for fine-grained access control to render nodes (very unlikely, considering the versaitlity of FS-ACLs), you may still fall-back to fd-passing from server to client (which allows arbitrary access-control). However, note that revoking access is currently impossible and unlikely to get implemented. Note: Render clients no longer have any associated DRM-Master as they are supposed to be independent of any server state. DRM core highly depends on file_priv->master to be non-NULL for modesetting/ctx/etc. commands. Therefore, drivers must be very careful to not require DRM-Master if they support DRIVER_RENDER. So far render-nodes are protected by "drm_rnodes". As long as this module-parameter is not set to 1, a driver will not create render nodes. This allows us to experiment with the API a bit before we stabilize it. v2: drop insecure GEM_FLINK to force use of dmabuf Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-25 18:29:00 +02:00
drm: implement experimental render nodes Render nodes provide an API for userspace to use non-privileged GPU commands without any running DRM-Master. It is useful for offscreen rendering, GPGPU clients, and normal render clients which do not perform modesetting. Compared to legacy clients, render clients no longer need any authentication to perform client ioctls. Instead, user-space controls render/client access to GPUs via filesystem access-modes on the render-node. Once a render-node was opened, a client has full access to the client/render operations on the GPU. However, no modesetting or ioctls that affect global state are allowed on render nodes. To prevent privilege-escalation, drivers must explicitly state that they support render nodes. They must mark their render-only ioctls as DRM_RENDER_ALLOW so render clients can use them. Furthermore, they must support clients without any attached master. If filesystem access-modes are not enough for fine-grained access control to render nodes (very unlikely, considering the versaitlity of FS-ACLs), you may still fall-back to fd-passing from server to client (which allows arbitrary access-control). However, note that revoking access is currently impossible and unlikely to get implemented. Note: Render clients no longer have any associated DRM-Master as they are supposed to be independent of any server state. DRM core highly depends on file_priv->master to be non-NULL for modesetting/ctx/etc. commands. Therefore, drivers must be very careful to not require DRM-Master if they support DRIVER_RENDER. So far render-nodes are protected by "drm_rnodes". As long as this module-parameter is not set to 1, a driver will not create render nodes. This allows us to experiment with the API a bit before we stabilize it. v2: drop insecure GEM_FLINK to force use of dmabuf Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-25 18:29:00 +02:00
drm: implement experimental render nodes Render nodes provide an API for userspace to use non-privileged GPU commands without any running DRM-Master. It is useful for offscreen rendering, GPGPU clients, and normal render clients which do not perform modesetting. Compared to legacy clients, render clients no longer need any authentication to perform client ioctls. Instead, user-space controls render/client access to GPUs via filesystem access-modes on the render-node. Once a render-node was opened, a client has full access to the client/render operations on the GPU. However, no modesetting or ioctls that affect global state are allowed on render nodes. To prevent privilege-escalation, drivers must explicitly state that they support render nodes. They must mark their render-only ioctls as DRM_RENDER_ALLOW so render clients can use them. Furthermore, they must support clients without any attached master. If filesystem access-modes are not enough for fine-grained access control to render nodes (very unlikely, considering the versaitlity of FS-ACLs), you may still fall-back to fd-passing from server to client (which allows arbitrary access-control). However, note that revoking access is currently impossible and unlikely to get implemented. Note: Render clients no longer have any associated DRM-Master as they are supposed to be independent of any server state. DRM core highly depends on file_priv->master to be non-NULL for modesetting/ctx/etc. commands. Therefore, drivers must be very careful to not require DRM-Master if they support DRIVER_RENDER. So far render-nodes are protected by "drm_rnodes". As long as this module-parameter is not set to 1, a driver will not create render nodes. This allows us to experiment with the API a bit before we stabilize it. v2: drop insecure GEM_FLINK to force use of dmabuf Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-08-25 18:29:00 +02:00
drm/i915: Introduce a PV INFO page structure for Intel GVT-g. Introduce a PV INFO structure, to facilitate the Intel GVT-g technology, which is a GPU virtualization solution with mediated pass-through. This page contains the shared information between i915 driver and the host emulator. For now, this structure utilizes an area of 4K bytes on HSW GPU's unused MMIO space. Future hardware will have the reserved window architecturally defined, and layout of the page will be added in future BSpec. The i915 driver load routine detects if it is running in a VM by reading the contents of this PV INFO page. Thereafter a flag, vgpu.active is set, and intel_vgpu_active() is used by checking this flag to conclude if GPU is virtualized with Intel GVT-g. By now, intel_vgpu_active() will return true, only when the driver is running as a guest in the Intel GVT-g enhanced environment on HSW platform. v2: take Chris' comments: - call the i915_check_vgpu() in intel_uncore_init() - sanitize i915_check_vgpu() by adding BUILD_BUG_ON() and debug info take Daniel's comments: - put the definition of PV INFO into a new header - i915_vgt_if.h other changes: - access mmio regs by readq/readw in i915_check_vgpu() v3: take Daniel's comments: - move the i915/vgt interfaces into a new i915_vgpu.c - update makefile - add kerneldoc to functions which are non-static - add a DOC: section describing some of the high-level design - update drm docbook other changes: - rename i915_vgt_if.h to i915_vgpu.h v4: take Tvrtko's comments: - fix a typo in commit message - add debug message when vgt version mismatches - rename low_gmadr/high_gmadr to mappable/non-mappable in PV INFO structure Signed-off-by: Yu Zhang <yu.c.zhang@linux.intel.com> Signed-off-by: Jike Song <jike.song@intel.com> Signed-off-by: Eddie Dong <eddie.dong@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-10 19:05:47 +08:00
drm/i915: Move to atomic plane helpers (v9) Switch plane handling to use the atomic plane helpers. This means that rather than provide our own implementations of .update_plane() and .disable_plane(), we expose the lower-level check/prepare/commit/cleanup entrypoints and let the DRM core implement update/disable for us using those entrypoints. The other main change that falls out of this patch is that our drm_plane's will now always have a valid plane->state that contains the relevant plane state (initial state is allocated at plane creation). The base drm_plane_state pointed to holds the requested source/dest coordinates, and the subclassed intel_plane_state holds the adjusted values that our driver actually uses. v2: - Renamed file from intel_atomic.c to intel_atomic_plane.c (Daniel) - Fix a copy/paste comment mistake (Bob) v3: - Use prepare/cleanup functions that we've already factored out - Use newly refactored pre_commit/commit/post_commit to avoid sleeping during vblank evasion v4: - Rebase to latest di-nightly requires adding an 'old_state' parameter to atomic_update; v5: - Must have botched a rebase somewhere and lost some work. Restore state 'dirty' flag to let begin/end code know which planes to run the pre_commit/post_commit hooks for. This would have actually shown up as broken in the next commit rather than this one. v6: - Squash kerneldoc patch into this one. - Previous patches have now already taken care of most of the infrastructure that used to be in this patch. All we're adding here now is some thin wrappers. v7: - Check return of intel_plane_duplicate_state() for allocation failures. v8: - Drop unused drm_plane_state -> intel_plane_state cast. (Ander) - Squash in actual transition to plane helpers. Significant refactoring earlier in the patchset has made the combined prep+transition much easier to swallow than it was in earlier iterations. (Ander) v9: - s/track_fbs/disabled_planes/ in the atomic crtc flags. The only fb's we need to update frontbuffer tracking for are those on a plane about to be disabled (since the atomic helpers never call prepare_fb() when disabling a plane), so the new name more accurately describes what we're actually tracking. Testcase: igt/kms_plane Testcase: igt/kms_universal_plane Testcase: igt/kms_cursor_crc Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-23 10:41:52 -08:00
drm/i915: Implement a framework for batch buffer pools This adds a small module for managing a pool of batch buffers. The only current use case is for the command parser, as described in the kerneldoc in the patch. The code is simple, but separating it out makes it easier to change the underlying algorithms and to extend to future use cases should they arise. The interface is simple: init to create an empty pool, fini to clean it up, get to obtain a new buffer. Note that all buffers are expected to be inactive before cleaning up the pool. Locking is currently based on the caller holding the struct_mutex. We already do that in the places where we will use the batch pool for the command parser. v2: - s/BUG_ON/WARN_ON/ for locking assertions - Remove the cap on pool size - Switch from alloc/free to init/fini v3: - Idiomatic looping structure in _fini - Correct handling of purged objects - Don't return a buffer that's too much larger than needed v4: - Rebased to latest -nightly v5: - Remove _put() function and clean up comments to match v6: - Move purged check inside the loop (danvet, from v4 1/7 feedback) v7: - Use single list instead of two. (Chris W) - s/active_list/cache_list - Squashed in debug patches (Chris W) drm/i915: Add a batch pool debugfs file It provides some useful information about the buffers in the global command parser batch pool. v2: rebase on global pool instead of per-ring pools v3: rebase drm/i915: Add batch pool details to i915_gem_objects debugfs To better account for the potentially large memory consumption of the batch pool. v8: - Keep cache in LRU order (danvet, from v6 1/5 feedback) Issue: VIZ-4719 Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com> Reviewed-By: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-11 12:13:08 -08:00
drm/i915: Integrate GuC-based command submission GuC-based submission is mostly the same as execlist mode, up to intel_logical_ring_advance_and_submit(), where the context being dispatched would be added to the execlist queue; at this point we submit the context to the GuC backend instead. There are, however, a few other changes also required, notably: 1. Contexts must be pinned at GGTT addresses accessible by the GuC i.e. NOT in the range [0..WOPCM_SIZE), so we have to add the PIN_OFFSET_BIAS flag to the relevant GGTT-pinning calls. 2. The GuC's TLB must be invalidated after a context is pinned at a new GGTT address. 3. GuC firmware uses the one page before Ring Context as shared data. Therefore, whenever driver wants to get base address of LRC, we will offset one page for it. LRC_PPHWSP_PN is defined as the page number of LRCA. 4. In the work queue used to pass requests to the GuC, the GuC firmware requires the ring-tail-offset to be represented as an 11-bit value, expressed in QWords. Therefore, the ringbuffer size must be reduced to the representable range (4 pages). v2: Defer adding #defines until needed [Chris Wilson] Rationalise type declarations [Chris Wilson] v4: Squashed kerneldoc patch into here [Daniel Vetter] v5: Update request->tail in code common to both GuC and execlist modes. Add a private version of lr_context_update(), as sharing the execlist version leads to race conditions when the CPU and the GuC both update TAIL in the context image. Conversion of error-captured HWS page to string must account for offset from start of object to actual HWS (LRC_PPHWSP_PN). Issue: VIZ-4884 Signed-off-by: Alex Dai <yu.dai@intel.com> Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12 15:43:43 +01:00
drm/i915: Integrate GuC-based command submission GuC-based submission is mostly the same as execlist mode, up to intel_logical_ring_advance_and_submit(), where the context being dispatched would be added to the execlist queue; at this point we submit the context to the GuC backend instead. There are, however, a few other changes also required, notably: 1. Contexts must be pinned at GGTT addresses accessible by the GuC i.e. NOT in the range [0..WOPCM_SIZE), so we have to add the PIN_OFFSET_BIAS flag to the relevant GGTT-pinning calls. 2. The GuC's TLB must be invalidated after a context is pinned at a new GGTT address. 3. GuC firmware uses the one page before Ring Context as shared data. Therefore, whenever driver wants to get base address of LRC, we will offset one page for it. LRC_PPHWSP_PN is defined as the page number of LRCA. 4. In the work queue used to pass requests to the GuC, the GuC firmware requires the ring-tail-offset to be represented as an 11-bit value, expressed in QWords. Therefore, the ringbuffer size must be reduced to the representable range (4 pages). v2: Defer adding #defines until needed [Chris Wilson] Rationalise type declarations [Chris Wilson] v4: Squashed kerneldoc patch into here [Daniel Vetter] v5: Update request->tail in code common to both GuC and execlist modes. Add a private version of lr_context_update(), as sharing the execlist version leads to race conditions when the CPU and the GuC both update TAIL in the context image. Conversion of error-captured HWS page to string must account for offset from start of object to actual HWS (LRC_PPHWSP_PN). Issue: VIZ-4884 Signed-off-by: Alex Dai <yu.dai@intel.com> Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12 15:43:43 +01:00
drm/i915: Integrate GuC-based command submission GuC-based submission is mostly the same as execlist mode, up to intel_logical_ring_advance_and_submit(), where the context being dispatched would be added to the execlist queue; at this point we submit the context to the GuC backend instead. There are, however, a few other changes also required, notably: 1. Contexts must be pinned at GGTT addresses accessible by the GuC i.e. NOT in the range [0..WOPCM_SIZE), so we have to add the PIN_OFFSET_BIAS flag to the relevant GGTT-pinning calls. 2. The GuC's TLB must be invalidated after a context is pinned at a new GGTT address. 3. GuC firmware uses the one page before Ring Context as shared data. Therefore, whenever driver wants to get base address of LRC, we will offset one page for it. LRC_PPHWSP_PN is defined as the page number of LRCA. 4. In the work queue used to pass requests to the GuC, the GuC firmware requires the ring-tail-offset to be represented as an 11-bit value, expressed in QWords. Therefore, the ringbuffer size must be reduced to the representable range (4 pages). v2: Defer adding #defines until needed [Chris Wilson] Rationalise type declarations [Chris Wilson] v4: Squashed kerneldoc patch into here [Daniel Vetter] v5: Update request->tail in code common to both GuC and execlist modes. Add a private version of lr_context_update(), as sharing the execlist version leads to race conditions when the CPU and the GuC both update TAIL in the context image. Conversion of error-captured HWS page to string must account for offset from start of object to actual HWS (LRC_PPHWSP_PN). Issue: VIZ-4884 Signed-off-by: Alex Dai <yu.dai@intel.com> Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12 15:43:43 +01:00
drm/i915: Integrate GuC-based command submission GuC-based submission is mostly the same as execlist mode, up to intel_logical_ring_advance_and_submit(), where the context being dispatched would be added to the execlist queue; at this point we submit the context to the GuC backend instead. There are, however, a few other changes also required, notably: 1. Contexts must be pinned at GGTT addresses accessible by the GuC i.e. NOT in the range [0..WOPCM_SIZE), so we have to add the PIN_OFFSET_BIAS flag to the relevant GGTT-pinning calls. 2. The GuC's TLB must be invalidated after a context is pinned at a new GGTT address. 3. GuC firmware uses the one page before Ring Context as shared data. Therefore, whenever driver wants to get base address of LRC, we will offset one page for it. LRC_PPHWSP_PN is defined as the page number of LRCA. 4. In the work queue used to pass requests to the GuC, the GuC firmware requires the ring-tail-offset to be represented as an 11-bit value, expressed in QWords. Therefore, the ringbuffer size must be reduced to the representable range (4 pages). v2: Defer adding #defines until needed [Chris Wilson] Rationalise type declarations [Chris Wilson] v4: Squashed kerneldoc patch into here [Daniel Vetter] v5: Update request->tail in code common to both GuC and execlist modes. Add a private version of lr_context_update(), as sharing the execlist version leads to race conditions when the CPU and the GuC both update TAIL in the context image. Conversion of error-captured HWS page to string must account for offset from start of object to actual HWS (LRC_PPHWSP_PN). Issue: VIZ-4884 Signed-off-by: Alex Dai <yu.dai@intel.com> Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12 15:43:43 +01:00
drm/i915: Integrate GuC-based command submission GuC-based submission is mostly the same as execlist mode, up to intel_logical_ring_advance_and_submit(), where the context being dispatched would be added to the execlist queue; at this point we submit the context to the GuC backend instead. There are, however, a few other changes also required, notably: 1. Contexts must be pinned at GGTT addresses accessible by the GuC i.e. NOT in the range [0..WOPCM_SIZE), so we have to add the PIN_OFFSET_BIAS flag to the relevant GGTT-pinning calls. 2. The GuC's TLB must be invalidated after a context is pinned at a new GGTT address. 3. GuC firmware uses the one page before Ring Context as shared data. Therefore, whenever driver wants to get base address of LRC, we will offset one page for it. LRC_PPHWSP_PN is defined as the page number of LRCA. 4. In the work queue used to pass requests to the GuC, the GuC firmware requires the ring-tail-offset to be represented as an 11-bit value, expressed in QWords. Therefore, the ringbuffer size must be reduced to the representable range (4 pages). v2: Defer adding #defines until needed [Chris Wilson] Rationalise type declarations [Chris Wilson] v4: Squashed kerneldoc patch into here [Daniel Vetter] v5: Update request->tail in code common to both GuC and execlist modes. Add a private version of lr_context_update(), as sharing the execlist version leads to race conditions when the CPU and the GuC both update TAIL in the context image. Conversion of error-captured HWS page to string must account for offset from start of object to actual HWS (LRC_PPHWSP_PN). Issue: VIZ-4884 Signed-off-by: Alex Dai <yu.dai@intel.com> Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-12 15:43:43 +01:00
apple-gmux: Add initial documentation Document what I've learned so far about the gmux so that we can collaboratively reverse-engineer its remaining unknown bits without everyone having to start from scratch. The DOC sections are bound together in the gpu.tmpl DocBook under a new vga_switcheroo "Handlers" chapter. Eventually this should be amended with documentation about the four other handlers that exist so far (nouveau v1 DSM, nouveau Optimus DSM, radeon ATPX, amdgpu ATPX). Requires kernel-doc with asciidoc support. The EFI variable was reverse-engineered by Bruno Bierbaumer <bruno@bierbaumer.net> and Andreas Heider <andreas@meetr.de>. Some of the remaining open questions: * How are vblank intervals synchronized on retinas to achieve seamless switching? Is the DP mux capable of this? It's not mentioned in the data sheets. Or is it done at the OS level, i.e. do we have to synchronize vblank intervals between DRM drivers? There's a signal coming from the panel connector and going into gmux, could this be the vblank signal as received by the panel to properly time the switch? * On retinas there's an I2C bus between gmux and the connector of the right I/O board, apparently leading to the Parade PS8401A HDMI repeater. What is this for, is it controlled via gmux registers? Data sheet: http://www.paradetech.com/products/jitter-cleaning-repeaters/ps8401/ * On retinas there's an I2C bus between gmux and the LED driver. Pre-retinas connected the LED driver to SMBUS. Are there additional gmux registers on retinas to control it? * The MacPro6,1 2013 also has a gmux, the same Renesas R4F2113 as the retina MacBook Pro. The Mac Pro doesn't have a built-in display, so what is its purpose? Power control of the dual FirePro GPUs? Switching of the external DP/Thunderbolt ports? The iFixit teardown clearly shows one TI HD3SS212 DisplayPort mux on the logic board next to one of the three Thunderbolt controllers. However six muxes would be necessary to switch all six ports between GPUs. The mux is probably necessary for one of the display configurations allowed by Apple, but which one? https://www.ifixit.com/Teardown/Mac+Pro+Late+2013+Teardown/20778 https://d3nevzfk7ii3be.cloudfront.net/igi/fELBTnt31QhnDsqq.huge https://support.apple.com/en-us/HT202801 * Registers we haven't decoded yet: 0x700 32 Bit configmap? 0x708 32 Bit power sequence? 0x712 8 Bit status of clock from panel on retinas? 0x713 8 Bit dito? 0x724 16 Bit backlight, raw value? 0x760 32 Bit backlight 0x764 32 Bit backlight 0x768 8 Bit backlight 0x76a 16 Bit backlight 0x76c 16 Bit backlight 0x76e 16 Bit backlight 0x77f edp/dp/hdmi probe? retina only. * Addition by Bruno Prémont <bonbons@linux-vserver.org>: "Missing is also precise knowledge as to what the gmux depends on. From behavioral reports, it is somehow sensitive to VGA IO/MEM routing (it apparently needs the routing to go to integrated GPU, not discrete GPU). When the routing is inappropriate backlight control IO just reads back as 0xFF (and eventually gmux IO in general does so)." Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Darren Hart <dvhart@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/da309e436fbeac886477d80376457b7d83ea4b2d.1452431795.git.lukas@wunner.de Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-01-11 00:08:35 +01:00
apple-gmux: Add initial documentation Document what I've learned so far about the gmux so that we can collaboratively reverse-engineer its remaining unknown bits without everyone having to start from scratch. The DOC sections are bound together in the gpu.tmpl DocBook under a new vga_switcheroo "Handlers" chapter. Eventually this should be amended with documentation about the four other handlers that exist so far (nouveau v1 DSM, nouveau Optimus DSM, radeon ATPX, amdgpu ATPX). Requires kernel-doc with asciidoc support. The EFI variable was reverse-engineered by Bruno Bierbaumer <bruno@bierbaumer.net> and Andreas Heider <andreas@meetr.de>. Some of the remaining open questions: * How are vblank intervals synchronized on retinas to achieve seamless switching? Is the DP mux capable of this? It's not mentioned in the data sheets. Or is it done at the OS level, i.e. do we have to synchronize vblank intervals between DRM drivers? There's a signal coming from the panel connector and going into gmux, could this be the vblank signal as received by the panel to properly time the switch? * On retinas there's an I2C bus between gmux and the connector of the right I/O board, apparently leading to the Parade PS8401A HDMI repeater. What is this for, is it controlled via gmux registers? Data sheet: http://www.paradetech.com/products/jitter-cleaning-repeaters/ps8401/ * On retinas there's an I2C bus between gmux and the LED driver. Pre-retinas connected the LED driver to SMBUS. Are there additional gmux registers on retinas to control it? * The MacPro6,1 2013 also has a gmux, the same Renesas R4F2113 as the retina MacBook Pro. The Mac Pro doesn't have a built-in display, so what is its purpose? Power control of the dual FirePro GPUs? Switching of the external DP/Thunderbolt ports? The iFixit teardown clearly shows one TI HD3SS212 DisplayPort mux on the logic board next to one of the three Thunderbolt controllers. However six muxes would be necessary to switch all six ports between GPUs. The mux is probably necessary for one of the display configurations allowed by Apple, but which one? https://www.ifixit.com/Teardown/Mac+Pro+Late+2013+Teardown/20778 https://d3nevzfk7ii3be.cloudfront.net/igi/fELBTnt31QhnDsqq.huge https://support.apple.com/en-us/HT202801 * Registers we haven't decoded yet: 0x700 32 Bit configmap? 0x708 32 Bit power sequence? 0x712 8 Bit status of clock from panel on retinas? 0x713 8 Bit dito? 0x724 16 Bit backlight, raw value? 0x760 32 Bit backlight 0x764 32 Bit backlight 0x768 8 Bit backlight 0x76a 16 Bit backlight 0x76c 16 Bit backlight 0x76e 16 Bit backlight 0x77f edp/dp/hdmi probe? retina only. * Addition by Bruno Prémont <bonbons@linux-vserver.org>: "Missing is also precise knowledge as to what the gmux depends on. From behavioral reports, it is somehow sensitive to VGA IO/MEM routing (it apparently needs the routing to go to integrated GPU, not discrete GPU). When the routing is inappropriate backlight control IO just reads back as 0xFF (and eventually gmux IO in general does so)." Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Darren Hart <dvhart@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/da309e436fbeac886477d80376457b7d83ea4b2d.1452431795.git.lukas@wunner.de Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-01-11 00:08:35 +01:00
apple-gmux: Add initial documentation Document what I've learned so far about the gmux so that we can collaboratively reverse-engineer its remaining unknown bits without everyone having to start from scratch. The DOC sections are bound together in the gpu.tmpl DocBook under a new vga_switcheroo "Handlers" chapter. Eventually this should be amended with documentation about the four other handlers that exist so far (nouveau v1 DSM, nouveau Optimus DSM, radeon ATPX, amdgpu ATPX). Requires kernel-doc with asciidoc support. The EFI variable was reverse-engineered by Bruno Bierbaumer <bruno@bierbaumer.net> and Andreas Heider <andreas@meetr.de>. Some of the remaining open questions: * How are vblank intervals synchronized on retinas to achieve seamless switching? Is the DP mux capable of this? It's not mentioned in the data sheets. Or is it done at the OS level, i.e. do we have to synchronize vblank intervals between DRM drivers? There's a signal coming from the panel connector and going into gmux, could this be the vblank signal as received by the panel to properly time the switch? * On retinas there's an I2C bus between gmux and the connector of the right I/O board, apparently leading to the Parade PS8401A HDMI repeater. What is this for, is it controlled via gmux registers? Data sheet: http://www.paradetech.com/products/jitter-cleaning-repeaters/ps8401/ * On retinas there's an I2C bus between gmux and the LED driver. Pre-retinas connected the LED driver to SMBUS. Are there additional gmux registers on retinas to control it? * The MacPro6,1 2013 also has a gmux, the same Renesas R4F2113 as the retina MacBook Pro. The Mac Pro doesn't have a built-in display, so what is its purpose? Power control of the dual FirePro GPUs? Switching of the external DP/Thunderbolt ports? The iFixit teardown clearly shows one TI HD3SS212 DisplayPort mux on the logic board next to one of the three Thunderbolt controllers. However six muxes would be necessary to switch all six ports between GPUs. The mux is probably necessary for one of the display configurations allowed by Apple, but which one? https://www.ifixit.com/Teardown/Mac+Pro+Late+2013+Teardown/20778 https://d3nevzfk7ii3be.cloudfront.net/igi/fELBTnt31QhnDsqq.huge https://support.apple.com/en-us/HT202801 * Registers we haven't decoded yet: 0x700 32 Bit configmap? 0x708 32 Bit power sequence? 0x712 8 Bit status of clock from panel on retinas? 0x713 8 Bit dito? 0x724 16 Bit backlight, raw value? 0x760 32 Bit backlight 0x764 32 Bit backlight 0x768 8 Bit backlight 0x76a 16 Bit backlight 0x76c 16 Bit backlight 0x76e 16 Bit backlight 0x77f edp/dp/hdmi probe? retina only. * Addition by Bruno Prémont <bonbons@linux-vserver.org>: "Missing is also precise knowledge as to what the gmux depends on. From behavioral reports, it is somehow sensitive to VGA IO/MEM routing (it apparently needs the routing to go to integrated GPU, not discrete GPU). When the routing is inappropriate backlight control IO just reads back as 0xFF (and eventually gmux IO in general does so)." Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Darren Hart <dvhart@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/da309e436fbeac886477d80376457b7d83ea4b2d.1452431795.git.lukas@wunner.de Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-01-11 00:08:35 +01:00