[Intel-gfx] [PATCH] drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.

If bios sets up an MST output and hardware state readout code sees this is an SST configuration, when disabling the encoder we end up calling ->post_disable_dp() hook instead of the MST version. Consequently, we write to the DP_SET_POWER dpcd to set it D3 state. Further along when we try enable

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v13,1/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

== Series Details == Series: series starting with [v13,1/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset URL : https://patchwork.freedesktop.org/series/39919/ State : failure == Summary == Possible new issues: Test drv_missed_irq: pass -> SKIP

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Kill scheduled work for Core platforms. (rev2)

== Series Details == Series: drm/i915/psr: Kill scheduled work for Core platforms. (rev2) URL : https://patchwork.freedesktop.org/series/39650/ State : success == Summary == Known issues: Test kms_atomic_transition: Subgroup 1x-modeset-transitions: pass ->

[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

== Series Details == Series: drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses URL : https://patchwork.freedesktop.org/series/39911/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-contexts: pass -> INCOMPLETE (shard-apl)

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/psr: Move PSR aux setup to it's own function.

== Series Details == Series: series starting with [1/2] drm/i915/psr: Move PSR aux setup to it's own function. URL : https://patchwork.freedesktop.org/series/39825/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-contexts: pass

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v13,1/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

== Series Details == Series: series starting with [v13,1/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset URL : https://patchwork.freedesktop.org/series/39919/ State : success == Summary == Series 39919v1 series starting with [v13,1/6] drm/i915/guc: Rename guc_ggtt_offset to

[Intel-gfx] [PATCH v13 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 v13 1/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

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 for future patches that needs to access intel_guc data to verify the GGTT

[Intel-gfx] [PATCH v13 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

[Intel-gfx] [PATCH v13 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 v13 6/6] HAX Enable GuC Submission for CI

Signed-off-by: Jackie Li --- drivers/gpu/drm/i915/i915_params.c | 2 +- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_uc.c| 2 ++ 3 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c

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

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 size can be calculated correctly for CNL. v9: - Created a new patch for these

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Kill scheduled work for Core platforms. (rev2)

== Series Details == Series: drm/i915/psr: Kill scheduled work for Core platforms. (rev2) URL : https://patchwork.freedesktop.org/series/39650/ State : success == Summary == Series 39650v2 drm/i915/psr: Kill scheduled work for Core platforms.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

== Series Details == Series: drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses URL : https://patchwork.freedesktop.org/series/39911/ State : success == Summary == Series 39911v1 drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

Re: [Intel-gfx] [PATCH v3 1/5] drm/i915: Move DP modeset retry work into intel_dp

On Mon, 2018-03-12 at 23:01 +0200, Ville Syrjälä wrote: > On Fri, Mar 09, 2018 at 04:32:27PM -0500, Lyude Paul wrote: > > While having the modeset_retry_work in intel_connector makes sense with > > SST, this paradigm doesn't make a whole ton of sense when it comes to > > MST since we have to deal

[Intel-gfx] [CI] drm/i915: Split GPU commands definitions into separate header

From: Michal Wajdeczko We should not mix MMIO with MI_INSTR definitions. v2: sanitize comment, change include order (Chris) Suggested-by: Chris Wilson Signed-off-by: Michal Wajdeczko Cc: Chris Wilson

Re: [Intel-gfx] [PATCH v3 2/5] drm/i915: Only use one link bw config for MST topologies

On Mon, 2018-03-12 at 13:45 -0700, Manasi Navare wrote: > On Fri, Mar 09, 2018 at 04:32:28PM -0500, Lyude Paul wrote: > > When a DP MST link needs retraining, sometimes the hub will detect that > > the current link bw config is impossible and will update it's RX caps in > > the DPCD to reflect the

[Intel-gfx] [PATCH] drm/i915/glk: Disable Guc and HuC on GLK

commit 2afba81c7909ac259720c0d3e7616cf54d4a5368 upstream for linux stable 4.14. Since the firmwares are not yet released to public repo, disable them on Geminilake. v2: Remove the firmware versions (Michal) v3: Remove unwanted defines (Rodrigo) Correct commit message (Michal) Cc: Michal

[Intel-gfx] [PATCH] drm/i915/glk: Disable Guc and HuC on GLK

From: Anusha Srivatsa commit 2afba81c7909ac259720c0d3e7616cf54d4a5368 upstream. for linux stable 4.15. Since the firmwares are not yet released to public repo, disable them on Geminilake. v2: Remove the firmware versions (Michal) v3: Remove unwanted defines

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/psr: Move PSR aux setup to it's own function.

== Series Details == Series: series starting with [1/2] drm/i915/psr: Move PSR aux setup to it's own function. URL : https://patchwork.freedesktop.org/series/39825/ State : success == Summary == Series 39825v1 series starting with [1/2] drm/i915/psr: Move PSR aux setup to it's own function.

Re: [Intel-gfx] [PATCH] drm/i915/glk: Disable Guc and HuC on GLK

On Tue, Mar 13, 2018 at 09:46:32AM +0100, Greg KH wrote: > On Mon, Mar 12, 2018 at 03:34:57PM -0700, Rodrigo Vivi wrote: > > From: Anusha Srivatsa > > > > commit 2afba81c7909ac259720c0d3e7616cf54d4a5368 upstream. > > > > Since the firmwares are not yet released to

Re: [Intel-gfx] [PATCH] drm/i915/psr: Comment to clarify SRD_DEBUG is called PSR_MASK SKL+

On Tue, Mar 13, 2018 at 03:25:51PM -0700, Rodrigo Vivi wrote: > On Mon, Mar 12, 2018 at 09:09:54PM -0700, Dhinakaran Pandiyan wrote: > > What was called SRD_DEBUG(0x6F860) on HSW and BDW was renamed to PSR_MASK > > SKL onwards, add a note next to the macro definition. > > There is also a different

Re: [Intel-gfx] [PATCH] drm/i915/psr: Comment to clarify SRD_DEBUG is called PSR_MASK SKL+

On Mon, Mar 12, 2018 at 09:09:54PM -0700, Dhinakaran Pandiyan wrote: > What was called SRD_DEBUG(0x6F860) on HSW and BDW was renamed to PSR_MASK > SKL onwards, add a note next to the macro definition. > There is also a different PSR_DEBUG on SKL+ to add to the confusion. > > Signed-off-by:

[Intel-gfx] [RFC v5] drm/i915/psr: Kill scheduled work for Core platforms.

The immediate enabling is actually not an issue for the HW perspective for core platforms that have HW tracking. HW will wait few identical idle frames before transitioning to actual psr active anyways. Note that this patch also remove the delayed activation on HSW and BDW introduced by commit

Re: [Intel-gfx] [PATCH v3 1/6] cgroup: Allow registration and lookup of cgroup private data

Hello, On Tue, Mar 13, 2018 at 02:47:45PM -0700, Alexei Starovoitov wrote: > it has to be zero lookups. If idr lookup is involved, it's cleaner > to add idr as new bpf map type and use cgroup ino as an id. Oh, idr (or rather ida) is just to allocate the key, once the key is there it pretty much

[Intel-gfx] [PATCH] drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses

drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary arguments that can be removed by creating separate functins. Create specific functions for these calls to reduce x86/64 defconfig size by ~20k. Modify the existing macros to use the specific calls. new: $ size -t

Re: [Intel-gfx] [PATCH] drm/i915: Move CUR_SURFLIFE definition to a better place.

On Mon, Mar 12, 2018 at 10:35:30PM +0200, Ville Syrjälä wrote: > On Mon, Mar 12, 2018 at 01:27:03PM -0700, Rodrigo Vivi wrote: > > No functional change. But let's keep definitions clean > > and cursor related register definitions together. > > > > Suggested-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/psr: Use more PSR HW tracking.

On Tue, Mar 13, 2018 at 12:58:59AM +, Souza, Jose wrote: > On Mon, 2018-03-12 at 16:19 -0700, Pandiyan, Dhinakaran wrote: > > On Mon, 2018-03-12 at 23:16 +, Souza, Jose wrote: > > > What if FBC is disabled? Or FBC can not be activate by any of the > > > reasons in intel_fbc_can_activate().

Re: [Intel-gfx] [PATCH v3 1/6] cgroup: Allow registration and lookup of cgroup private data

Hello, Matt. cc'ing Roman and Alexei. On Tue, Mar 06, 2018 at 03:46:55PM -0800, Matt Roper wrote: > There are cases where other parts of the kernel may wish to store data > associated with individual cgroups without building a full cgroup > controller. Let's add interfaces to allow them to

Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr: Remove open-coded PSR AUX transactions for SKL+

On Mon, 2018-03-12 at 20:46 -0700, Dhinakaran Pandiyan wrote: > HSW and BDW have SRD_AUX_{CTL, STATUS} registers that the driver > needs to > setup for the HW to use whenever exiting PSR. SKL+ hardware use > hardcoded > values for the same and do not need any registers to be setup. So, > use >

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/cnl: Kill _MMIO_PORT6 macro

On Tue, Mar 13, 2018 at 09:46:22AM +0530, Mahesh Kumar wrote: > This patch replaces use of remaining _MMIO_PORT6 macro and removes the > macro. > > Signed-off-by: Mahesh Kumar > Reviewed-by: Rodrigo Vivi Sorry, but I noticed one more thing here

Re: [Intel-gfx] [PATCH v3 3/6] cgroup: Introduce cgroup_permission()

On Tue, Mar 06, 2018 at 03:46:57PM -0800, Matt Roper wrote: > Non-controller kernel subsystems may base access restrictions for > cgroup-related syscalls/ioctls on a process' access to the cgroup. > Let's make it easy for other parts of the kernel to check these cgroup > permissions. I'm not sure

Re: [Intel-gfx] [PATCH v3 2/6] cgroup: Introduce task_get_dfl_cgroup()

(cc'ing Roman) Hello, On Tue, Mar 06, 2018 at 03:46:56PM -0800, Matt Roper wrote: > +static inline struct cgroup * > +task_get_dfl_cgroup(struct task_struct *task) > +{ > + struct cgroup *cgrp; > + > + mutex_lock(_mutex); > + cgrp = task_dfl_cgroup(task); > + cgroup_get(cgrp); >

Re: [Intel-gfx] [PATCH] [v2] drm/i915/pmu: avoid -Wmaybe-uninitialized warning

On Tue, Mar 13, 2018 at 6:46 PM, Tvrtko Ursulin wrote: > > On 13/03/2018 16:19, Arnd Bergmann wrote: >> >> The conditional spinlock confuses gcc into thinking the 'flags' value >> might contain uninitialized data: >> >> drivers/gpu/drm/i915/i915_pmu.c: In function

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915/psr: Move PSR aux setup to it's own function.

== Series Details == Series: series starting with [1/2] drm/i915/psr: Move PSR aux setup to it's own function. URL : https://patchwork.freedesktop.org/series/39825/ State : warning == Summary == Series 39825v1 series starting with [1/2] drm/i915/psr: Move PSR aux setup to it's own function.

Re: [Intel-gfx] [PATCH 3/3] drm: Store the calculated vrefresh in the user mode

Op 13-03-18 om 16:07 schreef Ville Syrjala: > From: Ville Syrjälä > > Ignore the vrefresh in the mode the user passed in and instead > calculate the value based on the actual timings. This way we can > actually trust mode->vrefresh to some degree. > > Or should we

Re: [Intel-gfx] [RFC] drm/i915/psr: Remove PSR active flag from debugfs

On Tue, Mar 13, 2018 at 10:20:58AM -0700, Souza, Jose wrote: > On Mon, 2018-03-12 at 21:42 -0700, Dhinakaran Pandiyan wrote: > > The flag becomes misleading with flips and cursor moves not modifying > > it's > > state as HW takes care of exiting PSR (when HW tracking is enabled) > > > > Cc:

Re: [Intel-gfx] [PATCH] [v2] drm/i915/pmu: avoid -Wmaybe-uninitialized warning

On 13/03/2018 16:19, Arnd Bergmann wrote: The conditional spinlock confuses gcc into thinking the 'flags' value might contain uninitialized data: drivers/gpu/drm/i915/i915_pmu.c: In function '__i915_pmu_event_read': arch/x86/include/asm/paravirt_types.h:573:3: error: 'flags' may be used

Re: [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/pmu: avoid -Wmaybe-uninitialized warning (rev2)

Quoting Tvrtko Ursulin (2018-03-13 17:41:59) > > On 13/03/2018 16:46, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915/pmu: avoid -Wmaybe-uninitialized warning (rev2) > > URL : https://patchwork.freedesktop.org/series/39857/ > > State : warning > > > > == Summary == > > > >

Re: [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/pmu: avoid -Wmaybe-uninitialized warning (rev2)

On 13/03/2018 16:46, Patchwork wrote: == Series Details == Series: drm/i915/pmu: avoid -Wmaybe-uninitialized warning (rev2) URL : https://patchwork.freedesktop.org/series/39857/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/pmu: avoid -Wmaybe-uninitialized

[Intel-gfx] ✗ Fi.CI.BAT: warning for HACK: enable the chamelium HDMI-CRC-multiple test

== Series Details == Series: HACK: enable the chamelium HDMI-CRC-multiple test URL : https://patchwork.freedesktop.org/series/39872/ State : warning == Summary == IGT patchset tested on top of latest successful build 1bb3995eb6dba8e43981e0378e1c6eea3f730a0f tests/i915_query: fix expected

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm: Nuke the useless 'ret' variable from drm_mode_convert_umode()

== Series Details == Series: series starting with [1/3] drm: Nuke the useless 'ret' variable from drm_mode_convert_umode() URL : https://patchwork.freedesktop.org/series/39875/ State : success == Summary == Possible new issues: Test kms_cursor_crc: Subgroup

Re: [Intel-gfx] [RFC] drm/i915/psr: Remove PSR active flag from debugfs

On Mon, 2018-03-12 at 21:42 -0700, Dhinakaran Pandiyan wrote: > The flag becomes misleading with flips and cursor moves not modifying > it's > state as HW takes care of exiting PSR (when HW tracking is enabled) > > Cc: Rodrigo Vivi > Signed-off-by: Dhinakaran Pandiyan

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915/psr: Move PSR aux setup to it's own function.

On Tue, 2018-03-13 at 04:23 +, Patchwork wrote: > == Series Details == > > Series: series starting with [1/2] drm/i915/psr: Move PSR aux setup to it's > own function. > URL : https://patchwork.freedesktop.org/series/39825/ > State : warning > > == Summary == > > Series 39825v1 series

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/3] drm: Add the optional .fb_modifier() hook (rev2)

On Tue, Mar 13, 2018 at 04:56:52PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [v2,1/3] drm: Add the optional .fb_modifier() > hook (rev2) > URL : https://patchwork.freedesktop.org/series/39813/ > State : failure > > == Summary == > > Possible new

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/pmu: avoid -Wmaybe-uninitialized warning (rev2)

== Series Details == Series: drm/i915/pmu: avoid -Wmaybe-uninitialized warning (rev2) URL : https://patchwork.freedesktop.org/series/39857/ State : warning == Summary == Series 39857v2 drm/i915/pmu: avoid -Wmaybe-uninitialized warning

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/3] drm: Add the optional .fb_modifier() hook (rev2)

== Series Details == Series: series starting with [v2,1/3] drm: Add the optional .fb_modifier() hook (rev2) URL : https://patchwork.freedesktop.org/series/39813/ State : failure == Summary == Possible new issues: Test kms_cursor_crc: Subgroup cursor-64x64-suspend:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/pmu: avoid -Wmaybe-uninitialized warning (rev2)

== Series Details == Series: drm/i915/pmu: avoid -Wmaybe-uninitialized warning (rev2) URL : https://patchwork.freedesktop.org/series/39857/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/pmu: avoid -Wmaybe-uninitialized warning

Re: [Intel-gfx] [PATCH] [v2] drm/i915/pmu: avoid -Wmaybe-uninitialized warning

Quoting Arnd Bergmann (2018-03-13 16:19:31) > The conditional spinlock confuses gcc into thinking the 'flags' value > might contain uninitialized data: > > drivers/gpu/drm/i915/i915_pmu.c: In function '__i915_pmu_event_read': > arch/x86/include/asm/paravirt_types.h:573:3: error: 'flags' may be

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

Failed to receive this mail for 5/6 patch (couldn't find it in my mailbox). So pasted the comments from patchwork. Quoting Jackie Li (2018-03-02 02:16:45) > +++ b/drivers/gpu/drm/i915/intel_wopcm.c > @@ -219,3 +219,67 @@ int intel_wopcm_init(struct intel_wopcm *wopcm) > > return 0; >

[Intel-gfx] [PATCH] [v2] drm/i915/pmu: avoid -Wmaybe-uninitialized warning

The conditional spinlock confuses gcc into thinking the 'flags' value might contain uninitialized data: drivers/gpu/drm/i915/i915_pmu.c: In function '__i915_pmu_event_read': arch/x86/include/asm/paravirt_types.h:573:3: error: 'flags' may be used uninitialized in this function

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm: Nuke the useless 'ret' variable from drm_mode_convert_umode()

== Series Details == Series: series starting with [1/3] drm: Nuke the useless 'ret' variable from drm_mode_convert_umode() URL : https://patchwork.freedesktop.org/series/39875/ State : success == Summary == Series 39875v1 series starting with [1/3] drm: Nuke the useless 'ret' variable from

Re: [Intel-gfx] [PATCH 1/3] drm: Nuke the useless 'ret' variable from drm_mode_convert_umode()

On Tue, Mar 13, 2018 at 05:07:57PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > No need to store the return value in a variable since we don't have to > do any unwinding. > > Signed-off-by: Ville Syrjälä Reviewed-by:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm: Add the optional .fb_modifier() hook (rev2)

== Series Details == Series: series starting with [v2,1/3] drm: Add the optional .fb_modifier() hook (rev2) URL : https://patchwork.freedesktop.org/series/39813/ State : success == Summary == Series 39813v2 series starting with [v2,1/3] drm: Add the optional .fb_modifier() hook

Re: [Intel-gfx] [PATCH v2 1/3] drm: Add the optional .fb_modifier() hook

On Tue, Mar 13, 2018 at 04:35:02PM +0100, Michel Dänzer wrote: > On 2018-03-13 04:20 PM, Daniel Vetter wrote: > > On Tue, Mar 13, 2018 at 03:38:38PM +0100, Michel Dänzer wrote: > >> On 2018-03-13 03:28 PM, Ville Syrjala wrote: > >>> From: Ville Syrjälä > >>> > >>>

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v3,1/4] drm/i915/uc: Use correct error code for GuC initialization failure

== Series Details == Series: series starting with [v3,1/4] drm/i915/uc: Use correct error code for GuC initialization failure URL : https://patchwork.freedesktop.org/series/39867/ State : warning == Summary == Series 39867v1 series starting with [v3,1/4] drm/i915/uc: Use correct error code

[Intel-gfx] [PATCH 4.14 057/140] drm/i915/perf: fix perf stream opening lock

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Lionel Landwerlin commit f616f2830c1ed79245cfeca900f7e8a3b3c08c06 upstream. We're seeing on CI that some contexts don't have the programmed OA period timer that

Re: [Intel-gfx] [PATCH v2 1/3] drm: Add the optional .fb_modifier() hook

On 2018-03-13 04:20 PM, Daniel Vetter wrote: > On Tue, Mar 13, 2018 at 03:38:38PM +0100, Michel Dänzer wrote: >> On 2018-03-13 03:28 PM, Ville Syrjala wrote: >>> From: Ville Syrjälä >>> >>> To make it possible for the core to check the fb pixel format and >>>

[Intel-gfx] [PATCH 4.15 016/146] drm/i915/perf: fix perf stream opening lock

4.15-stable review patch. If anyone has any objections, please let me know. -- From: Lionel Landwerlin commit f616f2830c1ed79245cfeca900f7e8a3b3c08c06 upstream. We're seeing on CI that some contexts don't have the programmed OA period timer that

[Intel-gfx] [PATCH 4.15 010/146] drm/i915/audio: fix check for av_enc_map overflow

4.15-stable review patch. If anyone has any objections, please let me know. -- From: Jani Nikula commit 72a6d72c2cd03bba7b70117b63dea83d2de88057 upstream. Turns out -1 >= ARRAY_SIZE() is always true. Move the bounds check where we know pipe >= 0 and

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/dp: Fix intel_edp_compare_alt_mode. (rev2)

== Series Details == Series: drm/i915/dp: Fix intel_edp_compare_alt_mode. (rev2) URL : https://patchwork.freedesktop.org/series/39841/ State : warning == Summary == Series 39841v2 drm/i915/dp: Fix intel_edp_compare_alt_mode.

Re: [Intel-gfx] [RFC PATCH i-g-t 3/3] tests: Add vc4 test suite

Hi, On Tue, Mar 13, 2018 at 12:42:02PM +0200, Petri Latvala wrote: > On Mon, Mar 05, 2018 at 03:21:29PM +0100, Maxime Ripard wrote: > > Add some various test suites relevant for the vc4 drm driver. > > > > Signed-off-by: Maxime Ripard > > --- > >

Re: [Intel-gfx] [PATCH v2 1/3] drm: Add the optional .fb_modifier() hook

On Tue, Mar 13, 2018 at 03:38:38PM +0100, Michel Dänzer wrote: > On 2018-03-13 03:28 PM, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > To make it possible for the core to check the fb pixel format and > > modifier, we need to first ask the driver to deduce

Re: [Intel-gfx] [PATCH v2 1/3] drm: Add the optional .fb_modifier() hook

On 2018-03-13 04:12 PM, Ville Syrjälä wrote: > On Tue, Mar 13, 2018 at 03:38:38PM +0100, Michel Dänzer wrote: >> On 2018-03-13 03:28 PM, Ville Syrjala wrote: >>> From: Ville Syrjälä >>> >>> To make it possible for the core to check the fb pixel format and >>>

Re: [Intel-gfx] [PATCH v2 1/3] drm: Add the optional .fb_modifier() hook

On Tue, Mar 13, 2018 at 03:38:38PM +0100, Michel Dänzer wrote: > On 2018-03-13 03:28 PM, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > To make it possible for the core to check the fb pixel format and > > modifier, we need to first ask the driver to deduce

Re: [Intel-gfx] [RFC v3 09/12] drm: Add API for in-kernel clients

On Mon, Mar 12, 2018 at 09:21:40PM +0100, Noralf Tr??nnes wrote: > > Den 12.03.2018 17.51, skrev Daniel Vetter: > > On Thu, Mar 08, 2018 at 06:12:11PM +0100, Noralf Tr??nnes wrote: > > > Den 06.03.2018 09.56, skrev Daniel Vetter: > > > > On Thu, Feb 22, 2018 at 09:06:50PM +0100, Noralf Tr??nnes

Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix alt mode handling.

On Tue, Mar 13, 2018 at 03:37:05PM +0100, Maarten Lankhorst wrote: > Op 13-03-18 om 15:27 schreef Ville Syrjälä: > > On Tue, Mar 13, 2018 at 02:52:35PM +0100, Maarten Lankhorst wrote: > >> On fi-cnl-y3 we have 2 modes that differ only by crtc_clock. This means > >> that if we request the normal

[Intel-gfx] [PATCH 2/3] drm: Make drm_mode_vrefresh() a bit more accurate

From: Ville Syrjälä Do the refresh rate calculation with a single division. This gives us slightly more accurate results, especially for interlaced since we don't just double the final truncated result. We do lose one bit compared to the old way, so with an

[Intel-gfx] [PATCH 3/3] drm: Store the calculated vrefresh in the user mode

From: Ville Syrjälä Ignore the vrefresh in the mode the user passed in and instead calculate the value based on the actual timings. This way we can actually trust mode->vrefresh to some degree. Or should we compare the user's idea of vrefresh with the one we get

[Intel-gfx] [PATCH 1/3] drm: Nuke the useless 'ret' variable from drm_mode_convert_umode()

From: Ville Syrjälä No need to store the return value in a variable since we don't have to do any unwinding. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_modes.c | 15 --- 1 file changed, 4 insertions(+), 11

Re: [Intel-gfx] [DIM PATCH 2/3] dim: add checkpatch profiles to allow different checkpatch options

On Tue, 13 Mar 2018, Daniel Vetter wrote: > On Tue, Mar 13, 2018 at 01:30:09PM +0200, Jani Nikula wrote: >> To reduce noise on CI checkpatch reports, we want to silence some >> checkpatch warnings. Different branches may end up having different >> rules, and users may want to get

Re: [Intel-gfx] [RFC PATCH i-g-t 2/3] tests/chamelium: Add test case for plane formats

Hi Eric, On Mon, Mar 12, 2018 at 12:02:26PM -0700, Eric Anholt wrote: > > +static pixman_image_t *convert_frame_format(pixman_image_t *src, > > + int format) > > +{ > > + pixman_image_t *converted; > > + unsigned int w = pixman_image_get_width(src); > > +

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/guc: Update syntax of GuC log functions

== Series Details == Series: drm/i915/guc: Update syntax of GuC log functions URL : https://patchwork.freedesktop.org/series/39859/ State : warning == Summary == Series 39859v1 drm/i915/guc: Update syntax of GuC log functions

[Intel-gfx] [PATCH i-g-t] HACK: enable the chamelium HDMI-CRC-multiple test

It seems like there's a regression (at least using the vc4 DRM display driver) when doing multiple calls to tests/kms_chamelium.c enable_output after a single prepare_output. Indeed, the DRM atomic_state doesn't seem to be full on the second run, especially for the CRTC that doesn't have any

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/pmu: avoid -Wmaybe-uninitialized warning

== Series Details == Series: drm/i915/pmu: avoid -Wmaybe-uninitialized warning URL : https://patchwork.freedesktop.org/series/39857/ State : success == Summary == Known issues: Test drv_selftest: Subgroup live_gtt: pass -> INCOMPLETE (shard-apl) fdo#103927

Re: [Intel-gfx] [PATCH v2 1/3] drm: Add the optional .fb_modifier() hook

On 2018-03-13 03:28 PM, Ville Syrjala wrote: > From: Ville Syrjälä > > To make it possible for the core to check the fb pixel format and > modifier, we need to first ask the driver to deduce the modifier > when the request does not explicitly specify one. > > Add

Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix alt mode handling.

Op 13-03-18 om 15:27 schreef Ville Syrjälä: > On Tue, Mar 13, 2018 at 02:52:35PM +0100, Maarten Lankhorst wrote: >> On fi-cnl-y3 we have 2 modes that differ only by crtc_clock. This means >> that if we request the normal mode, we automatically get the downclocked >> mode. >> >> This can be seen

[Intel-gfx] [PATCH v2 1/3] drm: Add the optional .fb_modifier() hook

From: Ville Syrjälä To make it possible for the core to check the fb pixel format and modifier, we need to first ask the driver to deduce the modifier when the request does not explicitly specify one. Add a new .fb_modifier() hook for that purpose and convert i915

Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix alt mode handling.

On Tue, Mar 13, 2018 at 02:52:35PM +0100, Maarten Lankhorst wrote: > On fi-cnl-y3 we have 2 modes that differ only by crtc_clock. This means > that if we request the normal mode, we automatically get the downclocked > mode. > > This can be seen during boot: >

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use sseu size for determining eu_regs[]

== Series Details == Series: drm/i915: Use sseu size for determining eu_regs[] URL : https://patchwork.freedesktop.org/series/39853/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-contexts: pass -> INCOMPLETE (shard-apl)

[Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

Exercise some new API that allows applications to request that individual contexts are executed within a desired frequency range. v2: Split single/continuous set_freq subtests v3: Do an up/down ramp for individual freq request, check nothing changes after each invalid request v4: Check the

[Intel-gfx] [PATCH v3 3/4] drm/i915/uc: Trivial s/dev_priv/i915 in intel_uc.c

Some functions already use i915 name instead of dev_priv. Let's rename this param in all remaining functions, except those that still use legacy macros. Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/intel_uc.c | 122

[Intel-gfx] [PATCH v3 4/4] HAX: Enable GuC for CI

v2: except running with HYPERVISOR Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_uc.c| 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h

[Intel-gfx] [PATCH v3 2/4] drm/i915/uc: Use helper functions to detect fw load status

We don't have to check load status values. Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_huc.c | 2 +- drivers/gpu/drm/i915/intel_uc.c | 4 ++-- 2 files

[Intel-gfx] [PATCH v3 1/4] drm/i915/uc: Use correct error code for GuC initialization failure

Since commit 6ca9a2beb54a ("drm/i915: Unwind i915_gem_init() failure") we believed that we correctly handle all errors encountered during GuC initialization, including special one that indicates request to run driver with disabled GPU submission (-EIO). Unfortunately since commit 121981fafe69

[Intel-gfx] [PATCH] drm/i915/dp: Fix alt mode handling.

On fi-cnl-y3 we have 2 modes that differ only by crtc_clock. This means that if we request the normal mode, we automatically get the downclocked mode. This can be seen during boot: [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:101:eDP-1] probed modes :

Re: [Intel-gfx] [PATCH v2] drm/i915: Show GEM_TRACE when detecting a failed GPU idle

Quoting Chris Wilson (2018-03-09 12:11:14) > If we timeout waiting for the GPU to idle, something went seriously > wrong. We currently dump the engine state, but we can also dump the > ftrace buffer showing our last operations (when available). > > In passing, note that since commit 559e040f1f08

[Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

Exercise some new API that allows applications to request that individual contexts are executed within a desired frequency range. v2: Split single/continuous set_freq subtests v3: Do an up/down ramp for individual freq request, check nothing changes after each invalid request v4: Check the

Re: [Intel-gfx] [PATCH] drm/i915: Reword warning for missing cases

On Tue, Mar 13, 2018 at 01:06:49PM +, Chris Wilson wrote: > Quoting Ville Syrjälä (2018-03-13 13:01:42) > > On Tue, Mar 13, 2018 at 12:17:13AM +, Chris Wilson wrote: > > > Quoting Lucas De Marchi (2018-03-13 00:03:12) > > > > In some places we end up converting switch statements to a

Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix intel_edp_compare_alt_mode.

On Tue, Mar 13, 2018 at 10:28:55AM +0100, Maarten Lankhorst wrote: > On fi-cnl-y3 we have 2 modes that differ only by crtc_clock. This means > that if we request the normal mode, we automatically get the downclocked > mode. > > This can be seen during boot: >

Re: [Intel-gfx] [PATCH] drm/i915: Reword warning for missing cases

Quoting Ville Syrjälä (2018-03-13 13:01:42) > On Tue, Mar 13, 2018 at 12:17:13AM +, Chris Wilson wrote: > > Quoting Lucas De Marchi (2018-03-13 00:03:12) > > > In some places we end up converting switch statements to a series of > > > if/else, particularly when introducing helper functions to

Re: [Intel-gfx] [PATCH] drm/i915: Reword warning for missing cases

On Tue, Mar 13, 2018 at 12:17:13AM +, Chris Wilson wrote: > Quoting Lucas De Marchi (2018-03-13 00:03:12) > > In some places we end up converting switch statements to a series of > > if/else, particularly when introducing helper functions to handle a > > group of cases. It's tempting to either

Re: [Intel-gfx] [PATCH] drm/i915/pmu: avoid -Wmaybe-uninitialized warning

On Tue, Mar 13, 2018 at 1:31 PM, Chris Wilson wrote: > Quoting Arnd Bergmann (2018-03-13 12:08:29) >> The conditional spinlock confuses gcc into thinking the 'flags' value >> might contain uninitialized data: >> >> drivers/gpu/drm/i915/i915_pmu.c: In function

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: avoid -Wmaybe-uninitialized warning

== Series Details == Series: drm/i915/pmu: avoid -Wmaybe-uninitialized warning URL : https://patchwork.freedesktop.org/series/39857/ State : success == Summary == Series 39857v1 drm/i915/pmu: avoid -Wmaybe-uninitialized warning

Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

Quoting Sagar Arun Kamble (2018-03-13 12:38:04) > > > On 3/10/2018 3:05 AM, Chris Wilson wrote: > > +static void single(int fd, const struct intel_execution_engine *e) > > +{ > > +#define N_STEPS 10 > > + const unsigned int engine = e->exec_id | e->flags; > > + uint32_t ctx =

Re: [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/pmu: avoid -Wmaybe-uninitialized warning

On Tue, Mar 13, 2018 at 1:29 PM, Patchwork wrote: > == Series Details == > > Series: drm/i915/pmu: avoid -Wmaybe-uninitialized warning > URL : https://patchwork.freedesktop.org/series/39857/ > State : warning > > == Summary == > > $ dim sparse origin/drm-tip >

[Intel-gfx] [PATCH v2] drm/i915: Split GPU commands definitions into separate header

We should not mix MMIO with MI_INSTR definitions. v2: sanitize comment, change include order (Chris) Suggested-by: Chris Wilson Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Reviewed-by: Chris Wilson

Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

On 3/10/2018 3:05 AM, Chris Wilson wrote: Exercise some new API that allows applications to request that individual contexts are executed within a desired frequency range. v2: Split single/continuous set_freq subtests v3: Do an up/down ramp for individual freq request, check nothing changes

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use sseu size for determining eu_regs[]

Quoting Patchwork (2018-03-13 12:25:40) > == Series Details == > > Series: drm/i915: Use sseu size for determining eu_regs[] > URL : https://patchwork.freedesktop.org/series/39853/ > State : success > > Blacklisted hosts: > fi-cnl-drrs total:288 pass:257 dwarn:3 dfail:0 fail:0

[Intel-gfx] [PATCH igt 3/3] igt/gem_exec_schedule: Exercise "deep" preemption

In investigating the issue with having to force preemption within the executing ELSP[], we want to trigger preemption between all elements of that array. To that end, we issue a series of requests with different priorities to fill the in-flight ELSP[] and then demand preemption into the middle of

  1   2   >