Re: [Intel-gfx] [PATCH i-g-t v2] lib/igt_pm: Restore runtime pm state on test exit

Quoting Tvrtko Ursulin (2018-02-28 15:35:06) > From: Tvrtko Ursulin > > Some tests (the ones which call igt_setup_runtime_pm and > igt_pm_enable_audio_runtime_pm) change default system configuration and > never restore it. > > The configured runtime suspend is

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/1] drm/i915/guc: s/intel_guc_fw_upload/intel_guc_init_hw/

== Series Details == Series: series starting with [1/1] drm/i915/guc: s/intel_guc_fw_upload/intel_guc_init_hw/ URL : https://patchwork.freedesktop.org/series/39192/ State : success == Summary == Series 39192v1 series starting with [1/1] drm/i915/guc: s/intel_guc_fw_upload/intel_guc_init_hw/

[Intel-gfx] [PATCH i-g-t v3] tests/perf_pmu: Test busyness reporting in face of GPU hangs

From: Tvrtko Ursulin Verify that the reported busyness is in line with what would we expect from a batch which causes a hang and gets kicked out from the engine. v2: Change to explicit igt_force_gpu_reset instead of guessing when a spin batch will hang. (Chris

Re: [Intel-gfx] [PATCH 2/6] drm: Remove now pointelss blob->data casts

Regards Shashank On 2/24/2018 12:55 AM, Ville Syrjala wrote: From: Ville Syrjälä Now that blob->data is void* again we don't need the casts anymore. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c| 3 +--

Re: [Intel-gfx] [PATCH i-g-t v2] tests/perf_pmu: Test busyness reporting in face of GPU hangs

On 01/03/2018 08:08, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-02-28 17:15:19) From: Tvrtko Ursulin Verify that the reported busyness is in line with what would we expect from a batch which causes a hang and gets kicked out from the engine. v2: Change to

Re: [Intel-gfx] i915 vs checkpatch

On Thu, 01 Mar 2018, Arkadiusz Hiler wrote: > Since not so long ago our CI is running and reporting sparse and > checkpatch. Sparse is doing just fine but I had to disable checkpatch > for the time being - too much "false" positives causing people to > complain. It's

Re: [Intel-gfx] [PATCH] drm/i915/perf: fix perf stream opening lock

Quoting Lionel Landwerlin (2018-02-28 11:45:48) > We're seeing on CI that some contexts don't have the programmed OA > period timer that directs the OA unit on how often to write reports. > > The issue is that we're not holding the drm lock from when we edit the > context images down to when we

Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: s/intel_guc_fw_upload/intel_guc_init_hw/

On Thu, 01 Mar 2018 09:18:18 +0100, Sagar Arun Kamble wrote: GuC and HuC get loaded from intel_uc_init_hw. HuC load function is named intel_huc_init_hw, however GuC load function is still named in old style as intel_guc_fw_upload. Update it and the function doc. for

[Intel-gfx] [PATCH] drm/i915: don't leak the pin_map on error

Add some onion to populate_lr_context. Fixes: d2b4b97933f5 ("drm/i915: Record the default hw state after reset upon load") Signed-off-by: Matthew Auld Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c | 10 ++ 1 file changed, 6

Re: [Intel-gfx] [PATCH] drm/i915: don't leak the pin_map on error

Quoting Matthew Auld (2018-03-01 10:18:55) > Add some onion to populate_lr_context. > > Fixes: d2b4b97933f5 ("drm/i915: Record the default hw state after reset upon > load") > Signed-off-by: Matthew Auld > Cc: Chris Wilson Worth backporting?

[Intel-gfx] [CI] drm/i915: Replace open-coded wait-for loop

Now that we can pass arbitrary commands into the base __wait_for() macro, we can reimplement the open-coded wait-for inside i915_gem_idle_work_handler() using the new macro. This means that instead of using ktime, we now use jiffies, and benefit from the exponential sleep backoff that allows a

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/icl: Prepare for more rings

== Series Details == Series: series starting with [CI,1/2] drm/i915/icl: Prepare for more rings URL : https://patchwork.freedesktop.org/series/39102/ State : success == Summary == Series 39102v1 series starting with [CI,1/2] drm/i915/icl: Prepare for more rings

Re: [Intel-gfx] [PATCH] drm/i915/guc: Removed unused GuC parameters.

Quoting Michel Thierry (2018-02-28 22:07:51) > On 28/02/18 12:26, Michel Thierry wrote: > > On 28/02/18 10:42, Piotr Piórkowski wrote: > >> In the i915 driver, there is a function, intel_guc_init_params(), > >> which initializes the GuC parameter block which is passed into > >> the GuC. There is

Re: [Intel-gfx] [PATCH i-g-t v2] tests/perf_pmu: Test busyness reporting in face of GPU hangs

