Re: [Intel-gfx] [PATCH 1/3] drm/i915: Add ppgtt init/release trace points

] drm/i915: Add ppgtt init/release trace points On Wed, Jun 18, 2014 at 05:16:39PM +0100, oscar.ma...@intel.com wrote: From: Daniele Ceraolo Spurio daniele.ceraolospu...@intel.com These tracepoints are useful for observing the creation and destruction of Full PPGTTs. Signed

Re: [Intel-gfx] [PATCH i-g-t] benchmarks/Android.mk, tools/Android.mk: Fix android build error

On 04/08/15 09:56, Morton, Derek J wrote: Bump. Can this be merged? It only affects android and addresses an issue causing igt to fail to build at all on android. //Derek -Original Message- From: Morton, Derek J Sent: Monday, July 27, 2015 11:31 AM To:

Re: [Intel-gfx] [PATCH 2/2] drm/i915/lrc: Prevent preemption when lite-restore is disabled

tcase: igt/gem_concurrent_blit Reported-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> Signed-off-by: Michel Thierry <michel.thie...@intel.com> --- The lock-up I was seeing goes away with these 2 patches applied, so: Tested-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com&

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_exec_basic: don't use gem_require_ring to check ring availability

On 29/01/16 10:58, Chris Wilson wrote: On Fri, Jan 29, 2016 at 09:21:33AM +, daniele.ceraolospu...@intel.com wrote: From: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> gem_require_ring will submit an execbuf using the provided flags and skip the test if the ioctl

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_exec_basic: don't use gem_require_ring to check ring availability

On 29/01/16 11:35, Chris Wilson wrote: On Fri, Jan 29, 2016 at 11:16:37AM +, Daniele Ceraolo Spurio wrote: On 29/01/16 10:58, Chris Wilson wrote: On Fri, Jan 29, 2016 at 09:21:33AM +, daniele.ceraolospu...@intel.com wrote: From: Daniele Ceraolo Spurio <daniele.ceraolo

Re: [Intel-gfx] [PATCH v3] drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem

On 27/01/16 16:39, Ville Syrjälä wrote: On Wed, Jan 27, 2016 at 03:43:49PM +,daniele.ceraolospu...@intel.com wrote: From: Daniele Ceraolo Spurio<daniele.ceraolospu...@intel.com> While running some tests on the scheduler patches with rpm enabled I came across a corr

Re: [Intel-gfx] [PATCH i-g-t v2] tests/drv_hangman: test for acthd increasing through invalid VM space

