Re: [Intel-gfx] [PATCH v4 4/6] drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission

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

Re: [Intel-gfx] [PATCH v4 2/6] drm/i915/guc: move guc_ring_doorbell() nearer to callsite

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

Re: [Intel-gfx] [PATCH v4 1/6] drm/i915/guc: add doorbell map to debugfs/i915_guc_info

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.

Re: [Intel-gfx] [PATCH v4 5/6] drm/i915/guc: disable GuC submission earlier during GuC (re)load

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,

Re: [Intel-gfx] [PATCH v4 4/6] drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission

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

[Intel-gfx] [PATCH] drm/i915: Apply WaC6DisallowByGfxPause prior to SKL B0 / BXT A1

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

Re: [Intel-gfx] [PATCH v4 3/6] drm/i915/guc: refactor doorbell management code

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.

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/guc: Reset GuC and retry on firmware load failure

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.

[Intel-gfx] [PATCH] drm/i915/guc: Support GuC SKL v6.1

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

Re: [Intel-gfx] [PATCH] drm/i915: add enable_guc_loading parameter

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

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Add i915_gem_object_vmap to map GEM object to virtual space

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 >

[Intel-gfx] [PATCH v2 1/2] drm/i915: Add i915_gem_object_vmap to map GEM object to virtual space

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

[Intel-gfx] [PATCH v2 0/2] Add i915_gem_object_vmap

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

[Intel-gfx] [PATCH v2 2/2] drm/i915/guc: Simplify code by keeping vmap of guc_client object

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

[Intel-gfx] [PATCH 0/2] Add i915_gem_object_vmap

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

[Intel-gfx] [PATCH 2/2] drm/i915/guc: Simplify code by keeping vmap of guc_client object

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

[Intel-gfx] [PATCH 1/2] drm/i915: Add i915_gem_object_vmap to map GEM object to virtual space

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Simplify code by keeping kmap of guc_client object

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: >

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Simplify code by keeping kmap of guc_client object

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Simplify code by keeping kmap of guc_client object

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

[Intel-gfx] [PATCH 1/2] drm/i915/guc: Simplify code by keeping kmap of guc_client object

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Set init value for cached work queue head

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

[Intel-gfx] [PATCH] drm/i915/guc: Set init value for cached work queue head

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.

[Intel-gfx] [PATCH v2 3/6] drm/i915/huc: Unified css_header struct for GuC and HuC

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

[Intel-gfx] [PATCH v2 0/6] Add HuC loading and authentication support

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

[Intel-gfx] [PATCH v2 1/6] drm/i915/guc: Make the GuC fw loading helper functions general

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'

[Intel-gfx] [PATCH v2 5/6] drm/i915/huc: Add debugfs for HuC loading status check

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(+)

[Intel-gfx] [PATCH v2 2/6] drm/i915/guc: Bypass fw loading gracefully if GuC is not supported

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

[Intel-gfx] [PATCH v2 4/6] drm/i915/huc: Add HuC fw loading 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:

[Intel-gfx] [PATCH v2 6/6] drm/i915/huc: Support HuC authentication

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

[Intel-gfx] [PATCH v2] drm/i915/guc: Decouple GuC engine id from ring id

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:

Re: [Intel-gfx] [PATCH] drm/i915/guc: Decouple GuC engine id from ring id

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

[Intel-gfx] [PATCH] drm/i915/guc: Decouple GuC engine id from ring id

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:

Re: [Intel-gfx] [PATCH 1/2] Revert "FROM_UPSTREAM [VPG]: drm/i915/kbl: drm/i915: Avoid GuC loading for now on Kabylake."

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

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Correct max save/restore register count during gpu reset with GuC

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

Re: [Intel-gfx] [PATCH] i915/guc: Add Kabylake GuC Loading

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.

Re: [Intel-gfx] [PATCH 2/3] drm/i915: resize the GuC WOPCM for rc6

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

Re: [Intel-gfx] [PATCH v1] drm/i915/guc: Fix a memory leak where guc->execbuf_client is not freed

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

Re: [Intel-gfx] [PATCH v10] drm/i915: Extend LRC pinning to cover GPU context writeback

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

[Intel-gfx] [PATCH v2] drm/i915/guc: Fix a memory leak where guc->execbuf_client is not freed

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix a memory leak where guc->execbuf_client is not freed

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 > ---

[Intel-gfx] [PATCH v1] drm/i915/guc: Fix a memory leak where guc->execbuf_client is not freed

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

[Intel-gfx] [PATCH 1/6] drm/i915/guc: Make the GuC fw loading helper functions general

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'

[Intel-gfx] [PATCH 4/6] drm/i915/huc: Add HuC fw loading 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:

[Intel-gfx] [PATCH 2/6] drm/i915/guc: Bypass fw loading gracefully if GuC is not supported

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

[Intel-gfx] [PATCH 3/6] drm/i915/huc: Unified css_header struct for GuC and HuC

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

[Intel-gfx] [PATCH 5/6] drm/i915/huc: Add debugfs for HuC loading status check

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(+)

[Intel-gfx] [PATCH 6/6] drm/i915/huc: Support HuC authentication

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

[Intel-gfx] [PATCH 0/6] Support HuC loading and authentication

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Adding Broxton GuC Loader Support

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 ---

