[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v4,1/2] drm/i915/icl: new context descriptor support

== Series Details == Series: series starting with [v4,1/2] drm/i915/icl: new context descriptor support URL : https://patchwork.freedesktop.org/series/38031/ State : success == Summary == Test perf_pmu: Subgroup rc6: skip -> PASS (shard-hsw) Test

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915: Store gen_mask inside the static device info

== Series Details == Series: series starting with [1/4] drm/i915: Store gen_mask inside the static device info URL : https://patchwork.freedesktop.org/series/38026/ State : failure == Summary == Test kms_setmode: Subgroup basic: fail -> PASS (shard-hsw)

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/2] drm/i915/icl: new context descriptor support

== Series Details == Series: series starting with [v4,1/2] drm/i915/icl: new context descriptor support URL : https://patchwork.freedesktop.org/series/38031/ State : success == Summary == Series 38031v1 series starting with [v4,1/2] drm/i915/icl: new context descriptor support

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/icl: new context descriptor support

On 02/09/2018 03:28 PM, Daniele Ceraolo Spurio wrote: From: "Ceraolo Spurio, Daniele" Starting from Gen11 the context descriptor format has been updated in the HW. The hw_id field has been considerably reduced in size and engine class and instance fields have

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Disable dynamic setup of device_info->num_rings

On 02/09/2018 02:35 PM, Chris Wilson wrote: In order to allow the compiler to use a known constant number of available engines, disable modification of intel_device_static_info during engine bring up. Instead of trying to gracefully hide the broken setup, error out -- in theory, this should be

Re: [Intel-gfx] [PATCH] drm/i915: Fix incorrect comment

On Fri, Feb 09, 2018 at 03:07:55PM +0200, David Weinehall wrote: > While the comment singles out Port A or B, the code says Port A or *D*. > Looking at the history it seems that the comment was added after the code, > so it seems likely that the code is correct, not the comment. > > CC: Jani

[Intel-gfx] [PATCH v8 2/2] drm/i915/icl: Enhanced execution list support

From: Thomas Daniel Enhanced Execlists is an upgraded version of execlists which supports up to 8 ports. The lrcs to be submitted are written to a submit queue (the ExecLists Submission Queue - ELSQ), which is then loaded on the HW. When writing to the ELSP register, the

[Intel-gfx] [PATCH v4 1/2] drm/i915/icl: new context descriptor support

From: "Ceraolo Spurio, Daniele" Starting from Gen11 the context descriptor format has been updated in the HW. The hw_id field has been considerably reduced in size and engine class and instance fields have been added. There is a slight name clashing issue

Re: [Intel-gfx] [PATCH] drm/i915: Improve PSR activation timing

On Thu, 2018-02-08 at 23:39 -0800, Rodrigo Vivi wrote: > Rodrigo Vivi writes: > > > "Pandiyan, Dhinakaran" writes: > > > >> On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote: > >>> Hi Andy, > >>> > >>> thanks for getting involved with

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Store gen_mask inside the static device info

== Series Details == Series: series starting with [1/4] drm/i915: Store gen_mask inside the static device info URL : https://patchwork.freedesktop.org/series/38026/ State : success == Summary == Series 38026v1 series starting with [1/4] drm/i915: Store gen_mask inside the static device info

Re: [Intel-gfx] [PATCH 3/5] drm/i915: Call i915_pipe_update_start with uncore.lock held.

On Fri, Feb 09, 2018 at 10:54:02AM +0100, Maarten Lankhorst wrote: > This requires being able to read the vblank counter with the > uncore.lock already held. This is also a preparation for > being able to run the entire vblank update sequence with > the uncore lock held. > > Signed-off-by:

[Intel-gfx] [PATCH 4/4] drm/i915: Disable dynamic setup of device_info->num_rings

In order to allow the compiler to use a known constant number of available engines, disable modification of intel_device_static_info during engine bring up. Instead of trying to gracefully hide the broken setup, error out -- in theory, this should be caught during power on. Signed-off-by: Chris

[Intel-gfx] [PATCH 3/4] drm/i915: Store platform_mask inside the static device info

Rather than deriving the platform_mask from the intel_device_static_info->platform at runtime, prefill it in the static data. baseline.ko drivers/gpu/drm/i915/i915.ko add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-20 (-20) Function old new delta

[Intel-gfx] [PATCH 2/4] drm/i915: Always define GEN as part of GENx_FEATURES