On 25/02/16 11:32, Chris Wilson wrote: On Thu, Feb 25, 2016 at 11:12:06AM +, Daniele Ceraolo Spurio wrote: On 25/02/16 10:41, Chris Wilson wrote: On Thu, Feb 25, 2016 at 10:32:11AM +, daniele.ceraolospu...@intel.com wrote: +/* This test covers the case where we end up

Re: [Intel-gfx] [PATCH i-g-t v2] tests/drv_hangman: test for acthd increasing through invalid VM space

On 25/02/16 10:41, Chris Wilson wrote: On Thu, Feb 25, 2016 at 10:32:11AM +, daniele.ceraolospu...@intel.com wrote: +/* This test covers the case where we end up in an uninitialised area of the + * ppgtt at an offset greater than the one where the last buffer is mapped. This + * is

Re: [Intel-gfx] [RFC i-g-t] tests/drv_hangman: test for acthd increasing through invalid VM space

On 18/02/16 21:10, Chris Wilson wrote: On Thu, Feb 18, 2016 at 05:34:50PM +, daniele.ceraolospu...@intel.com wrote: +static void ppgtt_walking(void) +{ + memset(, 0, sizeof(execbuf)); + execbuf.buffers_ptr = (uintptr_t)_exec; + execbuf.buffer_count = 1; +

Re: [Intel-gfx] [RFC] drm/i915: check that rpm ref is held when writing to ringbuf in stolen mem

On 27/01/16 09:38, Chris Wilson wrote: On Wed, Jan 27, 2016 at 08:55:40AM +, daniele.ceraolospu...@intel.com wrote: From: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> While running some tests on the scheduler patches with rpm enabled I came across a corr

Re: [Intel-gfx] [PATCH i-g-t 1/4] lib/igt_bb_factory: Add igt_bb_factory library

On 12/02/16 09:38, Derek Morton wrote: Adds functions to create a number of different batch buffers to perform several functions including: Batch buffer which will run for a long duration to provide a delay on a specified ring. Function to calibrate the delay batch buffer to run for a

Re: [Intel-gfx] [PATCH i-g-t 2/4] tests/gem_scheduler: Add gem_scheduler test

Hi, first round of comments inline. A few things will probably have to change based on the comments on the previous patch in the series so I'll have a better look at the related logic once the new series is up. Regards, Daniele On 12/02/16 09:38, Derek Morton wrote: This is intended to

Re: [Intel-gfx] [PATCH i-g-t 3/4] igt/gem_ctx_param_basic: Updated to support scheduler priority interface

as valid and invalid priority values we could use the values returned by the debugfs forTEST_SUCCESS and the same values +/-1 for TEST_FAIL. The patch as it is still LGTM, so with or without my suggested change: Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@int

Re: [Intel-gfx] [PATCH i-g-t 4/4] tests/gem_scheduler: Add subtests to test batch priority behaviour

On 12/02/16 09:38, Derek Morton wrote: Add subtests to test each ring to check batch buffers of a higher priority will be executed before batch buffers of a lower priority. Signed-off-by: Derek Morton --- tests/gem_scheduler.c | 34

Re: [Intel-gfx] [PATCH i-g-t v3 3/6] tests/gem_scheduler: Add gem_scheduler test

buffers that have write dependencies are executed in submission order but the batch buffers without interdependencies do not get held up. v2: Addressed review comments from Daniele Ceraolo Spurio v3: Added logic to use generic BSD ring if there is 1 and BSD1 / BSD2 if there are 2. Signed-off

Re: [Intel-gfx] [PATCH i-g-t v3 1/6] ioctl_wrappers: make gem_has_ring non static

On 10/03/16 11:03, Derek Morton wrote: For tests that use multiple rings to test interactions it is useful to know if a ring exists without triggering the test to skip. Signed-off-by: Derek Morton --- lib/ioctl_wrappers.c | 2 +- lib/ioctl_wrappers.h | 1 + 2

Re: [Intel-gfx] [PATCH i-g-t v3 2/6] lib/intel_batchbuffer: Add functions to be used in the scheduler test

for a specified period of time. Function to create a batch buffer which writes timestamps to a buffer object. Function to compare timestamps allowing for wrapping of the values. v2: Moved code to intel_batchbuffer (Daniel Vetter) Addressed review comments from Daniele Ceraolo Spurio Signed-off-by: Derek

Re: [Intel-gfx] [PATCH i-g-t v3 5/6] tests/gem_scheduler: Add subtests to test batch priority behaviour

On 10/03/16 11:03, Derek Morton wrote: Add subtests to test each ring to check batch buffers of a higher priority will be executed before batch buffers of a lower priority. v2: Addressed review comments from Daniele Ceraolo Spurio Signed-off-by: Derek Morton <derek.j.mor...@intel.

Re: [Intel-gfx] [PATCH i-g-t v3 3/6] tests/gem_scheduler: Add gem_scheduler test

On 17/03/16 08:49, Daniele Ceraolo Spurio wrote: On 10/03/16 11:03, Derek Morton wrote: This is intended to test the scheduler behaviour is correct. The subtests are -basic Tests that batch buffers of the same priority submitted to a ring execute in the order they are submitted. -read

Re: [Intel-gfx] [PATCH] drm/i915: Add ppgtt->kunmap_page_dma vfunc

On 17/05/16 14:34, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Rather than asking itself "am I a Broadwell, am I a Cherryview, or am I neither of the two" on on low level page table operations, like inserting and clearing PTEs; add a new vfunc kunmap_page_dma and set

[Intel-gfx] [PATCH i-g-t] tests/gem_exec_params: add test for exec_fence params

Added a subtest for invalid FENCE_IN usage, updated invalid-flag subtest and made the rsvd2 test skip when exec fences are available. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> --- lib/ioctl_wrappers.c| 29 + lib/ioctl_wrap

[Intel-gfx] [PATCH v2] tests/gem_exec_params: add test for exec_fence params

Added a subtest for invalid FENCE_IN usage, updated invalid-flag subtest and made the rsvd2 test skip when exec fences are available. v2: add a test that tries to use the device fd as fence (Chris) Cc: Chris Wilson <ch...@chris-wilson.co.uk> Signed-off-by: Daniele Ceraolo

[Intel-gfx] [PATCH v2] drm/i915: fix pm refcounting on fence error in execbuf

;ch...@chris-wilson.co.uk> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/

[Intel-gfx] [PATCH] drm/i915: fix pm refcounting on fence error in execbuf

aniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index a40ade6..7f

[Intel-gfx] [PATCH] drm/i915: refactor register fw read/write macros for recent GENs

<tvrtko.ursu...@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> --- drivers/gpu/drm/i915/intel_uncore.c | 40 ++--- 1 file changed, 10 insertions(+), 30 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/dri

[Intel-gfx] [PATCH v2] drm/i915: reinstate call to trace_i915_vma_bind

nd one to track vma activity. Added inside the i915_vma_bind function (was outside before) to keep a similar placement as trace_i915_vma_unbind. v2: print bind_flags instead of flags (Chris) Cc: Chris Wilson <ch...@chris-wilson.co.uk> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolos

Re: [Intel-gfx] [PATCH] drm/i915: reinstate call to trace_i915_vma_bind

Ping. can anyone review/comment on this? Thanks, Daniele On 12/01/17 14:21, daniele.ceraolospu...@intel.com wrote: From: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> The call went away in: commit 3b16525cc4c1a43e9053cfdc414356eea24bdfad Author: Chris Wilson <ch

Re: [Intel-gfx] [PATCH] drm/i915: reinstate call to trace_i915_vma_bind

On 20/01/17 13:28, Chris Wilson wrote: On Fri, Jan 20, 2017 at 01:16:13PM -0800, Daniele Ceraolo Spurio wrote: Ping. can anyone review/comment on this? Thanks, Daniele On 12/01/17 14:21, daniele.ceraolospu...@intel.com wrote: From: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.

Re: [Intel-gfx] [PATCH v2] drm/i915: Sanitize GuC client initialization

<joonas.lahti...@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdec...@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hi...@intel.com> Cc: Oscar Mateo <oscar.ma...@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com> Cc: Chris Wilson <ch...@chris-wilson.

Re: [Intel-gfx] [PATCH] drm/i915/guc: Add onion teardown to the GuC setup

On 16/02/17 06:18, Oscar Mateo wrote: Starting with intel_guc_loader, down to intel_guc_submission and finally to intel_guc_log. Signed-off-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_guc_submission.c | 94 + drivers/gpu/drm/i915/intel_guc_loader.c| 19

Re: [Intel-gfx] [RFC 06/11] drm/i915/guc: Remove extra arguments from guc_client_alloc

On 23/02/17 08:38, Oscar Mateo wrote: On 02/23/2017 11:14 AM, Michał Winiarski wrote: We're always using all engines and kernel context for guc clients, let's remove those arguments from guc_client_alloc. I am quite new to the GuC but, by the look of it, passing the ctx was groundwork for

Re: [Intel-gfx] [RFC] drm/i915/guc: Smurf the GuC context

We could then have a "registration_id", "registration_pool", etc. Whatever name we decide to go with, if it differs from whatever is in the documentation I suggest to make sure that the relation is properly documented in the code to avoid confusion in the future. Cheer

Re: [Intel-gfx] [PATCH v2] drm/i915/bdw: Do not write the replay bit of the ring mode register

Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> On 24/02/17 11:15, Kelvin Gardiner wrote: The replay bit of the ring mode register is not a valid bit for Gen8+. Do not write to this bit. Signed-off-by: Kelvin Gardiner <kelvin.gardi...@intel.com> Cc: Joo

[Intel-gfx] [PATCH v2] drm/i915/guc: fix mmio whitelist mmio_start offset and add reminder

), move comment about save/restore because it is not related to the mmio_white_list field. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> Cc: Michał Winiarski <michal.winiar...@intel.com> Cc: Michal Wajdeczko <michal.wajdec...@intel.com> C

Re: [Intel-gfx] [PATCH i-g-t] tools/intel_guc_logger: Fix the assert for the verbosity level

Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> On 16/02/17 06:31, Oscar Mateo wrote: I guess no one has needed to change the verbosity level of the GuC logs. Signed-off-by: Oscar Mateo <oscar.ma...@intel.com> --- tools/intel_guc_logger.c | 2 +- 1 fil

Re: [Intel-gfx] [RFC/CI] drm/i915: Sanitize GuC client initialization

+ /* * Tell the GuC to allocate or deallocate a specific doorbell */ -static int guc_allocate_doorbell(struct intel_guc *guc, -struct i915_guc_client *client) +static int __create_doorbell_hw(struct i915_guc_client *client) I would rather prefer to only