Re: [Intel-gfx] [PATCH 2/3] drm/i915: resize the GuC WOPCM for rc6

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Wait after context init with GuC Submission

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

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_guc_loading: Adding simple GuC loading test

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 |

[Intel-gfx] [PATCH] drm/i915/guc: Fix a memory leak where guc->execbuf_client is not freed

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

[Intel-gfx] [PATCH v3] drm/i915/guc: Expose (intel)_lr_context_size()

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

[Intel-gfx] [PATCH] drm/i915/guc: Enable GuC submission, where supported

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

Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/guc: Expose (intel)_lr_context_size()

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()

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix a warning message problem during driver unload

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

[Intel-gfx] [PATCH v1] drm/i915/guc: Fix a potential issue during driver unload

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 []

[Intel-gfx] [PATCH v2 4/5] drm/i915/guc: Add GuC ADS - MMIO reg state

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

[Intel-gfx] [PATCH v2 3/5] drm/i915/guc: Add GuC ADS - scheduler policies

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

[Intel-gfx] [PATCH v2 5/5] drm/i915/guc: Add GuC ADS - enabling ADS

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 +++

[Intel-gfx] [PATCH v2 2/5] drm/i915/guc: Add GuC ADS (Addition Data Structure) - allocation

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

[Intel-gfx] [PATCH v2 0/5] Add GuC ADS (Addition Data Structure)

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

[Intel-gfx] [PATCH v2 1/5] drm/i915/guc: Expose (intel)_lr_context_size()

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

Re: [Intel-gfx] [PATCH 3/5] drm/i915/guc: Add GuC ADS - scheduler policies

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

[Intel-gfx] [PATCH v1] drm/i915/guc: Add GuC ADS (Addition Data Structure) - allocation

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

[Intel-gfx] [PATCH v4] drm/i915/guc: Move GuC wq_check_space to alloc_request_extras

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

[Intel-gfx] [PATCH 3/5] drm/i915/guc: Add GuC ADS - scheduler policies

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

[Intel-gfx] [PATCH 0/5] Add GuC ADS (Addition Data Structure)

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

[Intel-gfx] [PATCH 4/5] drm/i915/guc: Add GuC ADS - MMIO reg state

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

[Intel-gfx] [PATCH 2/5] drm/i915/guc: Add GuC ADS (Addition Data Structure) - allocation

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

[Intel-gfx] [PATCH 1/5] drm/i915/guc: Expose (intel)_lr_context_size()

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

[Intel-gfx] [PATCH 5/5] drm/i915/guc: Add GuC ADS - enabling ADS

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

[Intel-gfx] [PATCH] drm/i915/guc: Fix a warning message problem during driver unload

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

[Intel-gfx] [PATCH v3] drm/i915/guc: Move GuC wq_check_space to alloc_request_extras

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

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Move GuC wq_reserve_space to alloc_request_extras

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

Re: [Intel-gfx] [PATCH v8] drm/i915: Extend LRC pinning to cover GPU context writeback

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

[Intel-gfx] [PATCH v2] drm/i915/guc: Move GuC wq_reserve_space to alloc_request_extras

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Move GuC wq_reserve_space to ring_reserve_space

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-gfx] [PATCH] drm/i915/guc: Move GuC wq_reserve_space to ring_reserve_space

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

[Intel-gfx] [PATCH v4] drm/i915/guc: Clean up locks in GuC

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

Re: [Intel-gfx] [PATCH] drm/i915: Extend LRC pinning to cover GPU context writeback

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

[Intel-gfx] [PATCH v3] drm/i915/guc: Clean up locks in GuC

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.

[Intel-gfx] [PATCH v2] drm/i915/guc: Clean up locks in GuC

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.

Re: [Intel-gfx] [PATCH] drm/i915: Change context lifecycle

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

Re: [Intel-gfx] [PATCH] drm/i915: Change context lifecycle

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Move wait for GuC out of spinlock/unlock

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: >

Re: [Intel-gfx] [PATCH] drm/i915: Change context lifecycle

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Move wait for GuC out of spinlock/unlock

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: >

Re: [Intel-gfx] [PATCH] drm/i915/guc: Move wait for GuC out of spinlock/unlock

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

[Intel-gfx] [PATCH] drm/i915/guc: Move wait for GuC out of spinlock/unlock

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.

Re: [Intel-gfx] [PATCH v1] drm/i915: Fix a false alert of memory leak when free LRC

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

Re: [Intel-gfx] [PATCH v1] drm/i915: Fix a false alert of memory leak when free LRC

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,

[Intel-gfx] [PATCH v1] drm/i915: Fix a false alert of memory leak when free LRC

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

[Intel-gfx] [PATCH] drm/i915/guc: Keep irq enabled during GuC cmd submission

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 ---

[Intel-gfx] [PATCH v1] drm/i915: Defer LRC unpin and release

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

Re: [Intel-gfx] [PATCH v1] drm/i915/guc: Fix a fw content lost issue after it is evicted

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix a fw content lost issue after it is evicted

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 <yu@intel.com> >

[Intel-gfx] [PATCH v1] drm/i915/guc: Fix a fw content lost issue after it is evicted

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

  1   2   3   >