[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

== Series Details == Series: series starting with [1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads URL : https://patchwork.freedesktop.org/series/39992/ State : success == Summary == Possible new issues: Test kms_frontbuffer_tracking: Subgroup

[Intel-gfx] linux-next: manual merge of the drm-misc tree with Linus' tree

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: sound/pci/hda/hda_intel.c between commits: 1ba8f9d30817 ("ALSA: hda: Add a power_save blacklist") 40088dc4e1ea ("ALSA: hda - Revert power_save option default value") from Linus' tree and commit: 07f4f97d7b4b

[Intel-gfx] [drm-tip:drm-tip 15/1373] arch/frv/include/asm/pgalloc.h:48:2: error: implicit declaration of function 'pgtable_page_dtor'; did you mean 'pgdat_page_nr'?

tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip head: 178cfb9373cc2bdfcb6ca73e03369d2c37cc4b58 commit: d8d019ccffb838bb0dd98e583b5c25ccc0bc6ece [15/1373] drm/amdgpu: Add KFD eviction fence config: frv-allyesconfig (attached as .config) compiler: frv-linux-gcc (GCC) 7.2.0 reproduce:

Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12

> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Wednesday, March 14, 2018 9:06 PM > To: Srinivas, Vidya > Cc: Maarten Lankhorst ; intel- > g...@lists.freedesktop.org; Syrjala, Ville

Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12

> -Original Message- > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] > Sent: Thursday, March 15, 2018 12:34 AM > To: Ville Syrjälä > Cc: Srinivas, Vidya ; intel- > g...@lists.freedesktop.org; Syrjala, Ville

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/huc: Check HuC status in dedicated function

== Series Details == Series: drm/i915/huc: Check HuC status in dedicated function URL : https://patchwork.freedesktop.org/series/39986/ State : failure == Summary == Possible new issues: Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-spr-indfb-draw-pwrite:

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams (rev2)

== Series Details == Series: drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams (rev2) URL : https://patchwork.freedesktop.org/series/39979/ State : failure == Summary == Possible new issues: Test gem_exec_capture: Subgroup capture-vebox:

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v4,1/4] drm/i915: store all mmio bases in intel_engines

== Series Details == Series: series starting with [v4,1/4] drm/i915: store all mmio bases in intel_engines URL : https://patchwork.freedesktop.org/series/39981/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-external: incomplete ->

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove hole and padding from intel_shared_dpll

== Series Details == Series: drm/i915: Remove hole and padding from intel_shared_dpll URL : https://patchwork.freedesktop.org/series/39972/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight: incomplete -> PASS (shard-apl)

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Control PSR at runtime through debugfs only (rev2)

== Series Details == Series: drm/i915: Control PSR at runtime through debugfs only (rev2) URL : https://patchwork.freedesktop.org/series/39955/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight: incomplete -> PASS (shard-apl)

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Update syntax of GuC log functions (rev2)

== Series Details == Series: drm/i915/guc: Update syntax of GuC log functions (rev2) URL : https://patchwork.freedesktop.org/series/39859/ State : failure == Summary == Possible new issues: Test kms_mmio_vs_cs_flip: Subgroup setplane_vs_cs_flip: pass ->

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

