See https://lists.freedesktop.org/archives/intel-gfx/2018-October/178452.html
for RFC v1 and the helpful feedback incorporated into this v2.
The GuC firmware team is proposing a change to the firmware versioning scheme.
The goal is to more accurately track the firmware interface to help users
mana
On Thu, Oct 18, 2018 at 11:12:21AM -0700, Rodrigo Vivi wrote:
> On Thu, Oct 18, 2018 at 10:32:37AM -0700, Jeff McGee wrote:
> > On Thu, Oct 18, 2018 at 11:57:06AM +0200, Daniel Vetter wrote:
> > > On Fri, Oct 12, 2018 at 11:45 PM Jeff McGee wrote:
> > > >
> &g
On Thu, Oct 18, 2018 at 11:57:06AM +0200, Daniel Vetter wrote:
> On Fri, Oct 12, 2018 at 11:45 PM Jeff McGee wrote:
> >
> > On Fri, Oct 12, 2018 at 02:33:26PM -0700, Jeff McGee wrote:
> > > On Fri, Oct 12, 2018 at 01:51:46PM -0700, Rodrigo Vivi wrote:
> > > >
On Fri, Oct 12, 2018 at 02:33:26PM -0700, Jeff McGee wrote:
> On Fri, Oct 12, 2018 at 01:51:46PM -0700, Rodrigo Vivi wrote:
> > On Fri, Oct 12, 2018 at 01:24:30PM -0700, Jeff McGee wrote:
> > > The GuC firmware team is proposing a change to the firmware versioning
> > >
On Fri, Oct 12, 2018 at 01:51:46PM -0700, Rodrigo Vivi wrote:
> On Fri, Oct 12, 2018 at 01:24:30PM -0700, Jeff McGee wrote:
> > The GuC firmware team is proposing a change to the firmware versioning
> > scheme.
> > The goal is to more accurately track the firmware in
Forgot to add some people on CC.
On Fri, Oct 12, 2018 at 01:24:30PM -0700, Jeff McGee wrote:
> The GuC firmware team is proposing a change to the firmware versioning scheme.
> The goal is to more accurately track the firmware interface to help users
> manage dependencies on that inter
The GuC firmware team is proposing a change to the firmware versioning scheme.
The goal is to more accurately track the firmware interface to help users
manage dependencies on that interface. The proposed scheme is based on
semver.org with some additions to handle branching.
The proposed version n
On Thu, May 31, 2018 at 10:20:54PM +0100, Chris Wilson wrote:
> Quoting Singh, Satyeshwar (2018-05-31 22:17:25)
> > Hi Chris,
> > Isn't this dependent upon the workload submitted to the GuC? Meaning we
> > have one workload that refused to be preempted (really long shader for
> > example) but it
On Mon, Mar 26, 2018 at 12:50:41PM +0100, Chris Wilson wrote:
> Install a timer when trying to preempt on behalf of an important
> context such that if the active context does not honour the preemption
> request within the desired timeout, then we reset the GPU to allow the
> important context to r
On Tue, Mar 27, 2018 at 09:51:20AM +0100, Tvrtko Ursulin wrote:
>
> On 26/03/2018 12:50, Chris Wilson wrote:
> >Install a timer when trying to preempt on behalf of an important
> >context such that if the active context does not honour the preemption
> >request within the desired timeout, then we
gpu.
>
> Signed-off-by: Chris Wilson
> Cc: Michał Winiarski
> CC: Michel Thierry
> Cc: Jeff McGee
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 127
> +++
> 1 file changed, 87 insertions(+), 40 deletions(-)
>
> diff --git a/
+)
> > > @@ -1126,6 +1139,10 @@ int intel_hangcheck_live_selftests(struct
> > > drm_i915_private *i915)
> > >
> > > err = i915_subtests(tests, i915);
> > >
> > > + mutex_lock(&i915->drm.struct_mutex);
> > > + flush_test(i915, I915_WAIT_LOCKED);
> > > + mutex_unlock(&i915->drm.struct_mutex);
> > > +
> >
> > To wash out leftovers.
>
> Yeah, from the early abort we left requests unaccounted for and needed
> to grab the struct_mutex to run retire. Otherwise we hit assertions
> later on about trying to unload the driver with requests still inflight.
> -Chris
On this and the 3 others in this series...
Reviewed-by: Jeff McGee
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thu, Mar 22, 2018 at 05:41:57PM +, Tvrtko Ursulin wrote:
>
> On 22/03/2018 16:01, Jeff McGee wrote:
> >On Thu, Mar 22, 2018 at 03:57:49PM +, Tvrtko Ursulin wrote:
> >>
> >>On 22/03/2018 14:34, Jeff McGee wrote:
> >>>On Thu, Mar 22, 20
On Thu, Mar 22, 2018 at 03:57:49PM +, Tvrtko Ursulin wrote:
>
> On 22/03/2018 14:34, Jeff McGee wrote:
> >On Thu, Mar 22, 2018 at 09:28:00AM +, Chris Wilson wrote:
> >>Quoting Tvrtko Ursulin (2018-03-22 09:22:55)
> >>>
> >>>On 21/03/2018 17:26,
On Thu, Mar 22, 2018 at 03:35:19PM +, Chris Wilson wrote:
> Quoting Jeff McGee (2018-03-22 14:34:58)
> > On Thu, Mar 22, 2018 at 09:28:00AM +, Chris Wilson wrote:
> > > Quoting Tvrtko Ursulin (2018-03-22 09:22:55)
> > > >
> > > > On 21
the interrupt
> with reset, we need serialisation on the set_bit() itself.
>
> And at last Mika can be happy.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Michał Winiarski
> CC: Michel Thierry
> Cc: Jeff McGee
> Cc: Tvrtko Ursulin
> ---
> driv
to their own backend callbacks.
>
> Signed-off-by: Chris Wilson
> Cc: Michał Winiarski
> CC: Michel Thierry
> Cc: Jeff McGee
> ---
> drivers/gpu/drm/i915/intel_guc_submission.c | 39
> +
> drivers/gpu/drm/i915/intel_lrc.c| 11 +--
n
> Cc: Michał Winiarski
> CC: Michel Thierry
> Cc: Jeff McGee
> ---
> drivers/gpu/drm/i915/i915_gem.c | 42 --
> drivers/gpu/drm/i915/intel_lrc.c| 52
> +++--
> drivers/gpu/drm/i915/intel_ringbuffer.c | 2
y: Chris Wilson
> Cc: Jeff McGee
> Cc: Michał Winiarski
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 22 --
> 1 file changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index
On Tue, Mar 20, 2018 at 05:17:34PM -0700, Jeff McGee wrote:
> On Tue, Mar 20, 2018 at 12:18:48AM +, Chris Wilson wrote:
> > Catch up with the inflight CSB events, after disabling the tasklet
> > before deciding which request was truly guilty of hanging the GPU.
> >
>
On Thu, Mar 22, 2018 at 09:28:00AM +, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-03-22 09:22:55)
> >
> > On 21/03/2018 17:26, jeff.mc...@intel.com wrote:
> > > From: Jeff McGee
> > >
> > > Force preemption uses engine reset to enforc
On Wed, Mar 21, 2018 at 06:06:44PM +, Chris Wilson wrote:
> Quoting Jeff McGee (2018-03-21 17:33:04)
> > On Wed, Mar 21, 2018 at 10:26:23AM -0700, jeff.mc...@intel.com wrote:
> > > From: Jeff McGee
> > >
> > > Signed-off-by: Jeff McGee
> > > --
On Wed, Mar 21, 2018 at 10:26:23AM -0700, jeff.mc...@intel.com wrote:
> From: Jeff McGee
>
> Signed-off-by: Jeff McGee
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
On Wed, Mar 21, 2018 at 10:26:24AM -0700, jeff.mc...@intel.com wrote:
> From: Jeff McGee
>
> Engine reset is fast. A context switch interrupt may be generated just
> prior to the reset such that the top half handler is racing with reset
> post-processing. The handler may set the
: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
---
drivers/gpu/drm/i915/intel_guc_submission.c | 39 +
drivers/gpu/drm/i915/intel_lrc.c| 11 +---
2 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915
From: Jeff McGee
Force preemption uses engine reset to enforce a limit on the time
that a request targeted for preemption can block. This feature is
a requirement in automotive systems where the GPU may be shared by
clients of critically high priority and clients of low priority that
may not
From: Jeff McGee
The hardware can complete the requested preemption at only certain points
in execution. Thus an uncooperative request that avoids those points can
block a preemption indefinitely. Our only option to bound the preemption
latency is to trigger reset and recovery just as we would
/i915_reset_engine so that we include the
reason for the reset in the dev_notice(), superseding the earlier option
to not print that notice.
v3: Stash the reason inside the i915->gpu_error to handover to the direct
reset from the blocking waiter.
Signed-off-by: Chris Wilson
Cc: Jeff McGee
Cc: Mika Kuopp
From: Chris Wilson
As a complement to inject_preempt_context(), follow up with the function
to handle its completion. This will be useful should we wish to extend
the duties of the preempt-context for execlists.
Signed-off-by: Chris Wilson
Cc: Jeff McGee
Cc: Michał Winiarski
---
drivers/gpu
From: Chris Wilson
Catch up with the inflight CSB events, after disabling the tasklet
before deciding which request was truly guilty of hanging the GPU.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
---
drivers/gpu/drm/i915/intel_lrc.c | 355
From: Jeff McGee
Engine reset is fast. A context switch interrupt may be generated just
prior to the reset such that the top half handler is racing with reset
post-processing. The handler may set the irq_posted bit again after
the reset code has cleared it to start fresh. Then the re-enabled
From: Jeff McGee
Signed-off-by: Jeff McGee
---
drivers/gpu/drm/i915/intel_lrc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index beb81f13a3cc..cec4e1653daf 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
From: Chris Wilson
In preparation to more carefully handling incomplete preemption during
reset by execlists, we move the existing code wholesale to the backends
under a couple of new reset vfuncs.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
On Wed, Mar 21, 2018 at 04:42:32PM +, Chris Wilson wrote:
> Quoting Jeff McGee (2018-03-21 15:55:16)
> > On Wed, Mar 21, 2018 at 03:00:23PM +, Chris Wilson wrote:
> > > After resetting the GPU (or subset of engines), call synchronize_irq()
> > > to flush any pe
On Wed, Mar 21, 2018 at 03:00:23PM +, Chris Wilson wrote:
> After resetting the GPU (or subset of engines), call synchronize_irq()
> to flush any pending irq before proceeding with the cleanup. For a
> device level reset, we disable the interupts around the reset, but when
> resetting just one
On Tue, Mar 20, 2018 at 12:18:48AM +, Chris Wilson wrote:
> Catch up with the inflight CSB events, after disabling the tasklet
> before deciding which request was truly guilty of hanging the GPU.
>
> Signed-off-by: Chris Wilson
> Cc: Michał Winiarski
> CC: Michel Thierry
From: Jeff McGee
The current non-atomic wait_for routines convert the provided usec
timeout into jiffies with upward rounding. This can increase the
actual timeout several msecs which is fine in most cases. In the next
patch we need the timeout to conform more exactly to what is
requested.
This
From: Jeff McGee
Pull the reset handling out of i915_handle_error() so that it can be
called by that function and directly by the upcoming force preemption
handler. This allows the force preemption handler to bypass the error
capture that i915_handle_error() does before getting on with the
reset
From: Jeff McGee
Force preemption uses engine reset to enforce a limit on the time
that a request targeted for preemption can block. This feature is
a requirement in automotive systems where the GPU may be shared by
clients of critically high priority and clients of low priority that
may not
From: Jeff McGee
Engine reset is fast. A context switch interrupt may be generated just
prior to the reset such that the top half handler is racing with reset
post-processing. The handler may set the irq_posted bit again after
the reset code has cleared it to start fresh. Then the re-enabled
From: Jeff McGee
It is possible for the hardware to be reset just as a context is
completing. The reset post-processing may see the seqno update and
assume that the context escaped corruption, but the context may
have been disrupted in the save out process. The corruption may
screw up the HEAD
From: Jeff McGee
The active request is found by scanning the engine timeline for the
request that follows the last completed request. That method is accurate
if there is no preemption in progress, because the engine will certainly
have started that request. If there is a preemption in progress
From: Jeff McGee
The hardware can complete the requested preemption at only certain points
in execution. Thus an uncooperative request that avoids those points can
block a preemption indefinitely. Our only option to bound the preemption
latency is to trigger reset and recovery just as we would
From: Jeff McGee
In the next patch we are improving how we find the active request
on an engine with a pending preemption. We need to know if the
preemption has completed or not. This determination can be made
most robustly by having the preemption context write a preemption
finished indicator
From: Jeff McGee
It is possible for the preemption context to be active on an engine
when the engine is reset. The preemption context is not tracked via
the request mechanism, so the normal reset handling will not detect
this scenario and will not be able to fixup possible context
corruption. So
On Fri, Nov 10, 2017 at 06:14:17PM +, Chris Wilson wrote:
> Quoting Patchwork (2017-11-10 16:46:14)
> > == Series Details ==
> >
> > Series: series starting with [CI,1/8] drm/i915: Define an engine class enum
> > for the uABI
> > URL : https://patchwork.freedesktop.org/series/33606/
> > Sta
From: Jeff McGee
If GuC firmware performs an engine reset while that engine had a
preemption pending, it will set the terminated attribute bit on our
preemption stage descriptor. GuC firmware retains all pending work
items for a high-priority GuC client, unlike the normal-priority GuC
client
DRM_DEBUG_DRIVER("Failed to reset %s, ret=%d\n",
> > + DRM_DEBUG_DRIVER("%sFailed to reset %s, ret=%d\n",
> > +(engine->i915->guc.execbuf_client ? "GUC
> > ":""),
>
> A bit ove
On Wed, Oct 18, 2017 at 11:01:13AM +0200, Daniel Vetter wrote:
> On Tue, Oct 17, 2017 at 09:23:43AM -0700, Jeff McGee wrote:
> > On Tue, Oct 17, 2017 at 05:36:54PM +0200, Daniel Vetter wrote:
> > > On Tue, Oct 17, 2017 at 08:25:33AM -0700, jeff.mc...@intel.com wrote:
> &
From: Jeff McGee
Useful for stress testing various reset scenarios. The ioctl that we
have for specific client/context banning disable is difficult to utilize
outside of unit testing.
v2: Fix rebase compilation error
Signed-off-by: Jeff McGee
---
drivers/gpu/drm/i915/i915_debugfs.c | 27
On Tue, Oct 17, 2017 at 05:36:54PM +0200, Daniel Vetter wrote:
> On Tue, Oct 17, 2017 at 08:25:33AM -0700, jeff.mc...@intel.com wrote:
> > From: Jeff McGee
> >
> > Useful for stress testing various reset scenarios. The ioctl that we
> > have for specific client
From: Jeff McGee
Useful for stress testing various reset scenarios. The ioctl that we
have for specific client/context banning disable is difficult to utilize
outside of unit testing.
Signed-off-by: Jeff McGee
---
drivers/gpu/drm/i915/i915_debugfs.c | 25 +
drivers/gpu
liminate the entirely redundant and forgotten debugfs/i915_gem_request
>
> Signed-off-by: Chris Wilson
> Cc: Jeff McGee
> Cc: Mika Kuoppala
> ---
Reviewed-by: Jeff McGee
> drivers/gpu/drm/i915/i915_debugfs.c| 49
> --
> drivers
From: Jeff McGee
We are racing with updates to the timeline. This can cause an inconsistent
snapshot to be dumped, or even worse a NULL pointer dereference.
Signed-off-by: Jeff McGee
---
drivers/gpu/drm/i915/i915_debugfs.c | 27 ++-
1 file changed, 10 insertions(+), 17
From: Jeff McGee
Debugfs i915_gem_request lists the entire queue of requests on the
engine timeline. This will include requests that are complete but not
yet removed from the timeline. So let's include in this snapshot the
current seqno to help separate completed from pending.
Signed-o
; information, meaning that preemption has finished, and hardware is now
> idle.
>
> Cc: Chris Wilson
> Cc: Jeff Mcgee
> Cc: Michal Wajdeczko
> Cc: Oscar Mateo
> Signed-off-by: Michał Winiarski
Reviewed-by: Jeff McGee
_
tions operating on GuC work items.
> We can extract guc_request_add - responsible for adding GuC work item and
> ringing the doorbell, and guc_wq_item_append - used by the function
> above, not tied to the concept of gem request.
>
> Cc: Chris Wilson
> Cc: Jeff Mcgee
> Cc: Mich
On Thu, Oct 05, 2017 at 11:13:43AM +0200, Michał Winiarski wrote:
> From: Dave Gordon
>
> This second client is created with priority KMD_HIGH, and marked
> as preemptive. This will allow us to request preemption using GuC actions.
>
> Cc: Chris Wilson
> Cc: Jeff Mcgee
&
context to report its status.
> Let's update GuC firmware interface with those new definitions.
>
> Cc: Jeff Mcgee
> Cc: Michal Wajdeczko
> Cc: Oscar Mateo
> Signed-off-by: Michał Winiarski
Reviewed-by: Jeff McGee
On Wed, Sep 06, 2017 at 10:57:20PM +0100, Chris Wilson wrote:
> Quoting Jeff McGee (2017-08-29 18:01:47)
> > On Tue, Aug 29, 2017 at 04:17:46PM +0100, Chris Wilson wrote:
> > > Quoting Jeff McGee (2017-08-29 16:04:17)
> > > > On Tue, Aug 29, 2017 at 10:07:
On Tue, Aug 29, 2017 at 04:17:46PM +0100, Chris Wilson wrote:
> Quoting Jeff McGee (2017-08-29 16:04:17)
> > On Tue, Aug 29, 2017 at 10:07:18AM +0100, Chris Wilson wrote:
> > > Quoting Jeff McGee (2017-08-28 21:18:44)
> > > > On Mon, Aug 28, 2017 at 08:44:
On Tue, Aug 29, 2017 at 10:07:18AM +0100, Chris Wilson wrote:
> Quoting Jeff McGee (2017-08-28 21:18:44)
> > On Mon, Aug 28, 2017 at 08:44:48PM +0100, Chris Wilson wrote:
> > > Quoting jeff.mc...@intel.com (2017-08-28 20:25:30)
> > > > From: Jeff McGee
>
On Mon, Aug 28, 2017 at 08:44:48PM +0100, Chris Wilson wrote:
> Quoting jeff.mc...@intel.com (2017-08-28 20:25:30)
> > From: Jeff McGee
> >
> > If someone else is resetting the engine we should clear our own bit as
> > part of skipping that engine. Otherwise we will la
On Mon, Aug 28, 2017 at 12:41:58PM -0700, Michel Thierry wrote:
> On 28/08/17 12:25, jeff.mc...@intel.com wrote:
> >From: Jeff McGee
> >
> >If someone else is resetting the engine we should clear our own bit as
> >part of skipping that engine. Otherwise we will later
From: Jeff McGee
If someone else is resetting the engine we should clear our own bit as
part of skipping that engine. Otherwise we will later believe that it
has not been reset successfully and then trigger full gpu reset. If the
other guy's reset actually fails, he will trigger the ful
19 09:41:40 2017 +0100
> > > >
> > > > igt/pm_rps: Allow CUR to be greater than MAX (overclocking)
> > > >
> > > > Cc: Chris Wilson
> > > > Signed-off-by: Jeff McGee
> > > Reviewed-by: Radoslaw Szwichtenberg
> >
> > Pushed. Tha
From: Jeff McGee
This completes the change started by:
commit 39cccab83b7c515a2b57abe679a8cb304c8933ef
Author: Chris Wilson
Date: Fri May 19 09:41:40 2017 +0100
igt/pm_rps: Allow CUR to be greater than MAX (overclocking)
Cc: Chris Wilson
Signed-off-by: Jeff McGee
---
tests/pm_rps.c
On Tue, Apr 18, 2017 at 01:23:33PM -0700, Michel Thierry wrote:
> Final enablement patch for GPU hang detection using watchdog timeout.
> Using the gem_context_setparam ioctl, users can specify the desired
> timeout value in microseconds, and the driver will do the conversion to
> 'timestamps'.
>
>>
> >> Version 1.7 of the HuC firmware.
> >>
> >> v2: rebased.
> >> v3: rebased on top of drm-tip
> >>
> >> Cc: Jeff Mcgee
> >> Signed-off-by: Anusha Srivatsa
> >> Reviewed-by: Jeff McGee
> >> ---
> >>
Reviewed-by: Jeff McGee
On Mon, Dec 05, 2016 at 05:04:29PM +0100, Arkadiusz Hiler wrote:
> The firmware interface file was initially partially autogenerated, but
> this is no longer the case.
>
> It was never updated automatically, and a lot manual changes were
> introduced since
: rebased.
> v7: rebased.
> v8: rebased.
>
> Tested-by: Xiang Haihao
> Signed-off-by: Anusha Srivatsa
> Signed-off-by: Peter Antoine
> Reviewed-by: Rodrigo Vivi
> Reviewed-by: Jeff McGee
> ---
> drivers/gpu/drm/i915/i915_drv.c | 8
>
On Tue, Nov 15, 2016 at 10:06:47AM -0800, Srivatsa, Anusha wrote:
>
>
> >-Original Message-
> >From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
> >Sent: Tuesday, November 15, 2016 2:31 AM
> >To: Srivatsa, Anusha ; Mcgee, Jeff
> >
> >Cc: Ursulin, Tvrtko ;
> >intel-gfx@lists.fr
On Tue, Nov 15, 2016 at 10:26:46AM +, Tvrtko Ursulin wrote:
>
> On 15/11/2016 00:39, Anusha Srivatsa wrote:
> >From: Peter Antoine
> >
> >The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
> >is used for both cases.
> >
> >HuC loading needs to be before GuC loading. The WOPCM
that we had an option to just load GuC and do nothing with it.
Can those folks please comment?
Jeff
> Cc: Tvrtko Ursulin
> Cc: Jeff Mcgee
> Cc: Rodrigo Vivi
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/i915_guc_submission.c | 16 +---
>
Reviewed-by: Jeff McGee
On Thu, Nov 10, 2016 at 04:15:18PM -0800, Anusha Srivatsa wrote:
> This patch adds the support to load HuC on KBL
> Version 2.0
>
> Cc: Jeff Mcgee
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/intel_huc_loader.c | 15
Reviewed-by: Jeff McGee
On Thu, Nov 10, 2016 at 04:15:17PM -0800, Anusha Srivatsa wrote:
> This patch adds the HuC Loading for the BXT by using
> the updated file construction.
>
> Version 1.7 of the HuC firmware.
>
> Cc: Jeff Mcgee
> Signed-off-by: Anusha Srivatsa
>
On Fri, Nov 11, 2016 at 06:05:34PM -0800, Jeff McGee wrote:
> On Thu, Nov 10, 2016 at 04:15:16PM -0800, Anusha Srivatsa wrote:
> > From: Peter Antoine
> >
> > The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
> > is used for both cases.
> >
&
On Thu, Nov 10, 2016 at 04:15:16PM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
> is used for both cases.
>
> HuC loading needs to be before GuC loading. The WOPCM setting must
> be done early before loading any of the
ed.
>
> Signed-off-by: Anusha Srivatsa
> Signed-off-by: Alex Dai
> Signed-off-by: Peter Antoine
> Reviewed-by: Dave Gordon
> Reviewed-by: Jeff McGee
> Reviewed-by: Carlos Santa
> Tested-by: Carlos Santa
> ---
> drivers/gpu/drm/i915/i915_debugfs.c
er patch
is fixing an issue in an earlier patch. Just fix the original patch.
-Jeff
> v2: rebased.
> v3: rebased.
> changed file name to match the install package format.
> v7: rebased.
> v8: rebased.
> v10: rebased.
>
> Cc: Tvrtko Ursulin
> Cc: Jeff Mcgee
> Si
On Mon, Oct 31, 2016 at 03:24:53PM -0700, Anusha Srivatsa wrote:
> Update the file construction and specifying the required version
> similar to that of GuC.Add an extra field for the build number.
> Adopted the approach used in
> https://patchwork.freedesktop.org/patch/104355/
&
have not yet been made available
(I don't see them on 01.org).
In either case...
Reviewed-by: Jeff McGee
On Mon, Oct 31, 2016 at 10:06:27AM -0700, Rodrigo Vivi wrote:
> Could someone please ack this? We need this before getting HuC.
>
> GuC submission has regressions so the sub
Patch set header includes links to libva intent to use the interface. Thanks
Reviewed-by: Jeff McGee
On Fri, Oct 28, 2016 at 05:05:46PM -0700, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> This patch will allow for getparams to return the status of the HuC.
> As the HuC has to
On Fri, Oct 28, 2016 at 05:05:45PM -0700, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> This patch adds the HuC Loading for the BXT.
> Version 1.7 of the HuC firmware.
>
> v2: rebased.
> v3: rebased.
> changed file name to match the install package format.
> v7: rebased.
> v8: rebased.
>
Reviewed-by: Jeff McGee
On Fri, Oct 28, 2016 at 05:05:44PM -0700, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> The HuC authentication is done by host2guc call. The HuC RSA keys
> are sent to GuC for authentication.
>
> v2: rebased on top of drm-intel-nightly.
> ch
On Fri, Oct 28, 2016 at 05:05:42PM -0700, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
> is used for both cases.
>
> HuC loading needs to be before GuC loading. The WOPCM setting must
> be done early before loading any of the
Reviewed-by: Jeff McGee
On Fri, Oct 28, 2016 at 05:05:41PM -0700, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> HuC firmware css header has almost exactly same definition as GuC
> firmware except for the sw_version. Also, add a new member fw_type
> into intel_uc_fw to indica
On Mon, Oct 24, 2016 at 02:24:01PM -0700, Carlos Santa wrote:
> On Thu, 2016-10-13 at 13:54 -0700, Jeff McGee wrote:
> > On Thu, Oct 13, 2016 at 10:42:42AM -0700, Jeff McGee wrote:
> > >
> > > On Mon, Oct 03, 2016 at 11:42:57AM -0700, Anusha Srivatsa wrote:
> >
On Thu, Oct 13, 2016 at 08:45:45AM -0700, Jeff McGee wrote:
> On Mon, Oct 03, 2016 at 11:42:56AM -0700, Anusha Srivatsa wrote:
> > From: Peter Antoine
> >
> > HuC firmware css header has almost exactly same definition as GuC
> > firmware except for the sw_version. Als
On Mon, Oct 03, 2016 at 11:43:02AM -0700, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> This patch will allow for getparams to return the status of the HuC.
> As the HuC has to be validated by the GuC this patch uses the validated
> status to show when the HuC is loaded and ready for use. You
On Fri, Oct 07, 2016 at 09:11:03AM +0200, Daniel Vetter wrote:
> On Wed, Oct 05, 2016 at 01:51:14PM -0700, Rodrigo Vivi wrote:
> >
> >
> > Reviewed-by: Rodrigo Vivi
>
> This is new uabi. Where's the userspace?
>
> Checking this is part of the review.
> -Daniel
>
I'm not sure that GuC status i
On Mon, Oct 03, 2016 at 11:43:00AM -0700, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> This patch adds the HuC Loading for the BXT.
> Version 1.7 of the HuC firmware.
>
> v2: rebased.
> v3: rebased.
> changed file name to match the install package format.
> v7: rebased.
> v8: rebased.
>
On Mon, Oct 03, 2016 at 11:42:59AM -0700, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> The HuC authentication is done by host2guc call. The HuC RSA keys
> are sent to GuC for authentication.
>
> v2: rebased on top of drm-intel-nightly.
> changed name format and upped version 1.7.
> v3: r
On Thu, Oct 13, 2016 at 10:42:42AM -0700, Jeff McGee wrote:
> On Mon, Oct 03, 2016 at 11:42:57AM -0700, Anusha Srivatsa wrote:
> > From: Peter Antoine
> >
> > The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
> > is used for both cases.
> >
&
Reviewed-by: Jeff McGee
On Mon, Oct 03, 2016 at 11:42:58AM -0700, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> Add debugfs entry for HuC loading status check.
>
> v2: rebase on-top of drm-intel-nightly.
> v3: rebased again.
> v7: rebased.
> v8: rebased.
>
On Mon, Oct 03, 2016 at 11:42:57AM -0700, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
> is used for both cases.
>
> HuC loading needs to be before GuC loading. The WOPCM setting must
> be done early before loading any of the
On Mon, Oct 03, 2016 at 11:42:56AM -0700, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> HuC firmware css header has almost exactly same definition as GuC
> firmware except for the sw_version. Also, add a new member fw_type
> into intel_uc_fw to indicate what kind of fw it is. So, the loader
>
Reviewed-by: Jeff McGee
On Mon, Oct 03, 2016 at 11:42:55AM -0700, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> Rename some of the GuC fw loading code to make them more general. We
> will utilise them for HuC loading as well.
> s/intel_guc_fw/intel_uc_fw/g
>
> + ret= wa_ring_whitelist_reg(engine, GEN9_CTX_PREEMPT_REG);
> + if (ret)
> + return ret;
> +
> /* WaEnablePreemptionGranularityControlByUMD:skl,bxt */
> ret= wa_ring_whitelist_reg(engine, GEN8_CS_CHICKEN1);
> if (ret)
>
On Thu, Jan 21, 2016 at 06:11:01PM +, Peter Antoine wrote:
> This patch resizes the GuC WOPCM to so that the GuC and the RC6 memory
> spaces do not overlap.
>
> Issue: https://jira01.devtools.intel.com/browse/VIZ-6638
> Signed-off-by: Peter Antoine
> ---
> drivers/gpu/drm/i915/i915_guc_reg.h
1 - 100 of 243 matches
Mail list logo