Be consistent and define the device's GEN as part of the GENx_FEATURE. It will be overridden by the next gen upon inheriting, as per usual. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_pci.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-)

[Intel-gfx] [PATCH 1/4] drm/i915: Store gen_mask inside the static device info

Rather than deriving the gen_mask from the static intel_device_info->gen at runtime, prefill it in the static data. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.c | 2 -- drivers/gpu/drm/i915/i915_pci.c | 39 --- 2

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

+ +static irqreturn_t +gen11_gt_irq_handler(struct drm_i915_private *dev_priv, u32 master_ctl) +{ + irqreturn_t ret = IRQ_NONE; + u16 irq[2][32]; + u32 dw, ident; + unsigned long tmp; + unsigned int bank, bit, engine; + unsigned long wait_start, wait_end; +

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/userptr: Probe vma range before gup (rev7)

== Series Details == Series: drm/i915/userptr: Probe vma range before gup (rev7) URL : https://patchwork.freedesktop.org/series/35394/ State : warning == Summary == Test kms_setmode: Subgroup basic: fail -> PASS (shard-apl) fdo#99912 Test perf_pmu:

[Intel-gfx] ✗ Fi.CI.BAT: failure for Selectable platform support (rev2)

== Series Details == Series: Selectable platform support (rev2) URL : https://patchwork.freedesktop.org/series/37912/ State : failure == Summary == Applying: drm/i915: Make I830 platform support optional Applying: drm/i915: Make I845G platform support optional Applying: drm/i915: Make I85X

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/2] drm/i915: Use INTEL_GEN everywhere

== Series Details == Series: series starting with [CI,1/2] drm/i915: Use INTEL_GEN everywhere URL : https://patchwork.freedesktop.org/series/38025/ State : failure == Summary == Series 38025v1 series starting with [CI,1/2] drm/i915: Use INTEL_GEN everywhere

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

On 02/09/2018 11:42 AM, Michal Wajdeczko wrote: +static inline bool __reg_locked(struct drm_i915_private *dev_priv, +    i915_reg_t reg) +{ +    /* Set of bit-0 means this write-once register is locked. */ +    return I915_READ(reg) & BIT(0); +} Hmm, I'm still not happy as not

[Intel-gfx] [PATCH] __gen__

--- drivers/gpu/drm/i915/i915_drv.c | 6 ++--- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/i915_pci.c | 30 drivers/gpu/drm/i915/intel_device_info.c | 2 +-

[Intel-gfx] [CI 1/2] drm/i915: Use INTEL_GEN everywhere

From: Tvrtko Ursulin Coccinelle patch: @@ identifier p; @@ -INTEL_INFO(p)->gen +INTEL_GEN(p) Signed-off-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20180208130606.15556-12-tvrtko.ursu...@linux.intel.com

[Intel-gfx] [CI 2/2] drm/i915: Replace some negative Gen checks

From: Tvrtko Ursulin Instead of INTEL_GEN != x use !IS_GENx for more optimisation opportunities. Signed-off-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20180208130606.15556-16-tvrtko.ursu...@linux.intel.com

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/10] drm/i915: Rename intel_device_info and accessors

== Series Details == Series: series starting with [01/10] drm/i915: Rename intel_device_info and accessors URL : https://patchwork.freedesktop.org/series/38018/ State : failure == Summary == Series 38018v1 series starting with [01/10] drm/i915: Rename intel_device_info and accessors

[Intel-gfx] [PATCH 07/10] drm/i915: Disable dynamic setup of device_info->num_rings

In order to allow the compiler to use a known constant number of available engines, disable modification of intel_device_static_info during engine bring up. Instead of trying to gracefully hide the broken setup, error out -- in theory, this should be caught during power on. add/remove: 0/0

[Intel-gfx] [PATCH 09/10] drm/i915: Make a mutable copy of pages_size in intel_driver_caps

Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 3 ++- drivers/gpu/drm/i915/i915_gem.c | 6 +++--- drivers/gpu/drm/i915/intel_device_info.c | 1 +

[Intel-gfx] [PATCH 10/10] drm/i915: Make a mutable copy of intel_device_static_info.has_fbc

Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/intel_device_info.c | 1 + drivers/gpu/drm/i915/intel_device_info.h | 2 ++ drivers/gpu/drm/i915/intel_fbc.c | 3 ++- 4 files changed, 6 insertions(+), 2

