Quoting Michal Wajdeczko (2018-10-18 19:27:20)
> On Thu, 18 Oct 2018 20:18:53 +0200, Daniele Ceraolo Spurio
> wrote:
>
> >
> >
> > On 18/10/18 02:13, Chris Wilson wrote:
> >> Quoting Michal Wajdeczko (2018-10-18 00:22:43)
> >>> On Thu, 18 Oct 2018 01:09:19 +0200, Daniele Ceraolo Spurio
> >>> w
On Thu, 18 Oct 2018 20:18:53 +0200, Daniele Ceraolo Spurio
wrote:
On 18/10/18 02:13, Chris Wilson wrote:
Quoting Michal Wajdeczko (2018-10-18 00:22:43)
On Thu, 18 Oct 2018 01:09:19 +0200, Daniele Ceraolo Spurio
wrote:
On 17/10/18 13:29, Chris Wilson wrote:
Propagate the timeout on tr
On 18/10/18 02:13, Chris Wilson wrote:
Quoting Michal Wajdeczko (2018-10-18 00:22:43)
On Thu, 18 Oct 2018 01:09:19 +0200, Daniele Ceraolo Spurio
wrote:
On 17/10/18 13:29, Chris Wilson wrote:
Propagate the timeout on transferring the fw back to the caller where it
may act upon it, usually
Quoting Michal Wajdeczko (2018-10-18 00:22:43)
> On Thu, 18 Oct 2018 01:09:19 +0200, Daniele Ceraolo Spurio
> wrote:
>
> >
> >
> > On 17/10/18 13:29, Chris Wilson wrote:
> >> Propagate the timeout on transferring the fw back to the caller where it
> >> may act upon it, usually by restarting the
On Thu, 18 Oct 2018 01:09:19 +0200, Daniele Ceraolo Spurio
wrote:
On 17/10/18 13:29, Chris Wilson wrote:
Propagate the timeout on transferring the fw back to the caller where it
may act upon it, usually by restarting the xfer before failing.
Did you see any case where we failed the xfer
On 17/10/18 13:29, Chris Wilson wrote:
Propagate the timeout on transferring the fw back to the caller where it
may act upon it, usually by restarting the xfer before failing.
Did you see any case where we failed the xfer and didn't get a timeout
out of guc_wait_ucode? that'd be quite weird
Propagate the timeout on transferring the fw back to the caller where it
may act upon it, usually by restarting the xfer before failing.
Testcase: igt/drv_selftest/live_hangcheck
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/intel_guc_fw.c