Re: [Intel-gfx] [RFC/CI] drm/i915: Sanitize GuC client initialization

On 10/02/17 05:30, Joonas Lahtinen wrote: Started adding proper teardown to guc_client_alloc, ended up removing quite a few dead ends where errors communicating with the GuC were silently ignored. There also seemed to be quite a few erronous teardown actions performed in case of an error

Re: [Intel-gfx] [PATCH v2] drm/i915: Sanitize GuC client initialization

On 15/02/17 23:44, Chris Wilson wrote: On Wed, Feb 15, 2017 at 06:28:59PM -0800, Daniele Ceraolo Spurio wrote: On 14/02/17 05:53, Joonas Lahtinen wrote: -static void guc_disable_doorbell(struct intel_guc *guc, -struct i915_guc_client *client) +static int

Re: [Intel-gfx] [PATCH 3/5] drm/i915/guc: Simplify intel_guc_load()

On 15/12/16 07:47, Arkadiusz Hiler wrote: Current version of intel_guc_load() does a lot: - cares about submission - loads huc - implement WA This change offloads some of the logic to intel_uc_load(), which now cares about the above. Cc: Anusha Srivatsa Cc:

Re: [Intel-gfx] [PATCH 3/5] drm/i915/guc: Simplify intel_guc_load()