== Series Details == Series: series starting with [1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads URL : https://patchwork.freedesktop.org/series/39992/ State : success == Summary == Series 39992v1 series starting with [1/2] drm/i915/cnl: Implement

Re: [Intel-gfx] [PATCH 0/3] PSR lag fixes

On Wed, 2018-03-14 at 23:09 +0100, Hans de Goede wrote: > Hi, > > On 14-03-18 21:49, Pandiyan, Dhinakaran wrote: > > > > On Wed, 2018-02-14 at 09:25 +0100, Hans de Goede wrote: > >> Hi, > >> > >> On 12-02-18 18:42, Pandiyan, Dhinakaran wrote: > >>> On Mon, 2018-02-12 at 09:45 +0100, Hans de

Re: [Intel-gfx] [PATCH] drm/i915/huc: Check HuC status in dedicated function

On 14/03/18 15:23, Michal Wajdeczko wrote: On Wed, 14 Mar 2018 21:17:29 +0100, Michel Thierry wrote: On 14/03/18 13:04, Michal Wajdeczko wrote: We try to keep all HuC related code in dedicated file. There is no need to peek HuC register directly during handling

[Intel-gfx] [PATCH 2/2] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads

L3Bank could be fused off in hardware for debug purpose, and it is possible that subslice is enabled while its corresponding L3Bank pairs are disabled. In such case, if MCR packet control register(0xFDC) is programed to point to a disabled bank pair, a MMIO read into L3Bank range will return 0

[Intel-gfx] [PATCH 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO read into Slice/Subslice specific registers, MCR packet control register(0xFDC) needs to be programmed to point to any enabled slice/subslice pair. Otherwise, incorrect value will be returned. However, that means each

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915/psr: Nuke aux_frame_sync

== Series Details == Series: series starting with [1/6] drm/i915/psr: Nuke aux_frame_sync URL : https://patchwork.freedesktop.org/series/39990/ State : failure == Summary == Series 39990v1 series starting with [1/6] drm/i915/psr: Nuke aux_frame_sync

[Intel-gfx] [PULL] drm-intel-fixes

Hi Dave, Here goes drm-intel-fixes-2018-03-14: - 1 display fix for bxt - 1 gem fix for fences - 1 gem/pm fix for rps freq Thanks, Rodrigo. The following changes since commit 0c8efd610b58cb23cefdfa12015799079aef94ae: Linux 4.16-rc5 (2018-03-11 17:25:09 -0700) are available in the git

[Intel-gfx] [PATCH 6/6] drm/i915/psr: Enable aux frame sync in source

Even with GTC not enabled lets send the aux frame sync. Hardware is going to send dummy values but this way we can get rid of this workarround in PSR exit: 'drm/i915/psr: disable aux_frame_sync on psr2 exit'. Also moving the line disabling aux frame sync in sink to after report that PSR2 has exit

[Intel-gfx] [PATCH 2/6] drm/i915/psr: Tie PSR2 support to Y coordinate requirement in intel_psr_init_dpcd()

Move to only one place the sink requirements that the actual driver needs to enable PSR2. Also intel_psr2_config_valid() is called every time the crtc config is computed, wasting some time every time it was checking for Y coordinate requirement. This allow us to nuke y_cord_support and some of

[Intel-gfx] [PATCH 4/6] drm/i915/psr: Do not override PSR2 sink support

Sink can support our PSR2 requirements but userspace can request a resolution that PSR2 hardware do not support, in this case it was overwritten the PSR2 sink support. Adding another flag here, this way if requested resolution changed to a value that PSR2 hardware can handle, PSR2 can be enabled.

[Intel-gfx] [PATCH 5/6] drm/i915/psr: Rename intel_crtc_state has_psr to can_psr

This value is a match of hardware and sink has PSR + if it can be enabled by the requested state, see intel_psr_compute_config(). Cc: Dhinakaran Pandiyan Cc: Rodrigo Vivi Signed-off-by: José Roberto de Souza ---

[Intel-gfx] [PATCH 1/6] drm/i915/psr: Nuke aux_frame_sync

PSR2 selective update requires aux frame sync(even though we don't support it in i915) and do not makes sense active PSR2 to only do full screen updates aka PSR1. Having aux_frame_sync flag could cause it be set to true even when the PSR1 is being used, see intel_psr2_config_valid(). Cc:

[Intel-gfx] [PATCH 3/6] drm/i915/psr: Enable Y-coordinate support in source

We are requiring that sink requires Y-coordinate but we are not sending it in the main-link. Even if hardware tracking isn't good enough it will not cause any more issues enabling it. Cc: Dhinakaran Pandiyan Cc: Rodrigo Vivi Signed-off-by:

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

On Wed, 2018-03-14 at 13:47 -0700, Rodrigo Vivi wrote: > On Wed, Mar 14, 2018 at 01:24:13PM -0700, Pandiyan, Dhinakaran wrote: > > On Tue, 2018-03-13 at 15:23 -0700, Rodrigo Vivi wrote: > > > The immediate enabling is actually not an issue for the > > > HW perspective for core platforms that

Re: [Intel-gfx] [PATCH] drm/i915/huc: Check HuC status in dedicated function

On Wed, 14 Mar 2018 21:17:29 +0100, Michel Thierry wrote: On 14/03/18 13:04, Michal Wajdeczko wrote: We try to keep all HuC related code in dedicated file. There is no need to peek HuC register directly during handling getparam ioctl. Signed-off-by: Michal

Re: [Intel-gfx] [PATCH 0/3] PSR lag fixes

Hi, On 14-03-18 21:49, Pandiyan, Dhinakaran wrote: On Wed, 2018-02-14 at 09:25 +0100, Hans de Goede wrote: Hi, On 12-02-18 18:42, Pandiyan, Dhinakaran wrote: On Mon, 2018-02-12 at 09:45 +0100, Hans de Goede wrote: Hi, On 12-02-18 07:08, Dhinakaran Pandiyan wrote: PSR currently when

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

On Tue, Mar 13, 2018 at 03:23:54PM +0200, Ville Syrjälä wrote: > 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) >

Re: [Intel-gfx] [PATCH] drm/i915: Control PSR at runtime through debugfs only

On Wed, Mar 14, 2018 at 12:46:58PM +0100, Maarten Lankhorst wrote: > Allow controlling link status through i915_edp_psr_status, in the same way > kernel does. > This replaces changing the module parameter at runtime, then forcing a > modeset. > > Writing -1 restores the original PSR mode set

Re: [Intel-gfx] [PATCH v3 0/2] CNL port refactoring

On Wed, Mar 14, 2018 at 01:36:51PM +0530, Mahesh Kumar wrote: > This series fixes CNL PORT_TX_DW5/7_LNO_D register address. > This series also introduces macros to get register address of > CNL_PORT_TX registers instead of defining for each DW instance. > > changes since V1: > completely kill

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/psr: Test PSR.

== Series Details == Series: drm/i915/psr: Test PSR. URL : https://patchwork.freedesktop.org/series/39989/ State : warning == Summary == Series 39989v1 drm/i915/psr: Test PSR. https://patchwork.freedesktop.org/api/1.0/series/39989/revisions/1/mbox/ Possible new issues: Test gem_mmap:

Re: [Intel-gfx] [PATCH] drm/i915/psr: Test PSR.

On Wed, Mar 14, 2018 at 02:08:14PM -0700, Dhinakaran Pandiyan wrote: > Don't panic, this is just a trial. LOL! :) > > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/i915/intel_psr.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff

[Intel-gfx] [PATCH] drm/i915/psr: Test PSR.

Don't panic, this is just a trial. Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/intel_psr.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

On Wed, Mar 14, 2018 at 01:20:06PM -0700, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 > bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended > receiver capabilities.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/huc: Check HuC status in dedicated function

== Series Details == Series: drm/i915/huc: Check HuC status in dedicated function URL : https://patchwork.freedesktop.org/series/39986/ State : success == Summary == Series 39986v1 drm/i915/huc: Check HuC status in dedicated function

Re: [Intel-gfx] [PATCH 0/3] PSR lag fixes

On Wed, 2018-02-14 at 09:25 +0100, Hans de Goede wrote: > Hi, > > On 12-02-18 18:42, Pandiyan, Dhinakaran wrote: > > On Mon, 2018-02-12 at 09:45 +0100, Hans de Goede wrote: > >> Hi, > >> > >> On 12-02-18 07:08, Dhinakaran Pandiyan wrote: > >>> PSR currently when enabled results in semi-permanent

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

On Wed, Mar 14, 2018 at 01:24:13PM -0700, Pandiyan, Dhinakaran wrote: > On Tue, 2018-03-13 at 15:23 -0700, Rodrigo Vivi wrote: > > 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

[Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

From: Matt Atwood DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended receiver capabilities. For panels that use this new feature wait interval would be increased by 512 ms, when

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

On Tue, 2018-03-13 at 15:23 -0700, Rodrigo Vivi wrote: > 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

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

On Wed, Mar 14, 2018 at 10:40:08AM -0700, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 > bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended > receiver capabilities.

Re: [Intel-gfx] [PATCH] drm/i915/huc: Check HuC status in dedicated function

On 14/03/18 13:04, Michal Wajdeczko wrote: We try to keep all HuC related code in dedicated file. There is no need to peek HuC register directly during handling getparam ioctl. Signed-off-by: Michal Wajdeczko Cc: Michel Thierry Cc: Rodrigo

Re: [Intel-gfx] [PATCH v2] drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams

On 03/14/2018 12:26 PM, Michal Wajdeczko wrote: On Wed, 14 Mar 2018 19:44:43 +0100, Jackie Li wrote: GuC Address Space and WOPCM Layout diagrams won't be generated correctly by sphinx build if not using proper reST syntax. This patch uses reST literal blocks to make

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Work around compiler warnings on some kernel configs

On Wed, Mar 14, 2018 at 6:57 PM, Tvrtko Ursulin wrote: > On 14/03/2018 08:31, Patchwork wrote: > > Pushed it, thanks for the review! > > (And I forgot to copy Arnd on the patch..) > > So Arnd, sorry, I forgot Reported-by does not add Cc from git send-email. >

[Intel-gfx] [PATCH] drm/i915/huc: Check HuC status in dedicated function

We try to keep all HuC related code in dedicated file. There is no need to peek HuC register directly during handling getparam ioctl. Signed-off-by: Michal Wajdeczko Cc: Michel Thierry Cc: Rodrigo Vivi Cc: Anusha

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

On 03/14/2018 11:26 AM, Pandiyan, Dhinakaran wrote: On Wed, 2018-03-14 at 15:35 +0200, Ville Syrjälä wrote: On Tue, Mar 13, 2018 at 10:48:25PM -0700, Dhinakaran Pandiyan wrote: If bios sets up an MST output and hardware state readout code sees this is an SST configuration, when disabling

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: drop various VLAs in i915_debugfs.c

== Series Details == Series: drm/i915: drop various VLAs in i915_debugfs.c URL : https://patchwork.freedesktop.org/series/39985/ State : failure == Summary == Applying: drm/i915: drop various VLAs in i915_debugfs.c error: Failed to merge in the changes. Using index info to reconstruct a base

[Intel-gfx] [PATCH] drm/i915: drop various VLAs in i915_debugfs.c

Avoid 3 VLAs[1] by using real constant expressions instead of variables. The compiler should be able to optimize the original code and avoid using any actual VLAs. Anyway this change is useful because it will avoid a false positives with -Wvla, it might also help the compiler generating better

Re: [Intel-gfx] [PATCH] drm/i915: drop various VLAs in i915_debugfs.c

2018-03-14 13:27 GMT+01:00 Joonas Lahtinen : > CHV_SS_MAX should be good enough. Make these function scoped (so #define > at the beginning and #undef at the end of function). > > Do use ARRAY_SIZE() instead of repeating. Thank you very much for your suggestions.

Re: [Intel-gfx] [PATCH] drm/i915: drop various VLAs in i915_debugfs.c

2018-03-14 13:17 GMT+01:00 Jani Nikula : > Thanks for your patch. However, Chris beat you to it with: > > 7aa0b14ede64 ("drm/i915: Remove variable length arrays from sseu debugfs > printers") I didn't notice it :) > as well as adding -Wvla to our subdir-ccflags-y to

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

On Tue, Mar 13, 2018 at 02:47:45PM -0700, Alexei Starovoitov wrote: > On 3/13/18 2:37 PM, Roman Gushchin wrote: > > On Tue, Mar 13, 2018 at 02:27:58PM -0700, Alexei Starovoitov wrote: > > > On 3/13/18 1:50 PM, Tejun Heo wrote: > > > > Hello, Matt. > > > > > > > > cc'ing Roman and Alexei. > > > >

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

On Tue, Mar 13, 2018 at 03:42:20PM -0700, Alexei Starovoitov wrote: > On 3/13/18 3:13 PM, Tejun Heo wrote: > > 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

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

On Tue, Mar 13, 2018 at 02:27:58PM -0700, Alexei Starovoitov wrote: > On 3/13/18 1:50 PM, Tejun Heo wrote: > > 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

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

On 3/13/18 3:13 PM, Tejun Heo wrote: 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,

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

On 3/13/18 2:37 PM, Roman Gushchin wrote: On Tue, Mar 13, 2018 at 02:27:58PM -0700, Alexei Starovoitov wrote: On 3/13/18 1:50 PM, Tejun Heo wrote: 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

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

On 3/13/18 1:50 PM, Tejun Heo wrote: 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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Engine discovery query

== Series Details == Series: drm/i915: Engine discovery query URL : https://patchwork.freedesktop.org/series/39958/ State : success == Summary == Known issues: Test kms_flip: Subgroup 2x-plain-flip-fb-recreate-interruptible: pass -> FAIL (shard-hsw)

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams (rev2)

== Series Details == Series: drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams (rev2) URL : https://patchwork.freedesktop.org/series/39979/ State : success == Summary == Series 39979v2 drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams

Re: [Intel-gfx] [PATCH v2] drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams

On Wed, 14 Mar 2018 19:44:43 +0100, Jackie Li wrote: GuC Address Space and WOPCM Layout diagrams won't be generated correctly by sphinx build if not using proper reST syntax. This patch uses reST literal blocks to make sure GuC Address Space and WOPCM Layout diagrams

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/guc: Unify naming of private GuC action functions

== Series Details == Series: drm/i915/guc: Unify naming of private GuC action functions URL : https://patchwork.freedesktop.org/series/39982/ State : warning == Summary == Series 39982v1 drm/i915/guc: Unify naming of private GuC action functions

Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12

Op 14-03-18 om 18:08 schreef Ville Syrjälä: > On Wed, Mar 14, 2018 at 04:55:08PM +0100, Maarten Lankhorst wrote: >> Op 14-03-18 om 16:35 schreef Ville Syrjälä: >>> On Wed, Mar 14, 2018 at 10:36:32AM +, Srinivas, Vidya wrote: > -Original Message- > From: Maarten Lankhorst

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/4] drm/i915: store all mmio bases in intel_engines

== Series Details == Series: series starting with [v4,1/4] drm/i915: store all mmio bases in intel_engines URL : https://patchwork.freedesktop.org/series/39981/ State : success == Summary == Series 39981v1 series starting with [v4,1/4] drm/i915: store all mmio bases in intel_engines

[Intel-gfx] [PATCH v2] drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams

GuC Address Space and WOPCM Layout diagrams won't be generated correctly by sphinx build if not using proper reST syntax. This patch uses reST literal blocks to make sure GuC Address Space and WOPCM Layout diagrams to be generated correctly, and it also corrects some errors in the diagram

[Intel-gfx] [PATCH] drm/i915/guc: Unify naming of private GuC action functions

We should avoid using guc_log prefix for functions that don't operate on GuC log, but rather request action from the GuC. Better to use guc_action prefix. Signed-off-by: Michal Wajdeczko Cc: Michal Winiarski Cc: Sagar Arun Kamble

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams

== Series Details == Series: drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams URL : https://patchwork.freedesktop.org/series/39979/ State : success == Summary == Series 39979v1 drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Update syntax of GuC log functions

On Wed, Mar 14, 2018 at 06:53:23PM +0100, Michal Wajdeczko wrote: > On Wed, 14 Mar 2018 18:20:18 +0100, Michal Wajdeczko > wrote: > > > On Wed, 14 Mar 2018 17:56:01 +0100, Michał Winiarski > > wrote: > > > > > On Wed, Mar 14, 2018 at

[Intel-gfx] [PATCH v4 3/4] drm/i915: use engine->irq_keep_mask when resetting irqs

the "reset" value and the "keep" value are the same. While at it, add a TODO for gen11 interrupt reset Suggested-by: Chris Wilson Cc: Chris Wilson Signed-off-by: Daniele Ceraolo Spurio Reviewed-by: Chris

[Intel-gfx] [PATCH v4 1/4] drm/i915: store all mmio bases in intel_engines

The mmio bases we're currently storing in the intel_engines array are only valid for a subset of gens, so we need to ignore them and use different values in some cases. Instead of doing that, we can have a table of [starting gen, mmio base] pairs for each engine in intel_engines and select the

[Intel-gfx] [PATCH v4 2/4] drm/i915: add a selftest for the mmio_bases table

Check that the entries are in reverse gen order and that all entries with gen > 0 have an mmio base set. v2: loop forward, simplify logic, use i915_subtests (Chris) Suggested-by: Chris Wilson Cc: Chris Wilson Signed-off-by: Daniele Ceraolo

[Intel-gfx] [PATCH v4 4/4] drm/i915: move gen8 irq shifts to intel_lrc.c

The only usage outside the intel_lrc.c file is in the ringbuffer init, but the irq mask calculated there is then overwritten for all engines that have a non-zero shift, so we can drop it. This change is not aimed at code saving but at removing from intel_engines information that does not apply to

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

On Wed, 2018-03-14 at 15:35 +0200, Ville Syrjälä wrote: > On Tue, Mar 13, 2018 at 10:48:25PM -0700, Dhinakaran Pandiyan wrote: > > 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 > >

Re: [Intel-gfx] [RFC] drm/i915: Engine discovery query

> -Original Message- > From: Tvrtko Ursulin [mailto:tursu...@ursulin.net] > Sent: Wednesday, March 14, 2018 7:06 AM > To: Intel-gfx@lists.freedesktop.org > Cc: tursu...@ursulin.net; Ursulin, Tvrtko ; Chris > Wilson ; Bloomfield, Jon >

Re: [Intel-gfx] [RFC] drm/i915: Engine discovery query

On 14/03/18 17:53, Tvrtko Ursulin wrote: Maybe I reorder it like: u32 flags; u16 class; u16 instance; u32/u64 capabilities; u32 rdsvd[some]; Looks good :) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Work around compiler warnings on some kernel configs

On 14/03/2018 08:31, Patchwork wrote: == Series Details == Series: drm/i915/pmu: Work around compiler warnings on some kernel configs URL : https://patchwork.freedesktop.org/series/39939/ State : success == Summary == Series 39939v1 drm/i915/pmu: Work around compiler warnings on some

[Intel-gfx] [PATCH] drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams

GuC Address Space and WOPCM Layout diagrams won't be generated correctly by sphinx build if not using proper reST syntax. This patch uses reST literal blocks to make sure GuC Address Space and WOPCM Layout diagrams to be generated correctly. Signed-off-by: Jackie Li Cc:

Re: [Intel-gfx] [RFC] drm/i915: Engine discovery query

On 14/03/2018 16:40, Lionel Landwerlin wrote: Looks mostly good to me. I have a few comments below. On 14/03/18 14:05, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Engine discovery query allows userspace to enumerate engines, probe their configuration features, all

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Update syntax of GuC log functions

On Wed, 14 Mar 2018 18:20:18 +0100, Michal Wajdeczko wrote: On Wed, 14 Mar 2018 17:56:01 +0100, Michał Winiarski wrote: On Wed, Mar 14, 2018 at 02:45:39PM +, Michal Wajdeczko wrote: We moved GuC log related data and code to

[Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

From: Matt Atwood DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended receiver capabilities. For panels that use this new feature wait interval would be increased by 512 ms, when

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

On Tue, Mar 13, 2018 at 07:24:20PM -0400, Lyude Paul wrote: > 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

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Update syntax of GuC log functions

On Wed, 14 Mar 2018 17:56:01 +0100, Michał Winiarski wrote: On Wed, Mar 14, 2018 at 02:45:39PM +, Michal Wajdeczko wrote: We moved GuC log related data and code to separate files and definition but we didn't change functions syntax to follow object-verb

Re: [Intel-gfx] [PATCH] drm/i915: Remove hole and padding from intel_shared_dpll

On Wed, Mar 14, 2018 at 09:31:32AM -0700, Lucas De Marchi wrote: > Reorder fields so we save 8 bytes per instance: this removes a 4-bytes > hole after enum intel_dpll_id and a 4-bytes padding. > > Signed-off-by: Lucas De Marchi > --- > > Is this something desirable? I

Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12

On Wed, Mar 14, 2018 at 04:55:08PM +0100, Maarten Lankhorst wrote: > Op 14-03-18 om 16:35 schreef Ville Syrjälä: > > On Wed, Mar 14, 2018 at 10:36:32AM +, Srinivas, Vidya wrote: > >> > >>> -Original Message- > >>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] > >>>

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove hole and padding from intel_shared_dpll

== Series Details == Series: drm/i915: Remove hole and padding from intel_shared_dpll URL : https://patchwork.freedesktop.org/series/39972/ State : success == Summary == Series 39972v1 drm/i915: Remove hole and padding from intel_shared_dpll

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Update syntax of GuC log functions

On Wed, Mar 14, 2018 at 02:45:39PM +, Michal Wajdeczko wrote: > We moved GuC log related data and code to separate files and > definition but we didn't change functions syntax to follow > object-verb pattern. Let's fix that before we continue with > next round of code refactoring. > > v2:

Re: [Intel-gfx] [PATCH 20/36] drm/i915: Remove obsolete min/max freq setters from debugfs

On 3/14/2018 3:07 PM, Chris Wilson wrote: A more complete, and more importantly stable, interface for controlling the RPS frequency range is available in sysfs, obsoleting the unstable debugfs. Signed-off-by: Chris Wilson Reviewed-by: Sagar Arun Kamble

Re: [Intel-gfx] [RFC] drm/i915: Engine discovery query

Looks mostly good to me. I have a few comments below. On 14/03/18 14:05, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Engine discovery query allows userspace to enumerate engines, probe their configuration features, all without needing to maintain the internal PCI ID

[Intel-gfx] [PATCH] drm/i915: Remove hole and padding from intel_shared_dpll

Reorder fields so we save 8 bytes per instance: this removes a 4-bytes hole after enum intel_dpll_id and a 4-bytes padding. Signed-off-by: Lucas De Marchi --- Is this something desirable? I happened to be looking at intel_shared_dpll and noticed the hole. I haven't

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Control PSR at runtime through debugfs only (rev2)

== Series Details == Series: drm/i915: Control PSR at runtime through debugfs only (rev2) URL : https://patchwork.freedesktop.org/series/39955/ State : success == Summary == Series 39955v2 drm/i915: Control PSR at runtime through debugfs only

[Intel-gfx] [PATCH 2/2] drm/i915/icl: Enable 2nd DBuf slice only when needed

ICL has two slices of DBuf, each slice of size 1024 blocks. We should not always enable slice-2. It should be enabled only if display total required BW is > 12GBps OR more than 1 pipes are enabled. Changes since V1: - typecast total_data_rate to u64 before multiplication to solve any possible

Re: [Intel-gfx] [PATCH] drm/i915: Allow control of PSR at runtime through debugfs.

Op 14-03-18 om 17:07 schreef Chris Wilson: > Quoting Maarten Lankhorst (2018-03-14 15:58:32) >> Currently tests modify i915.enable_psr and then do a modeset cycle >> to change PSR. We can write a value to i915_edp_psr_status to force >> a certain value without a modeset. >> >> To retain

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Update syntax of GuC log functions (rev2)

== Series Details == Series: drm/i915/guc: Update syntax of GuC log functions (rev2) URL : https://patchwork.freedesktop.org/series/39859/ State : success == Summary == Series 39859v2 drm/i915/guc: Update syntax of GuC log functions

Re: [Intel-gfx] [PATCH] drm/i915: Allow control of PSR at runtime through debugfs.

Quoting Maarten Lankhorst (2018-03-14 15:58:32) > Currently tests modify i915.enable_psr and then do a modeset cycle > to change PSR. We can write a value to i915_edp_psr_status to force > a certain value without a modeset. > > To retain compatibility with older userspace, we also still allow >

[Intel-gfx] [PATCH] drm/i915: Allow control of PSR at runtime through debugfs.

Currently tests modify i915.enable_psr and then do a modeset cycle to change PSR. We can write a value to i915_edp_psr_status to force a certain value without a modeset. To retain compatibility with older userspace, we also still allow the override through the module parameter, and add some

Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12

Op 14-03-18 om 16:35 schreef Ville Syrjälä: > On Wed, Mar 14, 2018 at 10:36:32AM +, Srinivas, Vidya wrote: >> >>> -Original Message- >>> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] >>> Sent: Wednesday, March 14, 2018 4:03 PM >>> To: Srinivas, Vidya

Re: [Intel-gfx] [PATCH v13 12/17] drm/i915: Upscale scaler max scale for NV12

On Wed, Mar 14, 2018 at 10:36:32AM +, Srinivas, Vidya wrote: > > > > -Original Message- > > From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com] > > Sent: Wednesday, March 14, 2018 4:03 PM > > To: Srinivas, Vidya ; intel- > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for Aspect ratio support in DRM layer

