All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
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

  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.