[Intel-gfx] [PATCH 03/10] drm/i915: Store platform_mask inside the static device info

Rather than deriving the platform_mask from the intel_device_static_info->platform at runtime, prefill it in the static data. baseline.ko drivers/gpu/drm/i915/i915.ko add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-20 (-20) Function old new delta

[Intel-gfx] [PATCH 05/10] drm/i915: Move PCI-ID from static device info to runtime

Since we map multiple PCI-IDs to a single static device info, we cannot store the PCI-ID inside the static struct. But since we want to keep the PCI-ID easily accessible, we do want to copy it into the drm_i915_private, hence use intel_device_runtime_info. add/remove: 0/0 grow/shrink: 3/0

[Intel-gfx] [PATCH 08/10] drm/i915: Move SSEU runtime info to intel_device_runtime_info

add/remove: 1/2 grow/shrink: 11/60 up/down: 3337/-3770 (-433) Function old new delta intel_device_runtime_info_init -2632 +2632 intel_device_runtime_info_print 25 335+310 capture

[Intel-gfx] [PATCH 06/10] drm/i915: Remove a local writable device_info

Now that we stop populating the static device_info during early init, we can remove the last trace of the writable local variable. add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-17 (-17) Function old new delta i915_driver_load

[Intel-gfx] [PATCH 02/10] drm/i915: Store gen_mask inside the static device info

Rather than deriving the gen_mask from the intel_device_static_info->gen at runtime, prefill it in the static data. add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-19 (-19) Function old new delta i915_driver_load50465027

[Intel-gfx] [PATCH 04/10] drm/i915: Move EDRAM capability bits to intel_device_runtime_info