+ +fail: + /* +* We've failed to load the firmware :( +* +* Decide whether to disable GuC submission and fall back to +* execlist mode, and whether to hide the error by returning +* zero or to return -EIO, which the caller will treat as a +

Re: [Intel-gfx] [PATCH] drm/i915/guc: Make sure vma containing firmware is GuC mappable

to trigger this assert. Let's add a proper bias. Cc: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> Signed-off-by: Michał Winiarski <michal.winiar...@intel.com> --- drivers/gpu/drm/i915/intel_guc_loader.c | 3 ++- 1 file

Re: [Intel-gfx] [PATCH] drm/i915/guc: Reserve the upper end of the Global GTT for the GuC

On 21/12/16 06:11, Chris Wilson wrote: The GuC would like to own the upper portion of the GTT for itself, so exclude it from our drm_mm to prevent us using it. I had a quick chat with a GuC dev and he is pretty sure that GuC can't reserve any GTT areas for itself (and that is why we do the

Re: [Intel-gfx] [PATCH 4/5] drm/i915/guc: Extract param logic form guc_init

On 15/12/16 07:47, Arkadiusz Hiler wrote: Let intel_guc_init() focus on determining and fetching the correct firmware. This patch introduces intel_sanitize_uc_params() that is called from intel_uc_init(). Then, if we have GuC, we can call intel_guc_init() conditionally and we do not have to

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Exclude the upper end of the Global GTT for the GuC

at the bottom of the GGTT, and couple it into the assertion that we don't feed unmappable addresses to the GuC. Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdec...@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hi...@intel.com> Cc: Dani

Re: [Intel-gfx] [PATCH] drm/i915/guc: Reserve the upper end of the Global GTT for the GuC

On 22/12/16 08:38, Arkadiusz Hiler wrote: On Thu, Dec 22, 2016 at 03:18:08PM +, Chris Wilson wrote: On Thu, Dec 22, 2016 at 03:53:15PM +0100, Arkadiusz Hiler wrote: On Wed, Dec 21, 2016 at 07:35:04PM +0100, Srivatsa, Anusha wrote: With enable_guc_loading=2 and enable_guc_submission=0 I

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: request ring to be pinned above GUC_WOPCM_TOP

On 22/12/16 14:23, Patchwork wrote: == Series Details == Series: drm/i915: request ring to be pinned above GUC_WOPCM_TOP URL : https://patchwork.freedesktop.org/series/17147/ State : failure == Summary == Series 17147v1 drm/i915: request ring to be pinned above GUC_WOPCM_TOP

[Intel-gfx] [PATCH] drm/i915/guc: limit forcewake to blitter domain in guc_send

The forcewake_get call in the guc_send_mmio function was added to avoid getting and releasing forcewake on each register access. While this makes sense, all GuC registers are in the blitter range so no need to wake all the wells. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolo

Re: [Intel-gfx] [08/11] drm/i915/guc: Wait for doorbell to be inactive before deallocating

On 13/03/17 01:56, Oscar Mateo wrote: On 03/13/2017 04:46 AM, Chris Wilson wrote: On Fri, Mar 10, 2017 at 08:28:55AM -0800, Oscar Mateo wrote: Doorbell release flow requires that we wait for GEN8_DRB_VALID bit to go to zero after updating db_status before we call the GuC to release the

Re: [Intel-gfx] [PATCH 21/67] drm/i915/cnl: Update the context size

On 06/04/17 12:15, Rodrigo Vivi wrote: From: Ben Widawsky The docs are not yet correct, so I cannot provide a reference to it. In the current docs, the size is actually smaller than SKL. This seems unlikely given that in another part of the docs there are clearly

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Suspend GuC prior to GPU Reset during GEM suspend

to me: Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> On a related note, we only allocate the pages for saving the GuC state if i915.enable_guc_submission=1 (they're part of the ADS), but from what I can see we call intel_guc_suspend/resume unconditionally. Since t

Re: [Intel-gfx] [PATCH v5 12/18] drm/i915/guc: Provide register list to be saved/restored during engine reset

On 24/03/17 18:30, Michel Thierry wrote: From: Arun Siluvery GuC expects a list of registers from the driver which are saved/restored during engine reset. The type of value to be saved is controlled by flags. We provide a minimal set of registers that we want

Re: [Intel-gfx] [PATCH v6 13/20] drm/i915/guc: Provide register list to be saved/restored during engine reset

g them after internal GuC reset (Daniele). Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> Signed-off-by: Arun Siluvery <arun.siluv...@linux.intel.com> Signed-off-by: Jeff McGee <jeff.mc...@intel.com> Signed-off-by: Michel Thierry <michel.thie...@intel.com> @@

Re: [Intel-gfx] [PATCH v5 17/18] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout

On 24/03/17 18:30, Michel Thierry wrote: Final enablement patch for GPU hang detection using watchdog timeout. Using the gem_context_setparam ioctl, users can specify the desired timeout value in microseconds, and the driver will do the conversion to 'timestamps'. The recommended default

Re: [Intel-gfx] [PATCH v6 18/20] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout

On 18/04/17 13:23, Michel Thierry wrote: Final enablement patch for GPU hang detection using watchdog timeout. Using the gem_context_setparam ioctl, users can specify the desired timeout value in microseconds, and the driver will do the conversion to 'timestamps'. The recommended default

Re: [Intel-gfx] [PATCH v6 13/20] drm/i915/guc: Provide register list to be saved/restored during engine reset

On 21/04/17 13:07, Michel Thierry wrote: On 20/04/17 10:29, Michel Thierry wrote: On 20/04/17 09:39, Daniele Ceraolo Spurio wrote: On 20/04/17 04:33, Joonas Lahtinen wrote: On ke, 2017-04-19 at 11:35 -0700, Michel Thierry wrote: From: Arun Siluvery <arun.siluv...@linux.intel.

Re: [Intel-gfx] [06/11 v3] drm/i915/guc: Make intel_guc_send a function pointer

intel_uc_init_early back to the top (Michal). Signed-off-by: Michel Thierry <michel.thie...@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdec...@intel.com> Signed-off-by: Oscar Mateo <oscar.ma...@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.

Re: [Intel-gfx] [01/11 v3] drm/i915/guc: Sanitize GuC client initialization

s Lahtinen <joonas.lahti...@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdec...@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hi...@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com> Cc: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <da

Re: [Intel-gfx] [07/11] drm/i915/guc: Improve the GuC documentation & comments about proxy submissions

On 10/03/17 08:28, Oscar Mateo wrote: While at it, fix a typo (s/ring_lcra/ring_lrca) and improve the naming of one firware interface field (s/ring_tail/submit_element_info, since it can contain more than just the ring tail). No change in functionality. Signed-off-by: Oscar Mateo

[Intel-gfx] [PATCH] drm/i915/guc: write wopcm related register once during uc init

every time we try to load GuC. Cc: Jeff McGee <jeff.mc...@intel.com> Cc: Anusha Srivatsa <anusha.sriva...@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> --- drivers/gpu/drm/i915/intel_guc_loader.c | 4 drivers/gpu/drm/i915/inte

Re: [Intel-gfx] [PATCH v5 14/18] drm/i915: Watchdog timeout: Pass GuC shared data structure during param load

On 24/03/17 18:30, Michel Thierry wrote: For watchdog / media reset, the firmware must know the address of the shared data page (the first page of the default context). This information should be in DWORD 9 of the GUC_CTL structure. Signed-off-by: Michel Thierry

Re: [Intel-gfx] [PATCH v6 15/20] drm/i915: Watchdog timeout: Pass GuC shared data structure during param load

of the default ctx as we needed for suspend/resume/reset (Daniele). Cc: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> Signed-off-by: Michel Thierry <michel.thie...@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ce

Re: [Intel-gfx] [PATCH v6 13/20] drm/i915/guc: Provide register list to be saved/restored during engine reset

urrent value from RING_MODE reg instead; no need to preserve head/tail either, be extra paranoid and save whitelisted registers (Daniele). Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> Signed-off-by: Arun Siluvery <arun.siluv...@linux.intel.com> Signed-off-by: J

Re: [Intel-gfx] [PATCH v3 15/16] drm/i915/guc: Trace messages from CT while in debug

<michal.wajdec...@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> Cc: Chris Wilson <ch...@chris-wilson.co.uk> Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> -Daniele ___ Intel-gf

Re: [Intel-gfx] [RFC] drm/i915/lrc: allocate separate page for HWSP

On 06/07/17 11:51, Michel Thierry wrote: On 7/6/2017 10:59 AM, Chris Wilson wrote: > If there are no conflicts, then just skip the patch, and really there > shouldn't be since the writes we care about are ordered and the writes > we don't, we don't. We will need to move to per-context hwsp

Re: [Intel-gfx] [PATCH 3/3] drm/i915/execlists: Read the context-status HEAD from the HWSP

On 12/07/17 15:58, Chris Wilson wrote: The engine provides also provides mirror of the CSB write pointer in the HWSP, but not of our read pointer. To take advantage of this we need to remember where we read up to on the last interrupt and continue off from there. This poses a problem following

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Don't make assumptions while getting the lrca offset

the new macros to prevent abusive overuse of the old ones (Chris). Reported-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> Signed-off-by: Michel Thierry <michel.thie...@intel.com> Cc: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ce

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Gen10 render context size.

Hi, I'm a bit late to the party, but as I already mentioned at [1] the CNL render ctx size is smaller than the gen9 one according to the specs. The ctx format in the specs contains 16752 dwords, i.e. 17 pages, to which we need to add 1 page for the PPHWSP, so 18 pages total. If we re-use the

[Intel-gfx] [RFC] drm/i915/lrc: allocate separate page for HWSP

below 0x30 in an area we don't access, but that is not guaranteed to be true for future platform. To avoid the conflict, instead of re-using the PPHWSP of the kernel ctx we can allocate a separate page for the HWSP like what happens for pre-execlists platform. Signed-off-by: Daniele Ceraolo Spurio

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Pre-calculate engine context size

On 26/04/17 02:57, Zhi Wang wrote: Uh...sorry for not mentioning that before:), and stolen memory is not my business. :( Actually we root-caused it. This is how we found this case: The story is W driver directly allocated the ring buffer after the context image, and the context image size

Re: [Intel-gfx] [PATCH] drm/i915/guc: Enable send function only after successful init

gt; Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> ___ Intel-gfx mailing list Intel-gfx@lis

Re: [Intel-gfx] [PATCH 01/15] drm/i915/guc: Add support for data reporting in GuC responses

Wajdeczko <michal.wajdec...@intel.com> Cc: Oscar Mateo <oscar.ma...@intel.com> Cc: Michel Thierry <michel.thie...@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> --- drivers/gpu/drm/i915/intel_guc_ct.c | 14 +++--- drivers/gpu/drm/i9

Re: [Intel-gfx] [PATCH v2 15/16] drm/i915/guc: Trace messages from CT while in debug

On 07/08/17 09:14, Michal Wajdeczko wrote: During debug we may want to investigate all communication from the Guc. Add proper tracing macros in debug config. v2: convert remaining DRM_DEBUG into new CT_DEBUG (Michal) Signed-off-by: Michal Wajdeczko ---

Re: [Intel-gfx] [PATCH v2 08/16] drm/i915/guc: Update CT message header definition

On 07/08/17 09:14, Michal Wajdeczko wrote: Flags bits are different in G2H message. Signed-off-by: Michal Wajdeczko <michal.wajdec...@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> Cc: Oscar Mateo <oscar.ma...@intel.com> Cc: Kelvin Gardiner <kelv

Re: [Intel-gfx] [PATCH v3] drm/i915/guc: capture GuC logs if FW fails to load

On 05/05/17 16:23, Daniele Ceraolo Spurio wrote: We're currently deleting the GuC logs if the FW fails to load, but those are still useful to understand why the loading failed. Keeping the object around allows us to access them after driver load is completed. v2: keep the object around

[Intel-gfx] [PATCH v4] drm/i915/guc: capture GuC logs if FW fails to load

eo <oscar.ma...@intel.com> Cc: Michal Wajdeczko <michal.wajdec...@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> --- drivers/gpu/drm/i915/i915_debugfs.c | 35 ++- drivers/gpu/drm/i915/i915_drv.c | 3 +++ driver

Re: [Intel-gfx] [PATCH v4] drm/i915/guc: capture GuC logs if FW fails to load

On 15/05/17 10:41, Michal Wajdeczko wrote: On Mon, May 15, 2017 at 09:35:30AM -0700, Daniele Ceraolo Spurio wrote: We're currently deleting the GuC logs if the FW fails to load, but those are still useful to understand why the loading failed. Keeping the object around allows us to access them

[Intel-gfx] [PATCH v6] drm/i915/guc: capture GuC logs if FW fails to load

to intel_guc, move functions to intel_uc.c, don't clear obj on new GuC load, free object only if enable_guc_loading is set (Michal) Cc: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Oscar Mateo <oscar.ma...@intel.com> Cc: Michal Wajdeczko <michal.wajdec...@intel.com> Signed-off-b

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/guc: capture GuC logs if FW fails to load (rev6)

On 22/05/17 11:21, Patchwork wrote: == Series Details == Series: drm/i915/guc: capture GuC logs if FW fails to load (rev6) URL : https://patchwork.freedesktop.org/series/23982/ State : warning == Summary == Series 23982v6 drm/i915/guc: capture GuC logs if FW fails to load

Re: [Intel-gfx] [PATCH v3 3/8] drm/i915/guc: Submit GuC workitems containing coalesced requests

son.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> Cc: Jeff McGee <jeff.mc...@intel.com> Cc: Michal Wajdeczko <michal.wajdec...@intel.com> Cc: Oscar Mateo <oscar.ma...@intel.com> Signed-off-by: Michał Winiarski <michal.winiar...@intel.com> --- d

Re: [Intel-gfx] [CI v2 2/2] drm/i915/guc: Introduce buffer based cmd transport

bert.beck...@intel.com> Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> v2: use gem_object_pin_map (Chris) don't use DEBUG_RATELIMITED (Chris) don't track action stats (Chris) simplify next fence (Chris) use READ_ONCE (Chris) move blob allocation to new functi

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/guc: Introduce buffer based cmd transport

+ +static int ctch_init(struct intel_guc *guc, +struct intel_guc_ct_channel *ctch) +{ + struct i915_vma *vma; + void *blob; + int err; + int i; + + GEM_BUG_ON(ctch->vma); + + /* We allocate 1 page to hold both descriptors and both

Re: [Intel-gfx] [PATCH v6] drm/i915/guc: capture GuC logs if FW fails to load

On 22/05/17 12:56, Michal Wajdeczko wrote: On Mon, May 22, 2017 at 10:50:28AM -0700, Daniele Ceraolo Spurio wrote: We're currently deleting the GuC logs if the FW fails to load, but those are still useful to understand why the loading failed. Keeping the object around allows us to access them

Re: [Intel-gfx] [PATCH v5] drm/i915/guc: capture GuC logs if FW fails to load

On 18/05/17 10:08, Michal Wajdeczko wrote: On Tue, May 16, 2017 at 02:52:53PM -0700, Daniele Ceraolo Spurio wrote: We're currently deleting the GuC logs if the FW fails to load, but those are still useful to understand why the loading failed. Keeping the object around allows us to access them

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/guc: Submit GuC workitems containing coalesced requests

ports. We also need to stop pretending that we're doing "lite-restore" in GuC submission (we would create a workitem each time we hit this condition). v2: Also coalesce when replaying on reset (Daniele) Cc: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <

Re: [Intel-gfx] [PATCH 3/6] drm/i915/guc: Remove GuC wq reservation

static void nested_enable_signaling(struct drm_i915_gem_request *rq) @@ -1223,6 +1155,9 @@ int i915_guc_submission_enable(struct drm_i915_private *dev_priv) enum intel_engine_id id; int err; + BUILD_BUG_ON(ARRAY_SIZE(engine->execlist_port) * +

[Intel-gfx] [PATCH v5] drm/i915/guc: capture GuC logs if FW fails to load

;ch...@chris-wilson.co.uk> Cc: Oscar Mateo <oscar.ma...@intel.com> Cc: Michal Wajdeczko <michal.wajdec...@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> --- drivers/gpu/drm/i915/i915_debugfs.c | 38 +++---

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix doorbell id selection

c: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> Cc: Oscar Mateo <oscar.ma...@intel.com> Signed-off-by: Michel Thierry <michel.thie...@intel.com> --- Reviewed-by: Daniele Ceraolo Spurio <daniele.cera

Re: [Intel-gfx] [PATCH] drm/i915/guc: Clear enable_guc_loading in case of init failure

You'll also need to change the order of operations in intel_uc_fini_hw to make sure guc_free_load_err_log is called before the i915.enable_guc_loading check, because that log exists exactly when GuC loading failed. Thanks, Daniele On 02/06/17 16:46, Michel Thierry wrote: And prevent calling

Re: [Intel-gfx] [RFC] drm/i915/guc: capture GuC logs if FW fails to load

On 04/05/17 14:26, Srivatsa, Anusha wrote: -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Daniele Ceraolo Spurio Sent: Thursday, May 4, 2017 11:52 AM To: intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] [RFC] drm/i915/guc

Re: [Intel-gfx] [RFC] drm/i915/guc: capture GuC logs if FW fails to load

On 04/05/17 14:31, Chris Wilson wrote: On Thu, May 04, 2017 at 09:26:35PM +, Srivatsa, Anusha wrote: +void i915_guc_load_error_log_capture(struct drm_i915_private *i915) { + void *log, *buf; + struct i915_vma *vma = i915->guc.log.vma; + + if

[Intel-gfx] [PATCH v2] drm/i915/guc: capture GuC logs if FW fails to load

the logs in the gpu_error struct (Chris) add a check on guc_log_level to avoid snapshotting empty logs Cc: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Oscar Mateo <oscar.ma...@intel.com> Cc: Michal Wajdeczko <michal.wajdec...@intel.com> Signed-off-by: Daniele Ceraolo Spurio &

[Intel-gfx] [PATCH v3] drm/i915/guc: capture GuC logs if FW fails to load

com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> --- drivers/gpu/drm/i915/i915_debugfs.c | 35 ++- drivers/gpu/drm/i915/i915_drv.c | 3 +++ drivers/gpu/drm/i915/intel_guc_log.c | 17 + drivers/gpu/drm/i

Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: Move notification code into virtual function

On 02/05/17 05:39, Michal Wajdeczko wrote: Prepare for alternate GuC notification mechanism. Signed-off-by: Michal Wajdeczko <michal.wajdec...@intel.com> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> --

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Make scratch register base and count flexible

eraolo Spurio <daniele.ceraolospu...@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> --- drivers/gpu/drm/i915/intel_uc.c | 42 + drivers/gpu/drm/i915/intel_uc

[Intel-gfx] [RFC] drm/i915/guc: capture GuC logs if FW fails to load

deczko <michal.wajdec...@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> --- drivers/gpu/drm/i915/i915_debugfs.c | 36 --- drivers/gpu/drm/i915/i915_drv.c | 3 +++ drivers/gpu/drm/i915/i915_drv.h | 6 ++ dr

Re: [Intel-gfx] [PATCH v4 2/3] drm/i915/guc: Introduce buffer based cmd transport

bert.beck...@intel.com> Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> v2: use gem_object_pin_map (Chris) don't use DEBUG_RATELIMITED (Chris) don't track action stats (Chris) simplify next fence (Chris) use READ_ONCE (Chris) move blob allocation to new functio

Re: [Intel-gfx] [PATCH v3 4/5] drm/i915/guc: Cleanup adding GuC work items

;ch...@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> Cc: Michal Wajdeczko <michal.wajdec...@intel.com> Cc: Oscar Mateo <oscar.ma...@intel.com> Signed-off-by: Michał Winiarski <michal.winiar...@intel.com> Reviewed-by: Chris Wilson <ch...@

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/guc : Decouple logs from submission

uC objects Cc: Michal Wajdeczko <michal.wajdec...@intel.com> Cc: Oscar Mateo <oscar.ma...@intel.com> Cc: Anusha Srivatsa <anusha.sriva...@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospu...@intel.com> Signed-off-by: Sujaritha Sundaresan <sujaritha.sundare...@i

Re: [Intel-gfx] [PATCH 01/10] drm/i915/guc: Precompute GuC shared data offset

On 06/10/17 05:35, Michał Winiarski wrote: On Thu, Oct 05, 2017 at 05:02:39PM +, Daniele Ceraolo Spurio wrote: On 05/10/17 02:33, Chris Wilson wrote: Quoting Michał Winiarski (2017-10-05 10:13:40) We're using first page of kernel context state to share data with GuC, let's precompute

[Intel-gfx] [RFC i-g-t 2/6] tests/gem_pwrite: drop stolen memory related subtests

The feature was never merged and there has been no progress in the last year. The subtests are currently skipping on all platforms by checking a field in the get_aperture ioctl structure that doesn't exist in the kernel version of the struct. Signed-off-by: Daniele Ceraolo Spurio

  1   2   3   4   5   6   7   8   9   10   >