Re: [Intel-gfx] [PATCH 2/2] drm/i915: Allow disabling error capture

2016-10-13 Thread Chris Wilson 
On Thu, Oct 13, 2016 at 12:16:03PM +0300, Jani Nikula wrote:
> On Tue, 11 Oct 2016, Chris Wilson  wrote:
> > +#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
> > {"i915_error_state", _error_state_fops},
> > +#endif
> 
> IGT tests/drm_lib.sh tests for existence of i915_error_state to find the
> debugfs path for i915. Perhaps not the cleverest thing to do, but I
> wonder if there are others who depend on the existence of that file.

Ugh. The general non-singleton code forms the path from the stat.st_rdev.
Something to work towards.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Allow disabling error capture

2016-10-13 Thread Jani Nikula 
On Tue, 11 Oct 2016, Chris Wilson  wrote:
> +#if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
>   {"i915_error_state", _error_state_fops},
> +#endif

IGT tests/drm_lib.sh tests for existence of i915_error_state to find the
debugfs path for i915. Perhaps not the cleverest thing to do, but I
wonder if there are others who depend on the existence of that file.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915: Allow disabling error capture

2016-10-11 Thread Chris Wilson 
We currently capture the GPU state after we detect a hang. This is vital
for us to both triage and debug hangs in the wild (post-mortem
debugging). However, it comes at the cost of running some potentially
dangerous code (since it has to make very few assumption about the state
of the driver) that is quite resource intensive.

This patch introduces both a method to disable error capture at runtime
(for users who hit bugs at runtime and need a workaround) and to disable
error capture at compiletime (for realtime users who want to minimise
any possible latency, and never require error capture, saving ~30k of
code). The cost is that we know have to be wary of (and test!) a kconfig
flag and a module parameter. The effect of the module parameter is easy
to verify through code inspection and runtime testing, but a kconfig flag
needs regular compile checking.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
Acked-by: Jani Nikula 
Acked-by: Daniel Vetter