Quoting Tvrtko Ursulin (2018-02-28 17:15:19) > From: Tvrtko Ursulin > > Verify that the reported busyness is in line with what would we expect > from a batch which causes a hang and gets kicked out from the engine. > > v2: Change to explicit igt_force_gpu_reset instead

[Intel-gfx] [PATCH 1/1] drm/i915/guc: s/intel_guc_fw_upload/intel_guc_init_hw/

GuC and HuC get loaded from intel_uc_init_hw. HuC load function is named intel_huc_init_hw, however GuC load function is still named in old style as intel_guc_fw_upload. Update it and the function doc. for both functions. Move of GuC load function's def. & decl. to intel_guc.c|h seems necessary as

Re: [Intel-gfx] [PATCH i-g-t v2] tests/perf_pmu: Test busyness reporting in face of GPU hangs

Quoting Tvrtko Ursulin (2018-03-01 09:21:52) > > On 01/03/2018 08:08, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-02-28 17:15:19) > >> From: Tvrtko Ursulin > >> > >> Verify that the reported busyness is in line with what would we expect > >> from a batch which

Re: [Intel-gfx] [PATCH] drm/i915/perf: fix perf stream opening lock

On 28/02/18 18:10, Matthew Auld wrote: On 28 February 2018 at 11:45, Lionel Landwerlin wrote: We're seeing on CI that some contexts don't have the programmed OA period timer that directs the OA unit on how often to write reports. The issue is that we're not

[Intel-gfx] i915 vs checkpatch

Hey all, Since not so long ago our CI is running and reporting sparse and checkpatch. Sparse is doing just fine but I had to disable checkpatch for the time being - too much "false" positives causing people to complain. It's simply confusing to see one thing in the code, and fitting your change

Re: [Intel-gfx] [PATCH] drm/i915: don't leak the pin_map on error

Matthew Auld writes: > Add some onion to populate_lr_context. > > Fixes: d2b4b97933f5 ("drm/i915: Record the default hw state after reset upon > load") > Signed-off-by: Matthew Auld > Cc: Chris Wilson > --- >

Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: s/intel_guc_fw_upload/intel_guc_init_hw/

On 3/1/2018 3:36 PM, Michal Wajdeczko wrote: On Thu, 01 Mar 2018 09:18:18 +0100, Sagar Arun Kamble wrote: GuC and HuC get loaded from intel_uc_init_hw. HuC load function is named intel_huc_init_hw, however GuC load function is still named in old style as

[Intel-gfx] [PATCH i-g-t] tests/gen7_forcewake_mt: Fix test

From: Tvrtko Ursulin 1. We need to tell the compiler mmio access cannot be optimized away (volatile). 2. We need to ensure we don't exit with forcewake left on. Signal threads to exit in a controlled fashion and install atexit handler just in case. Signed-off-by:

Re: [Intel-gfx] [PATCH] sna/uxa: Fix colormap handling at screen depth 30.

On Thu, Mar 01, 2018 at 02:20:48AM +0100, Mario Kleiner wrote: > The various clut handling functions like a setup > consistent with the x-screen color depth. Otherwise > we observe improper sampling in the gamma tables > at depth 30. > > Therefore replace hard-coded bitsPerRGB = 8 by actual >

Re: [Intel-gfx] [PATCH 3/6] drm: Verify gamma/degamma LUT size

On Thu, Mar 01, 2018 at 06:43:21PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 2/24/2018 12:55 AM, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > While we want to potentially support multiple different gamma/degamma > > LUT sizes we can

Re: [Intel-gfx] [PATCH 3/6] drm: Verify gamma/degamma LUT size

Regards Shashank On 3/1/2018 6:54 PM, Ville Syrjälä wrote: On Thu, Mar 01, 2018 at 06:43:21PM +0530, Sharma, Shashank wrote: Regards Shashank On 2/24/2018 12:55 AM, Ville Syrjala wrote: From: Ville Syrjälä While we want to potentially support multiple

Re: [Intel-gfx] [PATCH 3/6] drm: Verify gamma/degamma LUT size

On Thu, Mar 01, 2018 at 07:58:07PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/1/2018 6:54 PM, Ville Syrjälä wrote: > > On Thu, Mar 01, 2018 at 06:43:21PM +0530, Sharma, Shashank wrote: > >> Regards > >> > >> Shashank > >> > >> > >> On 2/24/2018 12:55 AM, Ville Syrjala

Re: [Intel-gfx] [PATCH i-g-t] tests/gen7_forcewake_mt: Fix test

