- 23 Nov, 2016 16 commits
-
-
Ville Syrjälä authored
A modeset on one pipe can update dev_priv->atomic_cdclk_freq without actually touching the hardware, in which case we won't force a modeset on all the pipes, and thus won't lock any of the other pipes either. That means a parallel plane update on another pipe could be looking at a stale dev_priv->atomic_cdcdlk_freq and thus fail to notice when the plane configuration is invalid, or potentially reject a valid update. To overcome this we must protect writes to atomic_cdclk_freq with all the crtc locks, and thus for reads any single crtc lock will be sufficient protection. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1479141311-11904-3-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
When we end up not recomputing the cdclk, we need to populate intel_state->cdclk with the "atomic_cdclk_freq" instead of the current cdclk_freq. When no pipes are active, the actual cdclk_freq may be lower than what the configuration of the planes and pipes would require from the point of view of the software state. This fixes bogus WARNS from skl_max_scale() which is trying to check the plane software state against the cdclk frequency. So any time it got called during DPMS off for instance, we might have tripped the warn if the current mode would have required a higher than minimum cdclk. v2: Drop the dev_cdclk stuff (Maarten) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: bruno.pagani@ens-lyon.org Cc: Daniel J Blueman <daniel.blueman@gmail.com> Cc: Paul Bolle <pebolle@tiscali.nl> Cc: Joseph Yasi <joe.yasi@gmail.com> Tested-by:
Paul Bolle <pebolle@tiscali.nl> Tested-by: Joseph Yasi <joe.yasi@gmail.com> (v1) Cc: stable@vger.kernel.org Fixes: 1a617b77 ("drm/i915: Keep track of the cdclk as if all crtc's were active.") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98214Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1479141311-11904-2-git-send-email-ville.syrjala@linux.intel.com
-
Bob Paauwe authored
For BXT, there is only one bit that enables/disables dual-link mode and not different bits depending on which pipe is being used. Signed-off-by:
Bob Paauwe <bob.j.paauwe@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1479767046-3964-1-git-send-email-bob.j.paauwe@intel.comSigned-off-by:
-
Ville Syrjälä authored
Let's try not to abuse plane->plane for sprites on VLV/CHV and instead use plane->id. Since out watermark structures aren't entirely plane type agnostic (for now) and start indexing sprites from 0 we'll add a small helper to convert between the two bases. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1479830524-7882-7-git-send-email-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
Use intel_plane->id to derive the VLV/CHV sprite register offsets instead of abusing plane->plane which is really meant to for primary planes only. v2: Convert assert_sprites_disabled() over as well v3: Rename the reg macro parameter to 'plane_id' as well (Paulo) Signed-off-by:
-
Ville Syrjälä authored
Replace the intel_plane->plane and hardcoded 0 usage in the SKL plane code with intel_plane->id. This should make the SKL "primary" and "sprite" code virtually identical, so the next logical step would likely be dropping one of the copies. Signed-off-by:
-
Ville Syrjälä authored
Nuke skl_wm_plane_id() and just use the new intel_plane->id. v2: Convert skl_write_plane_wm() as well v3: Convert skl_pipe_wm_get_hw_state() correctly v4: Rebase due to changes in the wm code Drop the cursor FIXME from the total data rate calc (Paulo) Use the "[PLANE:%d:%s]" format in debug print (Paulo) Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Lyude <cpaul@redhat.com> Signed-off-by:Lyude <lyude@redhat.com>
-
Ville Syrjälä authored
Add a mask of which planes are available for each pipe. This doesn't quite work for old platforms with dynamic plane<->pipe assignment, but as we don't support that sort of stuff (yet) we can get away with it. The main use I have for this is the for_each_plane_id_on_crtc() macro for iterating over all possible planes on the crtc. I suppose we could not add the mask, and instead iterate by comparing intel_plane->pipe but then we'd need a local intel_plane variable which is just unnecessary clutter in some cases. But I'm not hung up on this, so if people prefer the other option I could be convinced to use it. v2: Use BIT() in the iterator macro too (Paulo) Signed-off-by:
-
Ville Syrjälä authored
As I told people in [1] we really should not be confusing enum plane as a per-pipe plane identifier. Looks like that happened nonetheless, so let's fix it up by splitting the two into two enums. We'll also want something we just directly pass to various register offset macros and whatnot on SKL+. So let's make this new thing work for that. Currently we pass intel_plane->plane for the "sprites" and just a hardcoded zero for the "primary" planes. We want to get rid of that hardocoding so that we can share the same code for all planes (apart from the legacy cursor of course). [1] https://lists.freedesktop.org/archives/intel-gfx/2015-September/076082.html Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Ville Syrjälä authored
Someone forgot to make skl_write_{plane,cursor}_wm() static when removing the prototypes from the header. Sparse isn't pleased. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Lyude <cpaul@redhat.com> Cc: Matt Roper <matthew.d.roper@intel.com> Fixes: e62929b3 ("drm/i915/gen9+: Program watermarks as a separate step during evasion, v3.") Signed-off-by: -
Tvrtko Ursulin authored
It has only one call site from the same file. v2: Also rename it to alloc_context_obj. (Chris Wilson) Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1479898155-21014-1-git-send-email-tvrtko.ursulin@linux.intel.com
-
Tvrtko Ursulin authored
Signed-off-by:
-
Imre Deak authored
All callers asked for a forced change but the function ignored this parameter. It doesn't seem to be necessary to force the change in any case so let's just remove the parameter. Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Shashank Sharma <shashank.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1479755707-29596-5-git-send-email-imre.deak@intel.com
-
Imre Deak authored
Some LSPCON adaptors may return an incorrect LSPCON mode right after waking from DP Sleep state. This is the case at least for the ParadTech PS175 adaptor, both when waking because of exiting the DP Sleep to active state, or due to any other AUX CH transfer. We can determine the current expected mode based on whether the DPCD area is accessible, since according to the LSPCON spec this area is only accesible in PCON mode. This wait will avoid us trying to change the mode, while the current expected mode hasn't settled yet and start link training before the adaptor thinks it's in PCON mode after waking from DP Sleep state. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Imre Deak authored
We need to get to LSPCON in the next patch, so factor out the helper for it. While at it also remove the redundant GEN9 check. Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
-
Imre Deak authored
Some LSPCON adaptors won't properly wake up in response to an AUX request after the adaptor was placed to a DP Sink Sleep state (via writing 0x2 to DP_SET_POWER). Based on the DP 1.4 specification 5.2.5, the sink may place the AUX CH into a low-power state while in Sleep state, but should wake it up in response to an AUX request within 1-20ms (answering with AUX defers while waking it up). As opposed to this at least the ParadTech PS175 adaptor won't fully wake in response to the first I2C-over-AUX access and will occasionally ignore the offset in I2C messages. This can result in accessing the DDC register at offset 0 regardless of the specified offset and the LSPCON detection failing. To fix this do an initial dummy read from the DPCD area. The PS175 will defer this access until it's fully woken (taking ~150ms) making sure the following I2C-over-AUX accesses will work correctly. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=98353Signed-off-by:
-
- 22 Nov, 2016 15 commits
-
-
Chris Wilson authored
In order to prevent a race between the old callback submitting an incomplete request and i915_gem_set_wedged() installing its nop handler, we must ensure that the swap occurs when the machine is idle (stop_machine). v2: move context lost from out of BKL. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161122144121.7379-4-chris@chris-wilson.co.uk
-
Chris Wilson authored
Since the submit/execute split in commit d55ac5bf ("drm/i915: Defer transfer onto execution timeline to actual hw submission") the global seqno advance was deferred until the submit_request callback. After wedging the GPU, we were installing a nop_submit_request handler (to avoid waking up the dead hw) but I had missed converting this over to the new scheme. Under the new scheme, we have to explicitly call i915_gem_submit_request() from the submit_request handler to mark the request as on the hardware. If we don't the request is always pending, and any waiter will continue to wait indefinitely and hangcheck will not be able to resolve the lockup. References: https://bugs.freedesktop.org/show_bug.cgi?id=98748 Testcase: igt/gem_eio/in-flight Fixes: d55ac5bf ("drm/i915: Defer transfer onto execution timeline to actual hw submission") Signed-off-by:
-
Chris Wilson authored
If the gpu reset fails and the machine is terminally wedged, further hangchecks achieve nothing but noise. Disable them, with a corollary that we re-enable hangchecking after a successful GPU reset in case the user is artificially bringing the machine back to life through the debug interface. Signed-off-by:
-
Chris Wilson authored
When a user context is closed, it's file_priv backpointer is replaced by ERR_PTR(-EBADF); be careful not to chase this invalid pointer after a hang and a GPU reset. Signed-off-by:
-
Robert Bragg authored
In particular this tries to capture for posterity some of the early challenges we had with using the core perf infrastructure in case we ever want to revisit adapting perf for device metrics. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Robert Bragg <robert@sixbynine.org> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
Sourab Gupta <sourab.gupta@intel.com> Signed-off-by:
-
Robert Bragg authored
This adds 'compute', 'compute extended', 'memory reads', 'memory writes' and 'sampler balance' metric sets for Haswell. The code is auto generated from an XML description of metric sets, currently maintained in gputop, ref: https://github.com/rib/gputop > gputop-data/oa-*.xml > scripts/i915-perf-kernelgen.py $ make -C gputop-data -f Makefile.xml Signed-off-by:
-
Robert Bragg authored
The maximum OA sampling frequency is now configurable via a dev.i915.oa_max_sample_rate sysctl parameter. Following the precedent set by perf's similar kernel.perf_event_max_sample_rate the default maximum rate is 100000Hz Signed-off-by:
-
Robert Bragg authored
Consistent with the kernel.perf_event_paranoid sysctl option that can allow non-root users to access system wide cpu metrics, this can optionally allow non-root users to access system wide OA counter metrics from Gen graphics hardware. Signed-off-by:
-
Robert Bragg authored
Each metric set is given a sysfs entry like: /sys/class/drm/card0/metrics/<guid>/id This allows userspace to enumerate the specific sets that are available for the current system. The 'id' file contains an unsigned integer that can be used to open the associated metric set via DRM_IOCTL_I915_PERF_OPEN. The <guid> is a globally unique ID for a specific OA unit register configuration that can be reliably used by userspace as a key to lookup corresponding counter meta data and normalization equations. The guid registry is currently maintained as part of gputop along with the XML metric set descriptions and code generation scripts, ref: https://github.com/rib/gputop > gputop-data/guids.xml > scripts/update-guids.py > gputop-data/oa-*.xml > scripts/i915-perf-kernelgen.py $ make -C gputop-data -f Makefile.xml SYSFS=1 WHITELIST=RenderBasic Signed-off-by:
-
Robert Bragg authored
Gen graphics hardware can be set up to periodically write snapshots of performance counters into a circular buffer via its Observation Architecture and this patch exposes that capability to userspace via the i915 perf interface. v2: Make sure to initialize ->specific_ctx_id when opening, without relying on _pin_notify hook, in case ctx already pinned. v3: Revert back to pinning ctx upfront when opening stream, removing need to hook in to pinning and to update OACONTROL on the fly. Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Robert Bragg authored
Adds a static OA unit, MUX + B Counter configuration for basic render metrics on Haswell. This is auto generated from an XML description of metric sets, currently maintained in gputop, ref: https://github.com/rib/gputop > gputop-data/oa-*.xml > scripts/i915-perf-kernelgen.py $ make -C gputop-data -f Makefile.xml SYSFS=0 WHITELIST=RenderBasic Signed-off-by:
-
Robert Bragg authored
Being able to program OACONTROL from a non-privileged batch buffer is not sufficient to be able to configure the OA unit. This was originally allowed to help enable Mesa to expose OA counters via the INTEL_performance_query extension, but the current implementation based on programming OACONTROL via a batch buffer isn't able to report useable data without a more complete OA unit configuration. Mesa handles the possibility that writes to OACONTROL may not be allowed and so only advertises the extension after explicitly testing that a write to OACONTROL succeeds. Based on this; removing OACONTROL from the whitelist should be ok for userspace. Removing this simplifies adding a new kernel api for configuring the OA unit without needing to consider the possibility that userspace might trample on OACONTROL state which we'd like to start managing within the kernel instead. In particular running any Mesa based GL application currently results in clearing OACONTROL when initializing which would disable the capturing of metrics. v2: This bumps the command parser version from 8 to 9, as the change is visible to userspace. Signed-off-by: -
Robert Bragg authored
check_cmd() is checking whether a command adheres to certain restrictions that ensure it's safe to execute within a privileged batch buffer. Returning false implies a privilege problem, not that the command is invalid. The distinction makes the difference between allowing the buffer to be executed as an unprivileged batch buffer or returning an EINVAL error to userspace without executing anything. In a case where userspace may want to test whether it can successfully write to a register that needs privileges the distinction may be important and an EINVAL error may be considered fatal. In particular this is currently true for Mesa, which includes a test for whether OACONTROL can be written too, but Mesa treats any error when flushing a batch buffer as fatal, calling exit(1). As it is currently Mesa can gracefully handle a failure to write to OACONTROL if the command parser is disabled, but if we were to remove OACONTROL from the parser's whitelist then the returned EINVAL would break Mesa applications as they attempt an OACONTROL write. This bumps the command parser version from 7 to 8, as the change is visible to userspace. Signed-off-by:
-
Robert Bragg authored
OACONTROL changes quite a bit for gen8, with some bits split out into a per-context OACTXCONTROL register. Rename now before adding more gen7 OA registers Signed-off-by:
-
Robert Bragg authored
Adds base i915 perf infrastructure for Gen performance metrics. This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64 properties to configure a stream of metrics and returns a new fd usable with standard VFS system calls including read() to read typed and sized records; ioctl() to enable or disable capture and poll() to wait for data. A stream is opened something like: uint64_t properties[] = { /* Single context sampling */ DRM_I915_PERF_PROP_CTX_HANDLE, ctx_handle, /* Include OA reports in samples */ DRM_I915_PERF_PROP_SAMPLE_OA, true, /* OA unit configuration */ DRM_I915_PERF_PROP_OA_METRICS_SET, metrics_set_id, DRM_I915_PERF_PROP_OA_FORMAT, report_format, DRM_I915_PERF_PROP_OA_EXPONENT, period_exponent, }; struct drm_i915_perf_open_param parm = { .flags = I915_PERF_FLAG_FD_CLOEXEC | I915_PERF_FLAG_FD_NONBLOCK | I915_PERF_FLAG_DISABLED, .properties_ptr = (uint64_t)properties, .num_properties = sizeof(properties) / 16, }; int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m); Records read all start with a common { type, size } header with DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records contain an extensible number of fields and it's the DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that determine what's included in every sample. No specific streams are supported yet so any attempt to open a stream will return an error. v2: use i915_gem_context_get() - Chris Wilson v3: update read() interface to avoid passing state struct - Chris Wilson fix some rebase fallout, with i915-perf init/deinit v4: s/DRM_IORW/DRM_IOW/ - Emil Velikov Signed-off-by:
-
- 21 Nov, 2016 9 commits
-
-
Mika Kuoppala authored
Bannable property, banned status, guilty and active counts are properties of i915_gem_context. Make them so. v2: rebase Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Mika Kuoppala authored
If we have a bad client submitting unfavourably across different contexts, creating new ones, the per context scoring of badness doesn't remove the root cause, the offending client. To counter, keep track of per client context bans. Deny access if client is responsible for more than 3 context bans in it's lifetime. v2: move ban check to context create ioctl (Chris) v3: add commentary about hangs needed to reach client ban (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Mika Kuoppala authored
Now when driver has per context scoring of 'hanging badness' and also subsequent hangs during short windows are allowed, if there is progress made in between, it does not make sense to expose a ban timing window as a context parameter anymore. Let the scoring be the sole indicator for ban policy and substitute ban period context parameter as a boolean to get/set context bannable property. v2: allow non root to opt into being banned (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Suggested-by:
-
Mika Kuoppala authored
As hangcheck score was removed, the active decay of score was removed also. This removed feature for hangcheck to detect if the gpu client was accidentally or maliciously causing intermittent hangs. Reinstate the scoring as a per context property, so that if one context starts to act unfavourably, ban it. v2: ban_period_secs as a gate to score check (Chris) v3: decay in proper spot. scores as tunables (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Mika Kuoppala authored
Hangcheck state accumulation has gained more steps along the years, like head movement and more recently the subunit inactivity check. As the subunit sampling is only done if the previous state check showed inactivity, we have added more stages (and time) to reach a hang verdict. Asymmetric engine states led to different actual weight of 'one hangcheck unit' and it was demonstrated in some hangs that due to difference in stages, simpler engines were accused falsely of a hang as their scoring was much more quicker to accumulate above the hang treshold. To completely decouple the hangcheck guilty score from the hangcheck period, convert hangcheck score to a rough period of inactivity measurement. As these are tracked as jiffies, they are meaningful also across reset boundaries. This makes finding a guilty engine more accurate across multi engine activity scenarios, especially across asymmetric engines. We lose the ability to detect cross batch malicious attempts to hinder the progress. Plan is to move this functionality to be part of context banning which is more natural fit, later in the series. v2: use time_before macros (Chris) reinstate the pardoning of moving engine after hc (Chris) v3: avoid global state for per engine stall detection (Chris) v4: take timeline last retirement into account (Chris) v5: do debug print on pardoning, split out retirement timestamp (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: -
Mika Kuoppala authored
In order to simplify hangcheck state keeping, split hangcheck per engine loop in three phases: state load, action, state save. Add few more hangcheck actions to separate between seqno, head and subunit movements. This helps to gather all the hangcheck actions under a single switch umbrella. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Mika Kuoppala authored
To find out what firmware we actually loaded (from dmesg) the explicit 'dmc' and 'firmware' are missing from the info printout. Add them. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
-
A.Sunil Kamath authored
Better to use num_scaler itself while printing scaler_info. This fixes a bug of printing information for the missing second scaler on pipe C for SKL platform. Signed-off-by:
A.Sunil Kamath <sunil.kamath@intel.com> Reviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1479664226-22307-1-git-send-email-sunil.kamath@intel.com
-
Chris Wilson authored
When unloading the module, it is expected that we have finished executing all requests and so the signal threads should be idle. Add a warning in case there are any residual requests in the signaler rbtrees at that point. v2: We can also warn if there are any waiters Signed-off-by:
-
