From: Alex Dai
There is a memory leak warning message from i915_gem_context_clean
when GuC submission is enabled. The reason is that when LRC is
released, its ppgtt could be still referenced. The assumption that
all VMAs are unbound during release of LRC is not true.
v1: Move the code inside i91
From: Alex Dai
When GuC Work Queue is full, driver will wait GuC for avaliable
space by calling wait_for_atomic. If irq is disabled, lockup will
happen because jiffies won't be updated.
Issue is found in igt/gem_close_race.
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915/i915_guc_submission.
From: Alex Dai
Can't immediately free LRC (neither unpin it) even all its
referenced requests are completed, because HW still need a short
period of time to save data to LRC status page. It is safe to free
LRC when HW completes a request from a different LRC.
Introduce a new function intel_lr_co
On 11/20/2015 12:31 AM, Daniel Vetter wrote:
On Thu, Nov 19, 2015 at 04:10:26PM -0800, yu@intel.com wrote:
> From: Alex Dai
>
> There is a memory leak warning message from i915_gem_context_clean
> when GuC submission is enabled. The reason is that when LRC is
> released, its ppgtt could be
On 11/23/2015 02:34 AM, Tvrtko Ursulin wrote:
On 20/11/15 08:31, Daniel Vetter wrote:
> On Thu, Nov 19, 2015 at 04:10:26PM -0800, yu@intel.com wrote:
>> From: Alex Dai
>>
>> There is a memory leak warning message from i915_gem_context_clean
>> when GuC submission is enabled. The reason is
From: Alex Dai
When GuC Work Queue is full, driver will wait GuC for avaliable
space by delaying 1ms. The wait needs to be out of spinlockirq /
unlock. Otherwise, lockup happens because jiffies won't be updated
dur to irq is disabled.
Issue is found in igt/gem_close_race.
Signed-off-by: Alex Da
On 11/24/2015 05:26 AM, Imre Deak wrote:
On ti, 2015-11-24 at 14:04 +0100, Daniel Vetter wrote:
> On Mon, Nov 23, 2015 at 03:02:58PM -0800, yu@intel.com wrote:
> > From: Alex Dai
> >
> > When GuC Work Queue is full, driver will wait GuC for avaliable
> > space by delaying 1ms. The wait nee
On 11/24/2015 10:08 AM, Daniel Vetter wrote:
On Tue, Nov 24, 2015 at 07:05:47PM +0200, Imre Deak wrote:
> On ti, 2015-11-24 at 09:00 -0800, Yu Dai wrote:
> >
> > On 11/24/2015 05:26 AM, Imre Deak wrote:
> > > On ti, 2015-11-24 at 14:04 +0100, Daniel Vetter wrote:
>
On 11/24/2015 11:13 AM, Daniel Vetter wrote:
On Tue, Nov 24, 2015 at 10:36:54AM -0800, Yu Dai wrote:
>
>
> On 11/24/2015 10:08 AM, Daniel Vetter wrote:
> >On Tue, Nov 24, 2015 at 07:05:47PM +0200, Imre Deak wrote:
> >> On ti, 2015-11-24 at 09:00 -0800, Yu Dai wrote:
>
On 11/24/2015 08:23 AM, Nick Hoath wrote:
Use the first retired request on a new context to unpin
the old context. This ensures that the hw context remains
bound until it has been saved.
Now that the context is pinned until later in the request/context
lifecycle, it no longer needs to be pinned
OK, here is my understanding. We do context pin/unpin during create/free
request or during submit/retire request but with condition (dirty)
check. So the context pincount will be # of requests plus 1, if it is
dirty. Dirty means that context likely is accessed by HW, while
not-dirty means HW is
From: Alex Dai
When GuC Work Queue is full, driver will wait GuC for avaliable
space by delaying 1ms. The wait needs to be out of spinlockirq /
unlock. Otherwise, lockup happens because jiffies won't be updated
dur to irq is disabled. The unnecessary locks has been cleared.
dev->struct_mutex is u
On 11/25/2015 07:02 AM, Mika Kuoppala wrote:
Nick Hoath writes:
> Use the first retired request on a new context to unpin
> the old context. This ensures that the hw context remains
> bound until it has been written back to by the GPU.
> Now that the context is pinned until later in the reque
From: Alex Dai
When GuC Work Queue is full, driver will wait GuC for avaliable
space by delaying 1ms. The wait needs to be out of spinlockirq /
unlock. Otherwise, lockup happens because jiffies won't be updated
due to irq is disabled. The unnecessary locks has been cleared.
dev->struct_mutex is u
From: Alex Dai
For now, remove the spinlocks that protected the GuC's
statistics block and work queue; they are only accessed
by code that already holds the global struct_mutex, and
so are redundant (until the big struct_mutex rewrite!).
The specific problem that the spinlocks caused was that
if
I tested this with GuC submission enabled and it fixes the issue I found
during GPU reset.
Reviewed-by: Alex Dai
On 12/01/2015 06:48 AM, Nick Hoath wrote:
Use the first retired request on a new context to unpin
the old context. This ensures that the hw context remains
bound until it has been
From: Alex Dai
Split GuC work queue space reserve and submission and move the space
reserve to where ring space is reserved. The reason is that failure
in intel_logical_ring_advance_and_submit won't be handled. In the
case timeout happens, driver can return early in order to handle the
error.
---
Reviewed-by: Alex Dai
On 12/07/2015 09:10 AM, Nick Hoath wrote:
Use the first retired request on a new context to unpin
the old context. This ensures that the hw context remains
bound until it has been written back to by the GPU.
Now that the context is pinned until later in the request/context
On 12/09/2015 01:05 AM, Chris Wilson wrote:
On Tue, Dec 08, 2015 at 05:04:50PM -0800, yu@intel.com wrote:
> From: Alex Dai
>
> Split GuC work queue space reserve and submission and move the space
> reserve to where ring space is reserved. The reason is that failure
> in intel_logical_ring_
From: Alex Dai
Split GuC work queue space reserve from submission and move it to
ring_alloc_request_extras. The reason is that failure in later
i915_add_request() won't be handled. In the case timeout happens,
driver can return early in order to handle the error.
v1: Move wq_reserve_space to rin
On 12/10/2015 09:14 AM, Dave Gordon wrote:
On 09/12/15 18:50, yu@intel.com wrote:
> From: Alex Dai
>
> Split GuC work queue space reserve from submission and move it to
> ring_alloc_request_extras. The reason is that failure in later
> i915_add_request() won't be handled. In the case timeo
From: Alex Dai
Split GuC work queue space checking from submission and move it to
ring_alloc_request_extras. The reason is that failure in later
i915_add_request() won't be handled. In the case timeout happens,
driver can return early in order to handle the error.
v1: Move wq_reserve_space to ri
From: Alex Dai
Split GuC work queue space checking from submission and move it to
ring_alloc_request_extras. The reason is that failure in later
i915_add_request() won't be handled. In the case timeout happens,
driver can return early in order to handle the error.
v1: Move wq_reserve_space to ri
From: Alex Dai
The GuC firmware uses this for various purposes. The ADS itself is a chunk of
memory created by driver to share with GuC. This series creates the GuC ADS
object and setup some basic settings for it.
Alex Dai (4):
drm/i915/guc: Add GuC ADS (Addition Data Structure) - allocation
From: Alex Dai
GuC supports different scheduling policies for its four internal
queues. Currently these have been set to the same default values
as KMD_NORMAL queue.
Particularly POLICY_MAX_NUM_WI is set to 15 to match GuC internal
maximum submit queue numbers to avoid an out-of-space problem.
T
From: Alex Dai
GuC needs to know which registers and how they will be saved and
restored during event such as engine reset or power state changes.
For now only the base address of reg state is initialized. The
detail register table probably will be setup in future GuC TDR or
Preemption patch seri
From: Alex Dai
The GuC firmware uses this for various purposes. The ADS itself is
a chunk of memory created by driver to share with GuC. Its members
are usually addresses telling where GuC to access them, including
things like scheduler policies, register list that will be saved
and restored duri
From: Dave Gordon
The GuC code needs to know the size of a logical context, so we
expose get_lr_context_size(), renaming it intel_lr_context__size()
to fit the naming conventions for nonstatic functions.
For: VIZ-2021
Signed-off-by: Dave Gordon
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915
From: Alex Dai
Set ADS enabling flag during GuC init.
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915/intel_guc_loader.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 4740949..625272f4 100644
From: Alex Dai
The device struct_mutex needs to be held before releasing any GEM
objects allocated by GuC.
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915/intel_guc_loader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/
On 12/16/2015 11:39 PM, Chris Wilson wrote:
On Wed, Dec 16, 2015 at 01:40:53PM -0800, yu@intel.com wrote:
> From: Alex Dai
>
> GuC supports different scheduling policies for its four internal
> queues. Currently these have been set to the same default values
> as KMD_NORMAL queue.
>
> Part
From: Alex Dai
The GuC firmware uses this for various purposes. The ADS itself is
a chunk of memory created by driver to share with GuC. Its members
are usually addresses telling where GuC to access them, including
things like scheduler policies, register list that will be saved
and restored duri
From: Alex Dai
GuC needs to know which registers and how they will be saved and
restored during event such as engine reset or power state changes.
For now only the base address of reg state is initialized. The
detail register table probably will be setup in future GuC TDR or
Preemption patch seri
From: Alex Dai
The GuC firmware uses this for various purposes. The ADS itself is a chunk of
memory created by driver to share with GuC. This series creates the GuC ADS
object and setup some basic settings for it.
This version addresses some comments from Chris W. Tidy up some code; replace
kmap
From: Alex Dai
GuC supports different scheduling policies for its four internal
queues. Currently these have been set to the same default values
as KMD_NORMAL queue.
Particularly POLICY_MAX_NUM_WI is set to 15 to match GuC internal
maximum submit queue numbers to avoid an out-of-space problem.
T
From: Alex Dai
Set ADS enabling flag during GuC init.
Signed-off-by: Alex Dai
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 4740949..625272f4 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader
From: Alex Dai
The GuC firmware uses this for various purposes. The ADS itself is
a chunk of memory created by driver to share with GuC. Its members
are usually addresses telling where GuC to access them, including
things like scheduler policies, register list that will be saved
and restored duri
From: Dave Gordon
The GuC code needs to know the size of a logical context, so we
expose get_lr_context_size(), renaming it intel_lr_context__size()
to fit the naming conventions for nonstatic functions.
For: VIZ-2021
Signed-off-by: Dave Gordon
Signed-off-by: Alex Dai
diff --git a/drivers/gpu
On 12/18/2015 01:55 AM, Jani Nikula wrote:
On Thu, 17 Dec 2015, yu@intel.com wrote:
> From: Alex Dai
>
> The device struct_mutex needs to be held before releasing any GEM
> objects allocated by GuC.
This is indeed so, but your patch subject needs to say it fixes an
actual bug rather than
From: Alex Dai
The device struct_mutex needs to be held before releasing any GEM
objects allocated by GuC.
WARNING: CPU: 0 PID: 1575 at include/drm/drm_gem.h:217
gem_release_guc_obj+0x5f/0x70 [i915]()
Call Trace:
[] dump_stack+0x44/0x60
[] warn_slowpath_common+0x82/0xc0
[
From: Alex Dai
This is to rework previous patch:
commit 9f9e539f90bcecfdc7b3679d337b7a62d4313205
Author: Daniel Vetter
Date: Fri Oct 23 11:10:59 2015 +0200
drm/i915: Shut up GuC errors when it's disabled
There is the case where GuC loading is needed even GuC submission
is disabled. For
From: Alex Dai
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
will pull right sw_version from header.
Signed-off-by: Alex Dai
Signed-off-by: P
From: Alex Dai
The current GuC loading helper functions have been utilized for HuC loading
too. The firmware css_header is unified for GuC and HuC. Be note that driver
init won't fail even HuC loading fails.
v2: Rebase to latest kernel.
Alex Dai (6):
drm/i915/guc: Make the GuC fw loading help
From: Alex Dai
Rename some of the GuC fw loading code to make them more general. We
will utilize them for HuC loading as well.
s/intel_guc_fw/intel_uc_fw/g
s/GUC_FIRMWARE/UC_FIRMWARE/g
Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
such as 'guc' or 'guc_fw' either
From: Alex Dai
Add debugfs entry for HuC loading status check.
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/i915/i915_debugfs.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/
From: Alex Dai
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 them.
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/i915
From: Alex Dai
The HuC authentication is done by host2guc call. The HuC RSA keys
are sent to GuC for authentication.
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/i915/i915_guc_submission.c | 65 ++
drivers/gpu/drm/i915/intel_guc_fwif.h
From: Alex Dai
The cached work queue header pointer is set to last byte of work
queue buffer. It will make sure the whole work queue buffer is
available after coming back from reset or init.
Do not hold kmap_atomic mapping before going to sleep when work
queue is full.
Signed-off-by: Alex Dai
On 02/10/2016 09:30 AM, Tvrtko Ursulin wrote:
Hi,
On 10/02/16 00:05, yu@intel.com wrote:
> From: Alex Dai
>
> The cached work queue header pointer is set to last byte of work
> queue buffer. It will make sure the whole work queue buffer is
> available after coming back from reset or init.
From: Alex Dai
GuC client object is always pinned during its life cycle. We cache
the kmap of its first page, which includes guc_process_desc and
doorbell. By doing so, we can simplify the code where we read from
this page to get where GuC is progressing on work queue; and the
code where driver p
On 02/15/2016 06:39 AM, Dave Gordon wrote:
On 12/02/16 13:03, Tvrtko Ursulin wrote:
>
> On 11/02/16 23:09, yu@intel.com wrote:
>> From: Alex Dai
>>
>> GuC client object is always pinned during its life cycle. We cache
>> the kmap of its first page, which includes guc_process_desc and
>> do
On 02/15/2016 07:23 AM, Dave Gordon wrote:
On 12/02/16 13:03, Tvrtko Ursulin wrote:
>
> On 11/02/16 23:09, yu@intel.com wrote:
>> From: Alex Dai
>>
>> GuC client object is always pinned during its life cycle. We cache
>> the kmap of its first page, which includes guc_process_desc and
>> do
On 02/17/2016 08:04 AM, Daniel Vetter wrote:
On Tue, Feb 16, 2016 at 08:47:07AM -0800, Yu Dai wrote:
>
>
> On 02/15/2016 07:23 AM, Dave Gordon wrote:
> >On 12/02/16 13:03, Tvrtko Ursulin wrote:
> >>
> >> On 11/02/16 23:09, yu@intel.com wrote:
> >&g
From: Alex Dai
There are several places inside driver where a GEM object is mapped to
kernel virtual space. The mapping is either done for the whole object
or certain page range of it.
This patch introduces a function i915_gem_object_vmap to do such job.
Signed-off-by: Alex Dai
Cc: Dave Gordon
From: Alex Dai
GuC client object is always pinned during its life cycle. We cache
the vmap of client object, which includes guc_process_desc, doorbell
and work queue. By doing so, we can simplify the code where driver
communicate with GuC.
As a result, this patch removes the kmap_atomic in wq_ch
From: Alex Dai
There are several places in driver that a GEM object is mapped to kernel
virtual space. Now add a common function i915_gem_object_vmap to do the vmap
work for such use case.
Alex Dai (2):
drm/i915: Add i915_gem_object_vmap to map GEM object to virtual space
drm/i915/guc: Simpl
From: Alex Dai
GuC client object is always pinned during its life cycle. We cache
the vmap of client object, which includes guc_process_desc, doorbell
and work queue. By doing so, we can simplify the code where driver
communicate with GuC.
As a result, this patch removes the kmap_atomic in wq_ch
From: Alex Dai
There are several places in driver that a GEM object is mapped to kernel
virtual space. Now add a common function i915_gem_object_vmap to do the vmap
work for such use case.
Alex Dai (2):
drm/i915: Add i915_gem_object_vmap to map GEM object to virtual space
drm/i915/guc: Simpl
From: Alex Dai
There are several places inside driver where a GEM object is mapped to
kernel virtual space. The mapping is either done for the whole object
or certain page range of it.
This patch introduces a function i915_gem_object_vmap to do such job.
v2: Use obj->pages->nents for iteration
On 02/18/2016 01:05 PM, Chris Wilson wrote:
On Thu, Feb 18, 2016 at 10:31:37AM -0800, yu@intel.com wrote:
> From: Alex Dai
>
> There are several places inside driver where a GEM object is mapped to
> kernel virtual space. The mapping is either done for the whole object
> or certain page ra
LGTM.
Reviewed-by: Alex Dai
Thanks,
Alex
On 02/03/2016 04:56 AM, Dave Gordon wrote:
Split the function of "enable_guc_submission" into two separate options.
The new one "enable_guc_loading" controls only the *fetching and loading*
of the GuC firmware image. The existing one is redefined to co
From: Alex Dai
This version of GuC firmware fixes the engine reset issue where golden
context LRC address is treated as page index by mistake. It also fixes
the problem that scheduler stops submiting to one engine when the other
engine work queue is full.
Signed-off-by: Alex Dai
---
drivers/gp
On 02/25/2016 06:59 AM, Dave Gordon wrote:
On 24/02/16 16:49, yu@intel.com wrote:
> From: Alex Dai
>
> This version of GuC firmware fixes the engine reset issue where golden
> context LRC address is treated as page index by mistake. It also fixes
> the problem that scheduler stops submitin
LGTM. Reviewed-by: Alex Dai
On 03/08/2016 03:38 AM, Arun Siluvery wrote:
Due to timing issues in the HW some of the status bits required for GuC
authentication doesn't get set occassionally, when that happens, GuC cannot
be initialized and we will be left with a wedged GPU. The WA suggested is
On 04/07/2016 10:21 AM, Dave Gordon wrote:
During a hibernate/resume cycle, the driver, the GuC, and the doorbell
hardware can end up in inconsistent states. This patch refactors the
driver's handling and tracking of doorbells, in preparation for a later
one which will resolve the issue.
Signe
From: Alex Dai
No need for this workaround since SKL C0 and BXT B0.
Issue: VIZ-7615
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915/intel_guc_loader.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/in
On 04/07/2016 10:21 AM, Dave Gordon wrote:
During a hibernate/resume cycle, the whole system is reset, including
the GuC and the doorbell hardware. Then the system is booted up, drivers
are loaded, etc -- the GuC firmware may be loaded and set running at this
point. But then, the booted kernel
LGTM.
Reviewed-by: Alex Dai
On 04/07/2016 10:21 AM, Dave Gordon wrote:
When resetting and reloading the GuC, the GuC submission management code
also needs to destroy and recreate the GuC client(s). Currently this is
done by a separate call from the GuC loader, but really, it's just an
internal
LGTM.
Reviewed-by: Alex Dai
On 04/07/2016 10:21 AM, Dave Gordon wrote:
To properly verify the driver->doorbell->GuC functionality, validation
needs to know how the driver has assigned the doorbell cache lines and
registers, so make them visible through debugfs.
Signed-off-by: Dave Gordon
---
LGTM.
Reviewed-by: Alex Dai
On 04/07/2016 10:21 AM, Dave Gordon wrote:
Just code movement, no actual change to the function. This is in
preparation for the next patch, which will reorganise all the other
doorbell code, but doesn't change this function. So let's shuffle it
down near its caller
On 04/13/2016 12:46 PM, Dave Gordon wrote:
On 13/04/16 18:50, Yu Dai wrote:
>
>
> On 04/07/2016 10:21 AM, Dave Gordon wrote:
>> During a hibernate/resume cycle, the whole system is reset, including
>> the GuC and the doorbell hardware. Then the system is booted up, drive
From: Alex Dai
The size / offset information of all firmware ingredients are
now caculated from header. Driver will validate the header and
rsa key size. If any component is out of boundary, driver will
reject the loading too.
v5: Tidy up GuC titles in kernel/Doc
v4: Now using 'size_dw' for tho
From: Alex Dai
There is a memory leak warning message from i915_gem_context_clean
when GuC submission is enabled. The reason is that the request (so
the LRC associated with it) is freed early than moving the vma list
to inactive. When retire a gem object, this patch moves its vma
list to inactive
From: Matt Roper
---
integration-manifest | 24
1 file changed, 24 insertions(+)
create mode 100644 integration-manifest
diff --git a/integration-manifest b/integration-manifest
new file mode 100644
index 000..a726d7c
--- /dev/null
+++ b/integration-manifest
@@ -0,
From: Alex Dai
The size / offset information of all firmware ingredients are
now caculated from header. Driver will validate the header and
rsa key size. If any component is out of boundary, driver will
reject the loading too.
v6: Clean up warnings from make docs
v5: Tidy up GuC titles in kerne
From: Alex Dai
There is a memory leak warning message from i915_gem_context_clean
when GuC submission is enabled. The reason is that gem_request (so
the LRC associated with it) is freed early than moving the vma list
to inactive.
We are not seeing this in ExecList (non-GuC) mode because the
gem_
On 11/03/2015 07:22 PM, Dave Airlie wrote:
On 4 November 2015 at 07:42, Daniel Stone wrote:
> The GuC firmware load requires struct_mutex to create a GEM object,
> but this collides badly with request_firmware. Move struct_mutex
> locking down into the loader itself, so we don't hold it across
On 10/29/2015 10:22 AM, Rodrigo Vivi wrote:
GuC has no version for KBL published yet and it is not recommended
to load the Skylake one, so let's avoid loading this for now while
we don't have the proper GuC firmware for Kabylake.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv
From: Alex Dai
Can't immediately free LRC context (neither unpin it) even all
its referenced requests are completed, because HW still need a
short period of time to save data to LRC status page. It is safe
to free LRC when HW completes a request from a different LRC.
Move LRC to ring->last_unpin
From: Alex Dai
We keep a copy of GuC fw in a GEM obj. However its content is lost
if the GEM obj is evicted (igt/gem_evict_*). Therefore, the later
fw loading during GPU reset will fail.
Now we keep the copy in a memory block rather than a GEM objet.
During fw loading, we will wrap up a GEM obj
From: Alex Dai
Can't immediately free LRC (neither unpin it) even all its
referenced requests are completed, because HW still need a short
period of time to save data to LRC status page. It is safe to free
LRC when HW completes a request from a different LRC.
Introduce a new function intel_lr_co
Sorry for wrong patch. Please forget about his one. Another one will be
submitted.
Alex
On 11/06/2015 01:56 PM, yu@intel.com wrote:
From: Alex Dai
Can't immediately free LRC context (neither unpin it) even all
its referenced requests are completed, because HW still need a
short period of
On 11/06/2015 02:07 PM, Chris Wilson wrote:
On Fri, Nov 06, 2015 at 01:55:27PM -0800, yu@intel.com wrote:
> From: Alex Dai
>
> We keep a copy of GuC fw in a GEM obj. However its content is lost
> if the GEM obj is evicted (igt/gem_evict_*). Therefore, the later
> fw loading during GPU rese
On 11/06/2015 02:09 PM, Chris Wilson wrote:
On Fri, Nov 06, 2015 at 01:56:59PM -0800, yu@intel.com wrote:
> From: Alex Dai
>
> Can't immediately free LRC context (neither unpin it) even all
> its referenced requests are completed, because HW still need a
> short period of time to save data
From: Alex Dai
We keep a copy of GuC fw in a GEM obj. However its content is lost
if the GEM obj is swapped (igt/gem_evict_*). Therefore, the later
fw loading during GPU reset will fail. Mark the obj dirty after
copying data into the pages. So its content will be kept during
swapped out.
Signed-
On 11/09/2015 02:15 AM, Chris Wilson wrote:
On Fri, Nov 06, 2015 at 03:18:37PM -0800, Yu Dai wrote:
>
>
> On 11/06/2015 02:07 PM, Chris Wilson wrote:
> >On Fri, Nov 06, 2015 at 01:55:27PM -0800, yu@intel.com wrote:
> >> From: Alex Dai
> >>
> >
On 11/11/2015 01:07 AM, Chris Wilson wrote:
On Tue, Nov 10, 2015 at 03:27:36PM -0800, yu@intel.com wrote:
> From: Alex Dai
>
> We keep a copy of GuC fw in a GEM obj. However its content is lost
> if the GEM obj is swapped (igt/gem_evict_*). Therefore, the later
> fw loading during GPU rese
From: Dave Gordon
The GuC code needs to know the size of a logical context, so we
expose get_lr_context_size(), renaming it intel_lr_context__size()
to fit the naming conventions for nonstatic functions.
Add comments or kerneldoc (Daniel Vetter)
For: VIZ-2021
Signed-off-by: Dave Gordon
Signed-
On 01/05/2016 02:27 AM, Daniel Vetter wrote:
On Fri, Dec 18, 2015 at 12:00:08PM -0800, yu@intel.com wrote:
> From: Dave Gordon
>
> The GuC code needs to know the size of a logical context, so we
> expose get_lr_context_size(), renaming it intel_lr_context__size()
> to fit the naming conven
From: Alex Dai
This is to enable command submission via GuC.
Signed-off-by: Dave Gordon
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params
From: Alex Dai
During driver unloading, the guc_client created for command submission
needs to be released to avoid memory leak.
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915/i915_guc_submission.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_guc_submissio
This has been reviewed internally. LGTM.
Reviewed-by: Alex Dai
On 01/05/2016 08:17 AM, Lukasz Fiedorowicz wrote:
Test check GuC debugfs file for successful loading confirmation
Signed-off-by: Lukasz Fiedorowicz
---
tests/Makefile.sources | 1 +
tests/gem_guc_loading.c | 89 +
Reviewed-by: Alex Dai
On 01/08/2016 07:03 AM, Peter Antoine wrote:
This commits adds the Broxton target to the GuC loader
Issue: https://jira01.devtools.intel.com/browse/VIZ-6638
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/i915/intel_guc_loader.c | 7 +++
1 file changed, 7 inserti
Reviewed-by: Alex Dai
On 01/08/2016 07:03 AM, 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
Reviewed-by: Alex Dai
On 01/08/2016 07:03 AM, Peter Antoine wrote:
Per-context initialisation GPU instructions (which are injected directly
into the ringbuffer rather than being submitted as a batch) should not
be allowed to mix with user-generated batches in the same submission; it
will cause
From: Alex Dai
Rename some of the GuC fw loading code to make them more general. We
will utilize them for HuC loading as well.
s/intel_guc_fw/intel_uc_fw/g
s/GUC_FIRMWARE/UC_FIRMWARE/g
Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
such as 'guc' or 'guc_fw' either
From: Alex Dai
This series of patches is to enable HuC firmware loading and authentication.
The GuC loader and css_header are unified for HuC loading.
Alex Dai (6):
drm/i915/guc: Make the GuC fw loading helper functions general
drm/i915/guc: Bypass fw loading gracefully if GuC is not support
From: Alex Dai
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 them.
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/i915
From: Alex Dai
This is to rework previous patch:
commit 9f9e539f90bcecfdc7b3679d337b7a62d4313205
Author: Daniel Vetter
Date: Fri Oct 23 11:10:59 2015 +0200
drm/i915: Shut up GuC errors when it's disabled
There is the case where GuC loading is needed even GuC submission
is disabled. For
From: Alex Dai
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
will pull right sw_version from header.
Signed-off-by: Alex Dai
Signed-off-by: P
1 - 100 of 266 matches
Mail list logo