Quoting Tvrtko Ursulin (2018-03-01 14:32:17) > +static void *mmio_base; > + > +static void cleanup(int sig) > +{ > + volatile uint32_t *forcewake_mt = > + (uint32_t *)((char *)mmio_base + FORCEWAKE_MT); > + unsigned int bit; > + > + for (bit = 2; bit < 16; bit++) {

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [CI,1/2] drm/i915/icl: Prepare for more rings

== Series Details == Series: series starting with [CI,1/2] drm/i915/icl: Prepare for more rings URL : https://patchwork.freedesktop.org/series/39102/ State : warning == Summary == Possible new issues: Test kms_frontbuffer_tracking: Subgroup fbc-2p-primscrn-shrfb-pgflip-blt:

Re: [Intel-gfx] [PATCH v11 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers

On Thu, 01 Mar 2018 02:01:39 +0100, Jackie Li wrote: GuC WOPCM registers are write-once registers. Current driver code accesses these registers without checking the accessibility to these registers which will lead to unpredictable driver behaviors if these registers

[Intel-gfx] [PATCH v2] drm/i915/gen9, gen10: Disable FBC on planes with a misaligned Y-offset

Enabling FBC on a plane having a Y-offset that isn't divisible by 4 may cause pipe FIFO underruns and flickers, so disable FBC on such a config. I tried the followings to work around the issue: - enable each HW work around in ILK_DPFC_CHICKEN - disable each compression algorithm in

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: don't leak the pin_map on error (rev2)

== Series Details == Series: drm/i915: don't leak the pin_map on error (rev2) URL : https://patchwork.freedesktop.org/series/39207/ State : success == Summary == Series 39207v2 drm/i915: don't leak the pin_map on error https://patchwork.freedesktop.org/api/1.0/series/39207/revisions/2/mbox/

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen9: Disable FBC on planes with a misaligned Y-offset (rev2)

== Series Details == Series: drm/i915/gen9: Disable FBC on planes with a misaligned Y-offset (rev2) URL : https://patchwork.freedesktop.org/series/39129/ State : success == Summary == Series 39129v2 drm/i915/gen9: Disable FBC on planes with a misaligned Y-offset

[Intel-gfx] [PATCH v2 1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric

GuC load function is named intel_guc_fw_upload() and HuC load function is named intel_huc_init_hw(). Make them consistent intel_*_fw_upload. Also move HuC fw loading functions and declarations to separate files intel_huc_fw.c|h like GuC. While at this, do below changes 1. Update kernel-doc

Re: [Intel-gfx] [PATCH i-g-t] tests/gen7_forcewake_mt: Fix test

On 01/03/2018 14:41, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-03-01 14:32:17) +static void *mmio_base; + +static void cleanup(int sig) +{ + volatile uint32_t *forcewake_mt = + (uint32_t *)((char *)mmio_base + FORCEWAKE_MT); + unsigned int bit; + + for

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric

On Thu, 01 Mar 2018 15:47:22 +0100, Sagar Arun Kamble wrote: GuC load function is named intel_guc_fw_upload() and HuC load function is named intel_huc_init_hw(). Make them consistent intel_*_fw_upload. Also move HuC fw loading functions and declarations to separate

Re: [Intel-gfx] [PATCH v11 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers

Quoting Jackie Li (2018-03-01 01:01:39) > GuC WOPCM registers are write-once registers. Current driver code accesses > these registers without checking the accessibility to these registers which > will lead to unpredictable driver behaviors if these registers were touch > by other components (such

[Intel-gfx] [PATCH v2] drm/i915/perf: fix perf stream opening lock

We're seeing on CI that some contexts don't have the programmed OA period timer that directs the OA unit on how often to write reports. The issue is that we're not holding the drm lock from when we edit the context images down to when we set the exclusive_stream variable. This leaves a window for

Re: [Intel-gfx] [PATCH 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb()

On Thu, Mar 01, 2018 at 12:51:45PM +0200, Ville Syrjälä wrote: > On Wed, Feb 28, 2018 at 11:38:56PM +, Pandiyan, Dhinakaran wrote: > > > > > > > > On Wed, 2018-02-28 at 22:38 +0200, Ville Syrjälä wrote: > > > On Wed, Feb 28, 2018 at 10:28:13PM +0200, Ville Syrjälä wrote: > > > > On Sat, Feb

Re: [Intel-gfx] [PATCH 4/4] drm/i915/icl: Interrupt handling

Paulo Zanoni writes: > Em Ter, 2018-02-27 às 11:51 -0800, Daniele Ceraolo Spurio escreveu: >> >> On 20/02/18 07:37, Mika Kuoppala wrote: >> > v2: Rebase. >> > >> > v3: >> >* Remove DPF, it has been removed from SKL+. >> >* Fix -internal rebase wrt. execlists

Re: [Intel-gfx] [PATCH 3/4] drm/i915/icl: Prepare for more rings

Mika Kuoppala writes: > From: Tvrtko Ursulin > > Gen11 will add more VCS and VECS rings so prepare the > infrastructure to support that. > > Bspec: 7021 > > v2: Rebase. > v3: Rebase. > v4: Rebase. > v5: Rebase. > v6: > - Update for POR

Re: [Intel-gfx] [PATCH v11 3/6] drm/i915: Add support to return CNL specific reserved WOPCM size

On Thu, 01 Mar 2018 02:01:37 +0100, Jackie Li wrote: CNL has its specific reserved GuC WOPCM size for RC6 and other hardware contexts. This patch updates the code to return CNL specific reserved GuC WOPCM size for RC6 and other hardware contexts so that the GuC WOPCM

Re: [Intel-gfx] [PATCH 3/6] drm: Verify gamma/degamma LUT size

Regards Shashank On 2/24/2018 12:55 AM, Ville Syrjala wrote: From: Ville Syrjälä While we want to potentially support multiple different gamma/degamma LUT sizes we can (and should) at least check that the blob length is a multiple of the LUT entry size. I dint

Re: [Intel-gfx] [PATCH 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb()

On Wed, Feb 28, 2018 at 11:38:56PM +, Pandiyan, Dhinakaran wrote: > > > > On Wed, 2018-02-28 at 22:38 +0200, Ville Syrjälä wrote: > > On Wed, Feb 28, 2018 at 10:28:13PM +0200, Ville Syrjälä wrote: > > > On Sat, Feb 24, 2018 at 03:24:55AM +, Pandiyan, Dhinakaran wrote: > > > > > > > >

Re: [Intel-gfx] [PATCH v11 4/6] drm/i915: Add HuC firmware size related restriction for Gen9 and CNL A0

On Thu, 01 Mar 2018 02:01:38 +0100, Jackie Li wrote: On CNL A0 and Gen9, there's a hardware restriction that requires the available GuC WOPCM size to be larger than or equal to HuC firmware size. This patch adds new verification code to ensure the available GuC WOPCM

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: fix perf stream opening lock (rev2)

== Series Details == Series: drm/i915/perf: fix perf stream opening lock (rev2) URL : https://patchwork.freedesktop.org/series/39112/ State : success == Summary == Series 39112v2 drm/i915/perf: fix perf stream opening lock

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/1] drm/i915/guc: s/intel_guc_fw_upload/intel_guc_init_hw/

== Series Details == Series: series starting with [1/1] drm/i915/guc: s/intel_guc_fw_upload/intel_guc_init_hw/ URL : https://patchwork.freedesktop.org/series/39192/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-contexts: pass

Re: [Intel-gfx] [PATCH v11 1/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

On Thu, 01 Mar 2018 02:01:35 +0100, Jackie Li wrote: GuC related exported functions should start with "intel_guc_" prefix and pass intel_guc as the first parameter since its GuC related. Current guc_ggtt_offset() failed to follow this code convention and this is a problem

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Replace open-coded wait-for loop (rev2)

== Series Details == Series: drm/i915: Replace open-coded wait-for loop (rev2) URL : https://patchwork.freedesktop.org/series/36904/ State : success == Summary == Series 36904v2 drm/i915: Replace open-coded wait-for loop https://patchwork.freedesktop.org/api/1.0/series/36904/revisions/2/mbox/

Re: [Intel-gfx] [PATCH v11 2/6] drm/i915: Implement dynamic GuC WOPCM offset and size calculation

On Thu, 01 Mar 2018 02:01:36 +0100, Jackie Li wrote: Hardware may have specific restrictions on GuC WOPCM offset and size. On Gen9, the value of the GuC WOPCM size register needs to be larger than the value of GuC WOPCM offset register + a Gen9 specific offset (144KB)

Re: [Intel-gfx] [PATCH] drm/i915/skl+: Add and enable DP AUX CH mutex

On Wed, Feb 28, 2018 at 11:55:39PM +, Souza, Jose wrote: > On Wed, 2018-02-28 at 13:09 +0200, Ville Syrjälä wrote: > > On Wed, Feb 28, 2018 at 12:57:07AM +, Souza, Jose wrote: > > > On Tue, 2018-02-27 at 23:34 +0200, Ville Syrjälä wrote: > > > > On Tue, Feb 27, 2018 at 01:23:59PM -0800,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: don't leak the pin_map on error

== Series Details == Series: drm/i915: don't leak the pin_map on error URL : https://patchwork.freedesktop.org/series/39207/ State : success == Summary == Series 39207v1 drm/i915: don't leak the pin_map on error https://patchwork.freedesktop.org/api/1.0/series/39207/revisions/1/mbox/

Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: s/intel_guc_fw_upload/intel_guc_init_hw/

On Thu, 01 Mar 2018 11:28:03 +0100, Sagar Arun Kamble wrote: On 3/1/2018 3:36 PM, Michal Wajdeczko wrote: On Thu, 01 Mar 2018 09:18:18 +0100, Sagar Arun Kamble wrote: GuC and HuC get loaded from intel_uc_init_hw. HuC load function

Re: [Intel-gfx] i915 vs checkpatch

On Thu, Mar 01, 2018 at 12:43:22PM +0200, Jani Nikula wrote: > On Thu, 01 Mar 2018, Arkadiusz Hiler wrote: > > Since not so long ago our CI is running and reporting sparse and > > checkpatch. Sparse is doing just fine but I had to disable checkpatch > > for the time

Re: [Intel-gfx] [PATCH igt 4/5] igt/gem_exec_capture: Exercise readback of userptr

On Wed, Feb 28, 2018 at 03:51:37PM +, Chris Wilson wrote: > EXEC_OBJECT_CAPTURE extends the type of buffers we may read during error > capture. Previously we knew that we would only see batch buffers (which > limited the objects to being from gem_create()), but now we need to > check that any

[Intel-gfx] [PATCH] drm/i915: don't leak the pin_map on error

Add some onion to populate_lr_context. v2: prefer err_unpin_ctx drop the fixes tag, worst case we just spew a warn before everything is cleaned up and balance is restored Signed-off-by: Matthew Auld Cc: Chris Wilson Reviewed-by: Chris

Re: [Intel-gfx] [PATCH] drm/i915/guc: Removed unused GuC parameters.

On 3/1/2018 1:32 PM, Chris Wilson wrote: Quoting Michel Thierry (2018-02-28 22:07:51) On 28/02/18 12:26, Michel Thierry wrote: On 28/02/18 10:42, Piotr Piórkowski wrote: In the i915 driver, there is a function, intel_guc_init_params(), which initializes the GuC parameter block which is

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric

On 3/1/2018 8:21 PM, Michal Wajdeczko wrote: On Thu, 01 Mar 2018 15:47:22 +0100, Sagar Arun Kamble wrote: GuC load function is named intel_guc_fw_upload() and HuC load function is named intel_huc_init_hw(). Make them consistent intel_*_fw_upload. Also move HuC fw

Re: [Intel-gfx] [PATCH igt v2] igt/gem_ctx_switch: Exercise all engines at once

On 28/02/18 23:51, Chris Wilson wrote: Just a small variant to apply a continuous context-switch load to all engines. v2: Adapt to for_each_physical_engine() and sane gem_context_create() Signed-off-by: Chris Wilson Cc: Antonio Argenziano

Re: [Intel-gfx] i915 vs checkpatch

I went through the recent checkpatch reports, and here's my take. On Thu, 01 Mar 2018, Arkadiusz Hiler wrote: > 2. Which of the checkpatch checks we want to disabled for i915? I'd like to have these silenced: CHECK: No space is necessary after a cast WARNING: line

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric

== Series Details == Series: series starting with [v2,1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric URL : https://patchwork.freedesktop.org/series/39220/ State : success == Summary == Series 39220v1 series starting with [v2,1/1] drm/i915/uc: Make

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: don't leak the pin_map on error

== Series Details == Series: drm/i915: don't leak the pin_map on error URL : https://patchwork.freedesktop.org/series/39207/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-contexts: incomplete -> PASS (shard-apl) fdo#104945

Re: [Intel-gfx] [PATCH] drm/i915/psr: Update PSR2 resolution check for Cannonlake

On Thu, Mar 01, 2018 at 12:38:58PM -0800, Dhinakaran Pandiyan wrote: > In fact, apply the Cannonlake resolution check for all > Gen-9 platforms to > be safe. > > Cc: Rodrigo Vivi > Cc: Elio Martinez Monroy > Signed-off-by: Dhinakaran

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/psr: Update PSR2 resolution check for Cannonlake

== Series Details == Series: drm/i915/psr: Update PSR2 resolution check for Cannonlake URL : https://patchwork.freedesktop.org/series/39238/ State : failure == Summary == Series 39238v1 drm/i915/psr: Update PSR2 resolution check for Cannonlake

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gen9: Disable FBC on planes with a misaligned Y-offset (rev2)

== Series Details == Series: drm/i915/gen9: Disable FBC on planes with a misaligned Y-offset (rev2) URL : https://patchwork.freedesktop.org/series/39129/ State : success == Summary == Possible new issues: Test kms_frontbuffer_tracking: Subgroup

Re: [Intel-gfx] [PATCH 05/17] drm/i915/icl: compute the MG PLL registers

On Thu, Feb 22, 2018 at 12:55:07AM -0300, Paulo Zanoni wrote: > This implements the "MG PLL Programming" sequence from our spec. The > biggest problem was that the spec assumes real numbers, so we had to > adjust some numbers and alculations due to the fact that the Kernel > prefers to deal with

Re: [Intel-gfx] [PATCH v2] drm/i915/psr: Update PSR2 resolution check for Cannonlake

On Thu, Mar 01, 2018 at 01:27:09PM -0800, Dhinakaran Pandiyan wrote: > In fact, apply the Cannonlake resolution check for all >= Gen-10 platforms > to be safe. > > v2: Use local variables for resolution limits and print them (Ville) > > Cc: Ville Syrjälä > Cc:

Re: [Intel-gfx] [PATCH v2] drm/i915/uc: Start preparing GuC/HuC for reset

On 26/02/18 23:50, Chris Wilson wrote: Quoting Sagar Arun Kamble (2018-02-27 06:54:46) On 2/27/2018 2:22 AM, Chris Wilson wrote: Quoting Daniele Ceraolo Spurio (2018-02-26 16:57:11) As you said we do always reset GuC no matter the value of the modparam, but that does not reset the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Update PSR2 resolution check for Cannonlake (rev2)

== Series Details == Series: drm/i915/psr: Update PSR2 resolution check for Cannonlake (rev2) URL : https://patchwork.freedesktop.org/series/39238/ State : success == Summary == Series 39238v2 drm/i915/psr: Update PSR2 resolution check for Cannonlake

Re: [Intel-gfx] [PATCH] drm/i915/psr: Update PSR2 resolution check for Cannonlake

On Thu, Mar 01, 2018 at 10:47:05PM +0200, Ville Syrjälä wrote: > On Thu, Mar 01, 2018 at 12:38:58PM -0800, Dhinakaran Pandiyan wrote: > > In fact, apply the Cannonlake resolution check for all > Gen-9 platforms to > > be safe. > > > > Cc: Rodrigo Vivi > > Cc: Elio

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: don't leak the pin_map on error (rev2)

== Series Details == Series: drm/i915: don't leak the pin_map on error (rev2) URL : https://patchwork.freedesktop.org/series/39207/ State : warning == Summary == Possible new issues: Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-mmap-gtt:

Re: [Intel-gfx] [PATCH 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb()

On Thu, Mar 01, 2018 at 01:22:50PM +0200, Ville Syrjälä wrote: > On Thu, Mar 01, 2018 at 12:51:45PM +0200, Ville Syrjälä wrote: > > On Wed, Feb 28, 2018 at 11:38:56PM +, Pandiyan, Dhinakaran wrote: > > > > > > > > > > > > On Wed, 2018-02-28 at 22:38 +0200, Ville Syrjälä wrote: > > > > On

Re: [Intel-gfx] [PATCH] drm/i915/icl: local_clock returns an u64

Quoting Michel Thierry (2018-03-01 18:07:03) > So change timeout_ts and use time_after64 in gen11_gt_engine_intr. We only need u32 for the duration. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb()

On Thu, Mar 01, 2018 at 11:00:40AM -0800, Rodrigo Vivi wrote: > On Thu, Mar 01, 2018 at 08:43:05PM +0200, Ville Syrjälä wrote: > > On Thu, Mar 01, 2018 at 10:35:48AM -0800, Rodrigo Vivi wrote: > > > On Thu, Mar 01, 2018 at 01:22:50PM +0200, Ville Syrjälä wrote: > > > > On Thu, Mar 01, 2018 at

[Intel-gfx] [PATCH v2] drm/i915/psr: Update PSR2 resolution check for Cannonlake

In fact, apply the Cannonlake resolution check for all >= Gen-10 platforms to be safe. v2: Use local variables for resolution limits and print them (Ville) Cc: Ville Syrjälä Cc: Rodrigo Vivi Cc: Elio Martinez Monroy

Re: [Intel-gfx] i915 vs checkpatch

Quoting Arkadiusz Hiler (2018-03-01 09:47:06) > Hey all, > > Since not so long ago our CI is running and reporting sparse and > checkpatch. Sparse is doing just fine but I had to disable checkpatch > for the time being - too much "false" positives causing people to > complain. It's simply

[Intel-gfx] [PATCH] drm/i915/psr: Update PSR2 resolution check for Cannonlake

In fact, apply the Cannonlake resolution check for all > Gen-9 platforms to be safe. Cc: Rodrigo Vivi Cc: Elio Martinez Monroy Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/intel_psr.c | 11

Re: [Intel-gfx] [PATCH] drm/i915/psr: Update PSR2 resolution check for Cannonlake

On Thu, 2018-03-01 at 22:47 +0200, Ville Syrjälä wrote: > On Thu, Mar 01, 2018 at 12:38:58PM -0800, Dhinakaran Pandiyan wrote: > > In fact, apply the Cannonlake resolution check for all > Gen-9 platforms to > > be safe. > > > > Cc: Rodrigo Vivi > > Cc: Elio Martinez

Re: [Intel-gfx] [PATCH v2] drm/i915/psr: Update PSR2 resolution check for Cannonlake

On Thu, 2018-03-01 at 23:47 +0200, Ville Syrjälä wrote: > On Thu, Mar 01, 2018 at 01:27:09PM -0800, Dhinakaran Pandiyan wrote: > > In fact, apply the Cannonlake resolution check for all >= Gen-10 platforms > > to be safe. > > > > v2: Use local variables for resolution limits and print them

Re: [Intel-gfx] [PATCH 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb()

On Thu, Mar 01, 2018 at 10:35:48AM -0800, Rodrigo Vivi wrote: > On Thu, Mar 01, 2018 at 01:22:50PM +0200, Ville Syrjälä wrote: > > On Thu, Mar 01, 2018 at 12:51:45PM +0200, Ville Syrjälä wrote: > > > On Wed, Feb 28, 2018 at 11:38:56PM +, Pandiyan, Dhinakaran wrote: > > > > > > > > > > > > >

Re: [Intel-gfx] [PATCH] drm/i915/guc: Removed unused GuC parameters.

On Thu, 2018-03-01 at 17:35 +0530, Sagar Arun Kamble wrote: > > On 3/1/2018 1:32 PM, Chris Wilson wrote: > > > > Quoting Michel Thierry (2018-02-28 22:07:51) > > > > > > On 28/02/18 12:26, Michel Thierry wrote: > > > > > > > > On 28/02/18 10:42, Piotr Piórkowski wrote: > > > > > > > > > > In

Re: [Intel-gfx] [PATCH 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb()

On Thu, 2018-03-01 at 11:00 -0800, Rodrigo Vivi wrote: > On Thu, Mar 01, 2018 at 08:43:05PM +0200, Ville Syrjälä wrote: > > On Thu, Mar 01, 2018 at 10:35:48AM -0800, Rodrigo Vivi wrote: > > > On Thu, Mar 01, 2018 at 01:22:50PM +0200, Ville Syrjälä wrote: > > > > On Thu, Mar 01, 2018 at 12:51:45PM

[Intel-gfx] [PATCH i-g-t 3/6] lib: Add function to hash a framebuffer

From: Brian Starkey To use writeback buffers as a CRC source, we need to be able to hash them. Implement a simple FVA-1a hashing routine for this purpose. Doing a bytewise hash on the framebuffer directly can be very slow if the memory is noncached. By making a copy of

[Intel-gfx] [PATCH i-g-t 1/6] lib/igt_kms: Add writeback support in lib/

From: Brian Starkey Add support in igt_kms for Writeback connectors, with the ability to attach framebuffers and retrieve fences. Signed-off-by: Brian Starkey --- lib/igt_kms.c | 72 ++-

[Intel-gfx] [PATCH i-g-t 6/6] kms_writeback: Add tests using a cloned output

From: Brian Starkey Update the connector search to also optionally attempt to find a non-writeback connector to clone to. Add a subtest which is the same as writeback-check-output, but also clones to the second connector. Signed-off-by: Brian Starkey

Re: [Intel-gfx] i915 vs checkpatch

On Thu, Mar 01, 2018 at 06:13:31PM +0200, Jani Nikula wrote: > > I went through the recent checkpatch reports, and here's my take. > > On Thu, 01 Mar 2018, Arkadiusz Hiler wrote: > > 2. Which of the checkpatch checks we want to disabled for i915? > > I'd like to

Re: [Intel-gfx] [PATCH v11 4/6] drm/i915: Add HuC firmware size related restriction for Gen9 and CNL A0

On 03/01/2018 05:14 AM, Michal Wajdeczko wrote: On Thu, 01 Mar 2018 02:01:38 +0100, Jackie Li wrote: On CNL A0 and Gen9, there's a hardware restriction that requires the available GuC WOPCM size to be larger than or equal to HuC firmware size. This patch adds new

[Intel-gfx] [PATCH] drm/i915: Register definitions for DP Phy compiance

From: Clint Taylor DisplayPort Phy compliance test patterns register definitions. Signed-off-by: Clint Taylor --- drivers/gpu/drm/i915/i915_reg.h | 18 ++ 1 file changed, 18 insertions(+) diff --git

[Intel-gfx] [PATCH] drm/i915/icl: local_clock returns an u64

So change timeout_ts and use time_after64 in gen11_gt_engine_intr. Fixes: 51951ae7ed00 ("drm/i915/icl: Interrupt handling"). Suggested-by: Tvrtko Ursulin (long time ago) Signed-off-by: Michel Thierry Cc: Daniele Ceraolo Spurio

Re: [Intel-gfx] [PATCH] drm/i915/icl: local_clock returns an u64

On 3/1/2018 10:07 AM, Michel Thierry wrote: So change timeout_ts and use time_after64 in gen11_gt_engine_intr. I just read Chris' original comment about this, so ignore the patch, "The squash should be made, but time_after64 is no more correct since the native 32b/64b wrapped arithmetic is

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: local_clock returns an u64

== Series Details == Series: drm/i915/icl: local_clock returns an u64 URL : https://patchwork.freedesktop.org/series/39231/ State : success == Summary == Series 39231v1 drm/i915/icl: local_clock returns an u64 https://patchwork.freedesktop.org/api/1.0/series/39231/revisions/1/mbox/

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Register definitions for DP Phy compiance

== Series Details == Series: drm/i915: Register definitions for DP Phy compiance URL : https://patchwork.freedesktop.org/series/39233/ State : success == Summary == Series 39233v1 drm/i915: Register definitions for DP Phy compiance

[Intel-gfx] *cringe* at adding a parameter to workaround issues.

Hi Jani, > *cringe* at adding a parameter to workaround issues. I understand that *each* parameter has the potential to *multiply* the total number of configurations and that the resulting combinatorial explosion is absolutely not scalable and sustainable from a validation perspective. No one

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Replace open-coded wait-for loop (rev2)

== Series Details == Series: drm/i915: Replace open-coded wait-for loop (rev2) URL : https://patchwork.freedesktop.org/series/36904/ State : success == Summary == Possible new issues: Test kms_vblank: Subgroup pipe-a-ts-continuation-modeset: skip -> PASS

Re: [Intel-gfx] [PATCH v11 2/6] drm/i915: Implement dynamic GuC WOPCM offset and size calculation

On 03/01/2018 04:56 AM, Michal Wajdeczko wrote: On Thu, 01 Mar 2018 02:01:36 +0100, Jackie Li wrote: +    if (guc_fw_size >= wopcm->size) { +    DRM_ERROR("GuC FW (%uKiB) is too big to fit in WOPCM.", +  guc_fw_size / 1024); +    return -E2BIG; +  

Re: [Intel-gfx] [PATCH 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb()

On Thu, Mar 01, 2018 at 08:43:05PM +0200, Ville Syrjälä wrote: > On Thu, Mar 01, 2018 at 10:35:48AM -0800, Rodrigo Vivi wrote: > > On Thu, Mar 01, 2018 at 01:22:50PM +0200, Ville Syrjälä wrote: > > > On Thu, Mar 01, 2018 at 12:51:45PM +0200, Ville Syrjälä wrote: > > > > On Wed, Feb 28, 2018 at

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/perf: fix perf stream opening lock (rev2)

== Series Details == Series: drm/i915/perf: fix perf stream opening lock (rev2) URL : https://patchwork.freedesktop.org/series/39112/ State : success == Summary == Known issues: Test gem_eio: Subgroup suspend: pass -> INCOMPLETE (shard-hsw) fdo#105055 Test

Re: [Intel-gfx] [PATCH v11 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers

On 03/01/2018 05:37 AM, Michal Wajdeczko wrote: On Thu, 01 Mar 2018 02:01:39 +0100, Jackie Li wrote: + +    err = write_and_verify(dev_priv, GUC_WOPCM_SIZE, +   dev_priv->wopcm.guc.size, you should use wopcm-> instead dev_priv->wopcm. (same below)

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric

== Series Details == Series: series starting with [v2,1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric URL : https://patchwork.freedesktop.org/series/39220/ State : failure == Summary == Possible new issues: Test kms_frontbuffer_tracking:

[Intel-gfx] [PATCH v12 4/6] drm/i915: Add HuC firmware size related restriction for Gen9 and CNL A0

On CNL A0 and Gen9, there's a hardware restriction that requires the available GuC WOPCM size to be larger than or equal to HuC firmware size. This patch adds new verification code to ensure the available GuC WOPCM size to be larger than or equal to HuC firmware size on both Gen9 and CNL A0. v6:

[Intel-gfx] [PATCH v12 2/6] drm/i915: Implement dynamic GuC WOPCM offset and size calculation

Hardware may have specific restrictions on GuC WOPCM offset and size. On Gen9, the value of the GuC WOPCM size register needs to be larger than the value of GuC WOPCM offset register + a Gen9 specific offset (144KB) for reserved GuC WOPCM. Fail to enforce such a restriction on GuC WOPCM size will

[Intel-gfx] [PATCH v12 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers

GuC WOPCM registers are write-once registers. Current driver code accesses these registers without checking the accessibility to these registers which will lead to unpredictable driver behaviors if these registers were touch by other components (such as faulty BIOS code). This patch moves the GuC

  1   2   >