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
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
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:
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
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
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 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
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 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
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
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
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
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
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
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 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
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
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/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
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/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
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
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
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 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
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
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
Previously GuC uses ring id as engine id because of same definition.
But this is not true since this commit:
commit de1add360522c876c25ef2ab1c94bdb509ab
Author: Tvrtko Ursulin
Date: Fri Jan 15 15:12:50 2016 +
drm/i915: Decouple execbuf uAPI from internal implementa
On 01/23/2016 10:25 AM, Chris Wilson wrote:
On Fri, Jan 22, 2016 at 03:06:28PM -0800, yu@intel.com wrote:
> From: Alex Dai
>
> Previously GuC uses ring id as engine id because of same definition.
> But this is not true since this commit:
>
> commit de1add360522c876c25ef2ab1c94bdb509ab
From: Alex Dai
Previously GuC uses ring id as engine id because of same definition.
But this is not true since this commit:
commit de1add360522c876c25ef2ab1c94bdb509ab
Author: Tvrtko Ursulin
Date: Fri Jan 15 15:12:50 2016 +
drm/i915: Decouple execbuf uAPI from internal implementa
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 | 3 ++-
drivers/gpu/
On 01/19/2016 01:25 PM, Daniel Vetter wrote:
On Tue, Jan 19, 2016 at 09:18:50PM +, Peter Antoine wrote:
> This reverts commit a92d3f32eafc57cca55e654ecfd916f283100365.
Shouldnt' this be patch 2/2? Enabling guc loading before it's fixed isn't
awesome.
Either way needs a proper commit messa
I am OK with change here. However, in i915_drv.h, please check
definition of HAS_GUC_UCODE() and HAS_GUC_SCHED(). I believe they are
disabled for KBL.
Thanks,
Alex
On 01/18/2016 06:41 AM, Peter Antoine wrote:
This patch added the loading of the GuC for Kabylake.
It loads a 2.4 firmware.
Sign
Thanks for capture the typo. LGTM.
Reviewed-by: Alex Dai
On 01/18/2016 07:59 AM, Arun Siluvery wrote:
In GuC submission mode, driver has to provide a list of registers to be
save/restored during gpu reset, make the max no. of registers value consistent
with that of the value defined in FW. If
This version resolved the issue (kernel bug check in
intel_lr_context_clean_ring) I reported on previous versions. Verified
by igt drv_module_reload_basic, gem_close_race and -t basic tests.
Reviewed-by: Alex Dai
On 01/13/2016 08:19 AM, Nick Hoath wrote:
Use the first retired request on a ne
From: Alex Dai
During driver unloading, the guc_client created for command submission
needs to be released to avoid memory leak.
The struct_mutex needs to be held before tearing down GuC.
v1: Move i915_guc_submission_disable out of i915_guc_submission_fini and
take struct_mutex lock before
On 01/13/2016 10:15 AM, Dave Gordon wrote:
On 12/01/16 23:17, yu@intel.com wrote:
> From: Alex Dai
>
> During driver unloading, the guc_client created for command submission
> needs to be released to avoid memory leak.
>
> The struct_mutex needs to be held before tearing down GuC.
>
> v1:
From: Alex Dai
During driver unloading, the guc_client created for command submission
needs to be released to avoid memory leak.
The struct_mutex needs to be held before tearing down GuC.
v1: Move i915_guc_submission_disable out of i915_guc_submission_fini and
take struct_mutex lock before
On 01/12/2016 04:11 AM, Dave Gordon wrote:
On 06/01/16 20:53, yu@intel.com wrote:
> 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_su
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 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
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 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 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
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
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
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:
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
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 +
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
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
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: 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-
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
[
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: 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
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 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
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
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
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
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 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/
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
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
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
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
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
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
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 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/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_
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
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.
---
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
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
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
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
dur to irq is disabled. The unnecessary locks has been cleared.
dev->struct_mutex is u
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
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
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 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 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
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/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
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
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
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
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
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
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
> >>
> >
1 - 100 of 266 matches
Mail list logo