== Series Details == Series: Aspect ratio support in DRM layer URL : https://patchwork.freedesktop.org/series/39960/ State : failure == Summary == Series 39960v1 Aspect ratio support in DRM layer https://patchwork.freedesktop.org/api/1.0/series/39960/revisions/1/mbox/ Possible new

Re: [Intel-gfx] [PATCH 13/36] drm/i915: Merge sandybridge_pcode_(read|write)

On Wed, Mar 14, 2018 at 09:37:25AM +, Chris Wilson wrote: > These routines are identical except in the nature of the value parameter. > For writes it is a pure in-param, but for a read, we need an out-param. > Since they differ in a single line, merge the two routines into one. > >

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Aspect ratio support in DRM layer

== Series Details == Series: Aspect ratio support in DRM layer URL : https://patchwork.freedesktop.org/series/39960/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/modes: Introduce drm_mode_match() Okay! Commit: drm/edid: Use drm_mode_match_no_clocks_no_stereo() for

[Intel-gfx] [maintainer-tools PATCH] doc: how to become a drm-intel committer

Until now, the drm-intel commit access have been handed out ad hoc, without transparency, consistency, or fairness. With pressure to add more committers, this is no longer tenable, if it ever was. Document the requirements and expectations around becoming a drm-intel committer. The Linux kernel

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

On Tue, Mar 13, 2018 at 08:04:03PM +0100, Maarten Lankhorst wrote: > 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

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

On Wed, Mar 14, 2018 at 02:56:28PM +0100, Daniel Vetter wrote: > On Tue, Mar 13, 2018 at 05:07:58PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Do the refresh rate calculation with a single division. This gives > > us slightly more accurate results,

  1   2   3   >