Move the storage of the runtime discovery of EDRAM to intel_device_runtime_info so that we include it in all the relevant error state dumping and debugging. In the process, we introduce a new intel_device_runtime_info for storing all the write-once information about the device (as opposed to the

Re: [Intel-gfx] [RFC 00/15] Selectable platform support

Quoting Chris Wilson (2018-02-09 11:19:44) > Ideas? A long time ago, we wanted a static INTEL_INFO. I think now we > have driver_caps, we try to kill off mkwrite_intel_info() and where > need be use INTEL_INFO() && DRIVER_CAPS(). > > Tvrtko, how easy do you think it will be to go from Kconfig to

Re: [Intel-gfx] [PATCH v9 1/7] drm/i915/guc: Move GuC WOPCM related code into separate files

On 2/9/2018 11:38 AM, Yaodong Li wrote: On 02/09/2018 08:46 AM, Michal Wajdeczko wrote: --- /dev/null +++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c @@ -0,0 +1,48 @@ +/* + * SPDX-License-Identifier: MIT + * + * Copyright © 2017-2018 Intel Corporation + * Do we really want to keep legacy license

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/userptr: Probe vma range before gup (rev7)

== Series Details == Series: drm/i915/userptr: Probe vma range before gup (rev7) URL : https://patchwork.freedesktop.org/series/35394/ State : success == Summary == Series 35394v7 drm/i915/userptr: Probe vma range before gup

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Reduce context HW ID lifetime

Quoting Lionel Landwerlin (2018-02-09 17:47:44) > Hey Chris, > > From the i915/perf point of view, I'm fine with this change. > The pinning of the hw_id when monitoring a single context (with OA) > doesn't break the existing userspace (I can only think of Mesa). > > I'm also trying to build up

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Reduce context HW ID lifetime

Quoting Daniele Ceraolo Spurio (2018-02-09 18:56:36) > > > On 09/02/18 02:22, Chris Wilson wrote: > > Future gen reduce the number of bits we will have available to > > differentiate between contexts, so reduce the lifetime of the ID > > assignment from that of the context to its current active

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

On Fri, 09 Feb 2018 00:03:54 +0100, Jackie Li wrote: Few more comments in addition to Joonas/Chris GuC WOPCM registers are write-once registers. Current driver code accesses these registers without checking the accessibility to these registers which will lead to

Re: [Intel-gfx] [PATCH v9 1/7] drm/i915/guc: Move GuC WOPCM related code into separate files

On 02/09/2018 08:46 AM, Michal Wajdeczko wrote: --- /dev/null +++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c @@ -0,0 +1,48 @@ +/* + * SPDX-License-Identifier: MIT + * + * Copyright © 2017-2018 Intel Corporation + * Do we really want to keep legacy license text? Note that in other file

Re: [Intel-gfx] [PATCH v9 3/7] drm/i915/guc: Implement dynamic GuC WOPCM offset and size

On 02/09/2018 09:24 AM, Michal Wajdeczko wrote: +    struct intel_guc *guc = +    container_of(guc_wopcm, struct intel_guc, wopcm); If you define this as "wopcm_to_guc" inline helper, then maybe all your functions could take "wopcm" as first parameter? First thought is this is only one

[Intel-gfx] ✗ Fi.CI.IGT: warning for tests/kms_available_modes_crc: Test all modes on all planes

== Series Details == Series: tests/kms_available_modes_crc: Test all modes on all planes URL : https://patchwork.freedesktop.org/series/38004/ State : warning == Summary == Test kms_cursor_legacy: Subgroup flip-vs-cursor-legacy: pass -> FAIL (shard-hsw)

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Reduce context HW ID lifetime

On 09/02/18 02:22, Chris Wilson wrote: Future gen reduce the number of bits we will have available to differentiate between contexts, so reduce the lifetime of the ID assignment from that of the context to its current active cycle (i.e. only while it is pinned for use by the HW, will it have a

[Intel-gfx] [PATCH v3] drm/i915/icl: Update subslice define for ICL 11

From: Kelvin Gardiner ICL 11 has a greater number of maximum subslices. This patch reflects this. v2: GEN11 updates to MCR_SELECTOR (Oscar) v3: Copypasta error in the new defines (Lionel) Bspec: 21139 BSpec: 21108 Signed-off-by: Kelvin Gardiner

Re: [Intel-gfx] [PATCH] drm/i915: Improve PSR activation timing

On Fri, Feb 9, 2018 at 7:39 AM, Rodrigo Vivi wrote: > Rodrigo Vivi writes: > >> "Pandiyan, Dhinakaran" writes: >> >>> On Thu, 2018-02-08 at 14:48 -0800, Rodrigo Vivi wrote: Hi Andy, thanks for getting

Re: [Intel-gfx] [PATCH 2/6] drm/i915/icl: add the main CDCLK functions

On Tue, Feb 06, 2018 at 05:33:46PM -0200, Paulo Zanoni wrote: > This commit adds the basic CDCLK functions, but it's still missing > pieces of the display initialization sequence. > > v2: > - Implement the voltage levels. > - Rebase. > v3: > - Adjust to the new "bypass" clock (Imre). > - Call

Re: [Intel-gfx] [PATCH v2] drm/i915/icl: Update subslice define for ICL 11

On 09/02/18 17:44, Oscar Mateo wrote: On 02/08/2018 08:35 AM, Lionel Landwerlin wrote: On 11/01/18 18:25, Oscar Mateo wrote: From: Kelvin Gardiner ICL 11 has a greater number of maximum subslices. This patch reflects this. v2: GEN11 updates to MCR_SELECTOR

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Reduce context HW ID lifetime

Hey Chris, From the i915/perf point of view, I'm fine with this change. The pinning of the hw_id when monitoring a single context (with OA) doesn't break the existing userspace (I can only think of Mesa). I'm also trying to build up a system wide monitoring feature in GPUTop with a timeline

Re: [Intel-gfx] [PATCH v2] drm/i915/icl: Update subslice define for ICL 11

On 02/08/2018 08:35 AM, Lionel Landwerlin wrote: On 11/01/18 18:25, Oscar Mateo wrote: From: Kelvin Gardiner ICL 11 has a greater number of maximum subslices. This patch reflects this. v2: GEN11 updates to MCR_SELECTOR (Oscar) Bspec: 21139 BSpec: 21108

[Intel-gfx] ✓ Fi.CI.BAT: success for tests/kms_available_modes_crc: Test all modes on all planes

== Series Details == Series: tests/kms_available_modes_crc: Test all modes on all planes URL : https://patchwork.freedesktop.org/series/38004/ State : success == Summary == IGT patchset tested on top of latest successful build 3af87d45da24015b7a6124b59b2c4b854381cab6 tools/intel_aubdump:

Re: [Intel-gfx] [PATCH v9 3/7] drm/i915/guc: Implement dynamic GuC WOPCM offset and size

On Fri, 09 Feb 2018 00:03:51 +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 0/5] drm/i915: Grab the vblank evasion lock around the entire evasion.

Op 09-02-18 om 11:04 schreef Chris Wilson: > Quoting Maarten Lankhorst (2018-02-09 09:53:59) >> Some cleanups to move the uncore.lock around vblank evasion, so run >> to completion without racing on uncore.lock. Hopefully this will reduce >> the chance of underruns, and perhaps allows us to

Re: [Intel-gfx] [igt-dev] [PATCH igt] igt/pm_rc6_residency: Check debugfs existence before reading

On 09/02/18 06:30, Chris Wilson wrote: During the startup, we try to determine if the system supports rc6 prior to testing. However, the startup check asserts the residency debugfs exists, instead of testing for a requirement. Signed-off-by: Chris Wilson

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Fix incorrect comment

== Series Details == Series: drm/i915: Fix incorrect comment URL : https://patchwork.freedesktop.org/series/38002/ State : warning == Summary == Test gem_exec_suspend: Subgroup basic-s4: fail -> SKIP (shard-snb) fdo#103375 Test gem_eio: Subgroup

Re: [Intel-gfx] [PATCH v9 1/7] drm/i915/guc: Move GuC WOPCM related code into separate files

On Fri, 09 Feb 2018 00:03:49 +0100, Jackie Li wrote: intel_guc_reg.h should only include definition for GuC registers and related register bits. Non-register related GuC WOPCM macro definitions should not be defined in intel_guc_reg.h. This patch cleans up

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Move the final intel_gpu_reset() to after declaring wedged

== Series Details == Series: drm/i915: Move the final intel_gpu_reset() to after declaring wedged URL : https://patchwork.freedesktop.org/series/37997/ State : success == Summary == Test kms_flip: Subgroup flip-vs-expired-vblank-interruptible: fail -> PASS

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix incorrect comment

== Series Details == Series: drm/i915: Fix incorrect comment URL : https://patchwork.freedesktop.org/series/38002/ State : success == Summary == Series 38002v1 drm/i915: Fix incorrect comment https://patchwork.freedesktop.org/api/1.0/series/38002/revisions/1/mbox/ Test gem_mmap_gtt:

Re: [Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/snb+: Remove incorrect forcewake check in debugfs/i915_drpc_info

On Thu, Feb 08, 2018 at 08:44:04PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/snb+: Remove incorrect forcewake check in > debugfs/i915_drpc_info > URL : https://patchwork.freedesktop.org/series/37901/ > State : warning The warn is unrelated to the change see below.

Re: [Intel-gfx] [PATCH] drm/i915: Fix Limited Range Color Handling

On Fri, Feb 09, 2018 at 01:34:40PM +, Shankar, Uma wrote: > > > >-Original Message- > >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > >Sent: Wednesday, January 31, 2018 1:44 AM > >To: Shankar, Uma > >Cc: intel-gfx@lists.freedesktop.org; Lin,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Move the final intel_gpu_reset() to after declaring wedged

== Series Details == Series: drm/i915: Move the final intel_gpu_reset() to after declaring wedged URL : https://patchwork.freedesktop.org/series/37997/ State : success == Summary == Series 37997v1 drm/i915: Move the final intel_gpu_reset() to after declaring wedged

Re: [Intel-gfx] [RFC 14/15] drm/i915: Use new IS_GEN range helpers

On Fri, Feb 09, 2018 at 04:48:43PM +0200, Ville Syrjälä wrote: > On Fri, Feb 09, 2018 at 01:18:49PM +0200, Jani Nikula wrote: > > On Thu, 08 Feb 2018, Ville Syrjälä wrote: > > > On Thu, Feb 08, 2018 at 05:13:02PM +0200, Mika Kuoppala wrote: > > >> Chris Wilson

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Move EDRAM capability bits to intel_driver_caps

== Series Details == Series: drm/i915: Move EDRAM capability bits to intel_driver_caps URL : https://patchwork.freedesktop.org/series/37996/ State : failure == Summary == Series 37996v1 drm/i915: Move EDRAM capability bits to intel_driver_caps

Re: [Intel-gfx] [RFC 14/15] drm/i915: Use new IS_GEN range helpers

Quoting Ville Syrjälä (2018-02-09 14:48:43) > If only the compiler would be smart and be able to see that something > like > > #define INTEL_GEN(dev_priv) (ilog2((dev_priv)->gen_mask & CONFIG_GEN_MASK)) > > if (INTEL_GEN(dev_priv) < 8) > ... > > can never be true... > > Not sure it

Re: [Intel-gfx] [RFC 14/15] drm/i915: Use new IS_GEN range helpers

On Fri, Feb 09, 2018 at 01:18:49PM +0200, Jani Nikula wrote: > On Thu, 08 Feb 2018, Ville Syrjälä wrote: > > On Thu, Feb 08, 2018 at 05:13:02PM +0200, Mika Kuoppala wrote: > >> Chris Wilson writes: > >> > >> > Quoting Tvrtko Ursulin

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Rename drm_i915_gem_request to i915_request

== Series Details == Series: series starting with [1/2] drm/i915: Rename drm_i915_gem_request to i915_request URL : https://patchwork.freedesktop.org/series/37993/ State : failure == Summary == Series 37993v1 series starting with [1/2] drm/i915: Rename drm_i915_gem_request to i915_request

[Intel-gfx] [PATCH igt] igt/perf_pmu: Semaphores do not exists before gen6

We don't expect to be able to open the I915_SAMPLE_SEMA on gen5 and earlier as the HW doesn't support semaphores. Signed-off-by: Chris Wilson --- tests/perf_pmu.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/tests/perf_pmu.c

[Intel-gfx] [PATCH igt v2] igt/pm_rc6_residency: Check debugfs existence before reading

During the startup, we try to determine if the system supports rc6 prior to testing. However, the startup check asserts the residency debugfs exists, instead of testing for a requirement. Signed-off-by: Chris Wilson --- tests/pm_rc6_residency.c | 11 +++ 1 file

[Intel-gfx] [PATCH igt] igt/pm_rc6_residency: Check debugfs existence before reading

During the startup, we try to determine if the system supports rc6 prior to testing. However, the startup check asserts the residency debugfs exists, instead of testing for a requirement. Signed-off-by: Chris Wilson --- tests/pm_rc6_residency.c | 12 1

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Grab the vblank evasion lock around the entire evasion.

== Series Details == Series: drm/i915: Grab the vblank evasion lock around the entire evasion. URL : https://patchwork.freedesktop.org/series/37986/ State : failure == Summary == Series 37986v1 drm/i915: Grab the vblank evasion lock around the entire evasion.

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/userptr: Probe vma range before gup (rev7)

== Series Details == Series: drm/i915/userptr: Probe vma range before gup (rev7) URL : https://patchwork.freedesktop.org/series/35394/ State : failure == Summary == Series 35394v7 drm/i915/userptr: Probe vma range before gup

[Intel-gfx] [PATCH i-g-t] tests/kms_available_modes_crc: Test all modes on all planes

Ask from kernel about supported modes for each plane and try setting them on display and verify functionality with crc. DRM_FORMAT_ARGB and DRM_FORMAT_ABGR skip crc testing on primary and overlay planes because they produce incorrect crcs from hardware. DRM_FORMAT_ARGB is tested on

Re: [Intel-gfx] [PATCH] drm/i915: Fix Limited Range Color Handling

>-Original Message- >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] >Sent: Wednesday, January 31, 2018 1:44 AM >To: Shankar, Uma >Cc: intel-gfx@lists.freedesktop.org; Lin, Johnson ; >Syrjala, Ville ;

[Intel-gfx] [PATCH] drm/i915: Fix incorrect comment

While the comment singles out Port A or B, the code says Port A or *D*. Looking at the history it seems that the comment was added after the code, so it seems likely that the code is correct, not the comment. CC: Jani Nikula CC: Rodrigo Vivi

Re: [Intel-gfx] [PATCH] drm/i915: Move EDRAM capability bits to intel_driver_caps

On Fri, 09 Feb 2018, Chris Wilson wrote: > Quoting Chris Wilson (2018-02-09 11:29:08) >> Move the storage of the runtime discovery of EDRAM to intel_driver_caps >> so that we include it in all the relevant error state dumping and >> debugging. >> >> Signed-off-by: Chris

Re: [Intel-gfx] [RFC 00/15] Selectable platform support

Quoting Jani Nikula (2018-02-09 11:49:16) > On Thu, 08 Feb 2018, Joonas Lahtinen wrote: > > Quoting Tvrtko Ursulin (2018-02-08 16:06:41) > >> > >> On 08/02/2018 13:26, Chris Wilson wrote: > >> > Quoting Tvrtko Ursulin (2018-02-08 13:05:51) > >> >> From: Tvrtko

Re: [Intel-gfx] [RFC 00/15] Selectable platform support

On Thu, 08 Feb 2018, Joonas Lahtinen wrote: > Quoting Tvrtko Ursulin (2018-02-08 16:06:41) >> >> On 08/02/2018 13:26, Chris Wilson wrote: >> > Quoting Tvrtko Ursulin (2018-02-08 13:05:51) >> >> From: Tvrtko Ursulin >> >> >> >> For

[Intel-gfx] [PATCH igt 2/2] igt/gem_eio: Use slow spinners to inject hangs

One weird issue we see in bug 104676 is that the hangs are too fast on HSW! So force the use of the slow spinners that do not try to trigger a hang by injecting random bytes into the batch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104676 Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH igt 1/2] lib: force a reset on an uncooperative i915 device

Try to reset the GPU from within igt_require_gem() if we notice we are starting with a wedged device. If it remains wedged, the test definitely cannot run. We leave a warning in place to highlight the potentially suspect result, which will keep the flip-flops alive in CI! Signed-off-by: Chris

[Intel-gfx] [PATCH] drm/i915: Move the final intel_gpu_reset() to after declaring wedged

If we fail to reset the GPU (i915_reset()), we do one final intel_gpu_reset() attempt as we mark the device wedged. The idea here is even though the GPU has proven unreliable (and so we want to stop using it for the time being), we don't want it spinning away in the background whilst the driver

Re: [Intel-gfx] [RFC 00/15] Selectable platform support

On Fri, 09 Feb 2018, Tvrtko Ursulin wrote: > Anyway.. with the latest build the i915.ko size goes from 15600073 to > 1256697 when I enable only Skylake via Kconfig. This is 296kiB and close > to 20% saving. Those numbers look like 90+% saving to me. ;) BR,

Re: [Intel-gfx] [PATCH] drm/i915: Move EDRAM capability bits to intel_driver_caps

Quoting Chris Wilson (2018-02-09 11:29:08) > Move the storage of the runtime discovery of EDRAM to intel_driver_caps > so that we include it in all the relevant error state dumping and > debugging. > > Signed-off-by: Chris Wilson > --- > > Or do we want to keep

[Intel-gfx] [PATCH] drm/i915: Move EDRAM capability bits to intel_driver_caps

Move the storage of the runtime discovery of EDRAM to intel_driver_caps so that we include it in all the relevant error state dumping and debugging. Signed-off-by: Chris Wilson --- Or do we want to keep driver_caps only for driver related info, and move this sort of

Re: [Intel-gfx] [RFC 01/15] drm/i915: Make I830 platform support optional

On Thu, 08 Feb 2018, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Signed-off-by: Tvrtko Ursulin > --- > drivers/gpu/drm/i915/Kconfig | 5 + > drivers/gpu/drm/i915/Kconfig.platforms | 6 ++ >

Re: [Intel-gfx] [RFC 00/15] Selectable platform support

Quoting Tvrtko Ursulin (2018-02-09 11:01:08) > > On 09/02/18 10:50, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-02-09 10:48:23) > >> > >> On 08/02/2018 13:05, Tvrtko Ursulin wrote: > >>> From: Tvrtko Ursulin > >>> > >>> For Joonas basically. :) > >>> > >>>

Re: [Intel-gfx] [RFC 14/15] drm/i915: Use new IS_GEN range helpers

On Thu, 08 Feb 2018, Ville Syrjälä wrote: > On Thu, Feb 08, 2018 at 05:13:02PM +0200, Mika Kuoppala wrote: >> Chris Wilson writes: >> >> > Quoting Tvrtko Ursulin (2018-02-08 14:34:38) >> >> >> >> On 08/02/2018 14:22, Ville Syrjälä wrote:

Re: [Intel-gfx] [RFC 00/15] Selectable platform support

On 09/02/18 10:50, Chris Wilson wrote: > Quoting Tvrtko Ursulin (2018-02-09 10:48:23) >> >> On 08/02/2018 13:05, Tvrtko Ursulin wrote: >>> From: Tvrtko Ursulin >>> >>> For Joonas basically. :) >>> >>> Rough goal - add Kconfig options to turn off supported platforms and

Re: [Intel-gfx] [RFC 00/15] Selectable platform support

Quoting Tvrtko Ursulin (2018-02-09 10:48:23) > > On 08/02/2018 13:05, Tvrtko Ursulin wrote: > > From: Tvrtko Ursulin > > > > For Joonas basically. :) > > > > Rough goal - add Kconfig options to turn off supported platforms and count > > on > > compiler DCE to make

Re: [Intel-gfx] [RFC 00/15] Selectable platform support

On 08/02/2018 13:05, Tvrtko Ursulin wrote: From: Tvrtko Ursulin For Joonas basically. :) Rough goal - add Kconfig options to turn off supported platforms and count on compiler DCE to make the driver smaller. Tested as so much that it boots and renders on Skylake

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

Quoting Jackie Li (2018-02-09 01:03:54) > 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

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Enable VBT based BL control for DP (v2)

Hi Jani, May I know why the need to use connector as connector wasn't initialized in parent function ' intel_pps_get_registers'? While ' dev_priv' already initialized which also already initialized to the VBT value. So it make sense to me to use 'dev_priv' structure to read the VBT value

[Intel-gfx] [PATCH 2/2] drm/i915: Reduce context HW ID lifetime

Future gen reduce the number of bits we will have available to differentiate between contexts, so reduce the lifetime of the ID assignment from that of the context to its current active cycle (i.e. only while it is pinned for use by the HW, will it have a constant ID). This means that instead of a

Re: [Intel-gfx] [RFC 11/15] drm/i915: Use INTEL_GEN everywhere

Quoting Tvrtko Ursulin (2018-02-08 13:06:02) > From: Tvrtko Ursulin > > Coccinelle patch: > > @@ > identifier p; > @@ > -INTEL_INFO(p)->gen > +INTEL_GEN(p) > > Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson

Re: [Intel-gfx] [RFC 15/15] drm/i915: Replace some negative Gen checks

Quoting Tvrtko Ursulin (2018-02-08 13:06:06) > From: Tvrtko Ursulin > > Instead of INTEL_GEN != x use !IS_GENx for more optimisation > opportunities. > > Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson

Re: [Intel-gfx] [RFC 15/15] drm/i915: Replace some negative Gen checks

On Thu, 08 Feb 2018, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Instead of INTEL_GEN != x use !IS_GENx for more optimisation > opportunities. This could be upstreamed outside of this series. BR, Jani. > > Signed-off-by: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH] drm/i915: Rename drm_i915_gem_request to i915_request

Chris Wilson writes: > Quoting Joonas Lahtinen (2018-02-09 07:48:21) >> Quoting Chris Wilson (2018-02-09 01:11:34) >> > We want to de-emphasize the link between the request (dependency, >> > execution and fence tracking) from GEM and so rename the struct from >> >

Re: [Intel-gfx] [RFC 11/15] drm/i915: Use INTEL_GEN everywhere

On Thu, 08 Feb 2018, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Coccinelle patch: > > @@ > identifier p; > @@ > -INTEL_INFO(p)->gen > +INTEL_GEN(p) > > Signed-off-by: Tvrtko Ursulin I think you should get this

Re: [Intel-gfx] [PATCH 0/5] drm/i915: Grab the vblank evasion lock around the entire evasion.

Quoting Maarten Lankhorst (2018-02-09 09:53:59) > Some cleanups to move the uncore.lock around vblank evasion, so run > to completion without racing on uncore.lock. Hopefully this will reduce > the chance of underruns, and perhaps allows us to decrease > VBLANK_EVASION_TIME_US as well as a

Re: [Intel-gfx] [PATCH v9 5/7] drm/i915/guc: Add HuC firmware size related restriction for Gen9 and CNL A0

Quoting Jackie Li (2018-02-09 01:03:53) > 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 verfication code to ensure the available GuC WOPCM size > to be larger than or equal

[Intel-gfx] [PATCH 0/5] drm/i915: Grab the vblank evasion lock around the entire evasion.

Some cleanups to move the uncore.lock around vblank evasion, so run to completion without racing on uncore.lock. Hopefully this will reduce the chance of underruns, and perhaps allows us to decrease VBLANK_EVASION_TIME_US as well as a followup patch. Tested on KBL and BSW. Maarten Lankhorst

[Intel-gfx] [PATCH 3/5] drm/i915: Call i915_pipe_update_start with uncore.lock held.

This requires being able to read the vblank counter with the uncore.lock already held. This is also a preparation for being able to run the entire vblank update sequence with the uncore lock held. Signed-off-by: Maarten Lankhorst ---

  1   2   >