From: Tomas Elf <tomas.elf@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Intel-GFX@Lists.FreeDesktop.Org
Subject: Re: [RFC 02/11] drm/i915: Introduce uevent for full GPU reset.
Date: Tue, 16 Jun 2015 16:43:55 +0100 [thread overview]
Message-ID: <5580443B.8000206@intel.com> (raw)
In-Reply-To: <20150616134357.GV23637@phenom.ffwll.local>
On 16/06/2015 14:43, Daniel Vetter wrote:
> On Mon, Jun 08, 2015 at 06:03:20PM +0100, Tomas Elf wrote:
>> The TDR ULT used to validate this patch series requires a special uevent for
>> full GPU resets in order to distinguish between different kinds of resets.
>>
>> Signed-off-by: Tomas Elf <tomas.elf@intel.com>
>
> Why duplicate the uevent we send out from i915_reset_and_wakeup? At least
> I can't spot what this gets us in addition to the existing one.
> -Daniel
Look at this line:
>> + reset_event[0] = kasprintf(GFP_KERNEL, "%s", "GPU RESET=0");
It doesn't exist in reset_and_wakeup (specifically, the "GPU RESET=0"
part). It's a uevent that happens at the time of the actual GPU reset
(GDRST register write). In the subsequent TDR commit we add another one
to the point of the actual engine reset, which also includes information
about what exact engine was reset.
The uevents in reset_and_wakeup only tell the user that an error has
been detected and that some kind of reset has happened, these new
uevents specify exactly what kind of reset has happened. This particular
one on its own it's not very meaningful since there is only one
supported form of reset at this point but once we add engine reset
support it's useful to be able to discern the types of resets from each
other (GPU reset, RCS engine reset, VCS engine reset, VCS2 engine reset,
BCS engine reset, VECS engine reset).
Does that make sense?
Thanks,
Tomas
>
>> ---
>> drivers/gpu/drm/i915/intel_uncore.c | 29 ++++++++++++++++++++++-------
>> 1 file changed, 22 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
>> index d96d15f..770f526 100644
>> --- a/drivers/gpu/drm/i915/intel_uncore.c
>> +++ b/drivers/gpu/drm/i915/intel_uncore.c
>> @@ -1449,18 +1449,33 @@ static int gen6_do_reset(struct drm_device *dev)
>>
>> int intel_gpu_reset(struct drm_device *dev)
>> {
>> - if (INTEL_INFO(dev)->gen >= 6)
>> - return gen6_do_reset(dev);
>> + int ret = -ENODEV;
>> + int gen = INTEL_INFO(dev)->gen;
>> +
>> + if (gen >= 6)
>> + ret = gen6_do_reset(dev);
>> else if (IS_GEN5(dev))
>> - return ironlake_do_reset(dev);
>> + ret = ironlake_do_reset(dev);
>> else if (IS_G4X(dev))
>> - return g4x_do_reset(dev);
>> + ret = g4x_do_reset(dev);
>> else if (IS_G33(dev))
>> - return g33_do_reset(dev);
>> + ret = g33_do_reset(dev);
>> else if (INTEL_INFO(dev)->gen >= 3)
>> - return i915_do_reset(dev);
>> + ret = i915_do_reset(dev);
>> else
>> - return -ENODEV;
>> + WARN(1, "Full GPU reset not supported on gen %d\n", gen);
>> +
>> + if (!ret) {
>> + char *reset_event[2];
>> +
>> + reset_event[1] = NULL;
>> + reset_event[0] = kasprintf(GFP_KERNEL, "%s", "GPU RESET=0");
>> + kobject_uevent_env(&dev->primary->kdev->kobj,
>> + KOBJ_CHANGE, reset_event);
>> + kfree(reset_event[0]);
>> + }
>> +
>> + return ret;
>> }
>>
>> void intel_uncore_check_errors(struct drm_device *dev)
>> --
>> 1.7.9.5
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-06-16 15:43 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-08 17:03 [RFC 00/11] TDR/watchdog timeout support for gen8 Tomas Elf
2015-06-08 17:03 ` [RFC 01/11] drm/i915: Early exit from semaphore_waits_for for execlist mode Tomas Elf
2015-06-08 17:36 ` Chris Wilson
2015-06-09 11:02 ` Tomas Elf
2015-06-16 13:44 ` Daniel Vetter
2015-06-16 15:46 ` Tomas Elf
2015-06-16 16:50 ` Chris Wilson
2015-06-16 17:07 ` Tomas Elf
2015-06-17 11:43 ` Daniel Vetter
2015-06-08 17:03 ` [RFC 02/11] drm/i915: Introduce uevent for full GPU reset Tomas Elf
2015-06-16 13:43 ` Daniel Vetter
2015-06-16 15:43 ` Tomas Elf [this message]
2015-06-16 16:55 ` Chris Wilson
2015-06-16 17:32 ` Tomas Elf
2015-06-16 19:33 ` Chris Wilson
2015-06-17 11:49 ` Daniel Vetter
2015-06-17 12:51 ` Chris Wilson
2015-06-08 17:03 ` [RFC 03/11] drm/i915: Add reset stats entry point for per-engine reset Tomas Elf
2015-06-08 17:33 ` Chris Wilson
2015-06-09 11:06 ` Tomas Elf
2015-06-16 13:48 ` Daniel Vetter
2015-06-16 13:54 ` Chris Wilson
2015-06-16 15:55 ` Daniel Vetter
2015-06-18 11:12 ` Dave Gordon
2015-06-11 9:14 ` Dave Gordon
2015-06-16 13:49 ` Daniel Vetter
2015-06-16 15:54 ` Tomas Elf
2015-06-17 11:51 ` Daniel Vetter
2015-06-08 17:03 ` [RFC 04/11] drm/i915: Adding TDR / per-engine reset support for gen8 Tomas Elf
2015-06-08 17:03 ` [RFC 05/11] drm/i915: Extending i915_gem_check_wedge to check engine reset in progress Tomas Elf
2015-06-08 17:24 ` Chris Wilson
2015-06-09 11:08 ` Tomas Elf
2015-06-09 11:11 ` Chris Wilson
2015-06-08 17:03 ` [RFC 06/11] drm/i915: Disable warnings for TDR interruptions in the display driver Tomas Elf
2015-06-08 17:53 ` Chris Wilson
2015-06-08 17:03 ` [RFC 07/11] drm/i915: Reinstate hang recovery work queue Tomas Elf
2015-06-08 17:03 ` [RFC 08/11] drm/i915: Watchdog timeout support for gen8 Tomas Elf
2015-06-08 17:03 ` [RFC 09/11] drm/i915: Fake lost context interrupts through forced CSB check Tomas Elf
2015-06-08 17:03 ` [RFC 10/11] drm/i915: Debugfs interface for per-engine hang recovery Tomas Elf
2015-06-08 17:45 ` Chris Wilson
2015-06-09 11:18 ` Tomas Elf
2015-06-09 12:27 ` Chris Wilson
2015-06-09 17:28 ` Tomas Elf
2015-06-11 9:32 ` Dave Gordon
2015-06-08 17:03 ` [RFC 11/11] drm/i915: TDR/watchdog trace points Tomas Elf
2015-06-23 10:05 ` [RFC 00/11] TDR/watchdog timeout support for gen8 Daniel Vetter
2015-06-23 10:47 ` Tomas Elf
2015-06-23 11:38 ` Daniel Vetter
2015-06-23 14:06 ` Tomas Elf
2015-06-23 15:20 ` Daniel Vetter
2015-06-23 15:35 ` Daniel Vetter
2015-06-25 10:38 ` Tomas Elf
2015-07-03 11:15 ` Mika Kuoppala
2015-07-03 17:41 ` Tomas Elf
2015-07-09 18:47 ` Chris Wilson
2015-07-10 15:24 ` Tomas Elf
2015-07-10 15:48 ` Tomas Elf
2015-07-11 18:15 ` Chris Wilson
2015-07-11 18:22 ` Chris Wilson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5580443B.8000206@intel.com \
--to=tomas.elf@intel.com \
--cc=Intel-GFX@Lists.FreeDesktop.Org \
--cc=daniel@ffwll.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.