[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Check if WM is greater than previous level

== Series Details == Series: drm/i915: Check if WM is greater than previous level URL : https://patchwork.freedesktop.org/series/25752/ State : success == Summary == Series 25752v1 drm/i915: Check if WM is greater than previous level

[Intel-gfx] [PATCH] drm/i915: fix the issue DP-1 not working in guest

From: "Anuar, Nuhairi" In GVT guest, when port A is DP, i915 will force it as an EDP panel, which will cause DP-1 not working in GVT guest. This patch fixed this issue by check intel_vgpu_active() in intel_ddi_compute_config(). Signed-off-by: Min He

[Intel-gfx] [PATCH] drm/i915: Check if WM is greater than previous level

From: "Kumar, Mahesh" Some time WM calculated values are higher for lower level & lower WM value for higher level. This leads to allocation of less DDB to plane & may result in disabling lower WM level but enabling higher WM level. which may lead to under run. This

Re: [Intel-gfx] [PATCH v8 4/6] vfio: Define vfio based vgpu's dma-buf operations

>-Original Message- >From: Alex Williamson [mailto:alex.william...@redhat.com] >Sent: Wednesday, June 14, 2017 11:46 AM >To: Chen, Xiaoguang >Cc: Tian, Kevin ; intel-gfx@lists.freedesktop.org; linux- >ker...@vger.kernel.org;

Re: [Intel-gfx] [PATCH v8 4/6] vfio: Define vfio based vgpu's dma-buf operations

On Wed, 14 Jun 2017 03:18:31 + "Chen, Xiaoguang" wrote: > >-Original Message- > >From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > >Behalf Of Alex Williamson > >Sent: Wednesday, June 14, 2017 11:06 AM > >To: Chen, Xiaoguang

Re: [Intel-gfx] [PATCH v8 4/6] vfio: Define vfio based vgpu's dma-buf operations

>-Original Message- >From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On >Behalf Of Alex Williamson >Sent: Wednesday, June 14, 2017 11:06 AM >To: Chen, Xiaoguang >Cc: Tian, Kevin ; intel-gfx@lists.freedesktop.org;

Re: [Intel-gfx] [PATCH v8 4/6] vfio: Define vfio based vgpu's dma-buf operations

On Wed, 14 Jun 2017 02:53:24 + "Chen, Xiaoguang" wrote: > >-Original Message- > >From: Alex Williamson [mailto:alex.william...@redhat.com] > >Sent: Wednesday, June 14, 2017 5:25 AM > >To: Chen, Xiaoguang > >Cc: kra...@redhat.com;

Re: [Intel-gfx] [PATCH v8 4/6] vfio: Define vfio based vgpu's dma-buf operations

>-Original Message- >From: Alex Williamson [mailto:alex.william...@redhat.com] >Sent: Wednesday, June 14, 2017 5:25 AM >To: Chen, Xiaoguang >Cc: kra...@redhat.com; ch...@chris-wilson.co.uk; intel- >g...@lists.freedesktop.org; linux-ker...@vger.kernel.org;

[Intel-gfx] linux-next: manual merge of the drm tree with the drm-intel-fixes tree

Hi Dave, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/i915/intel_pm.c between commit: 1c2d6bbf0433 ("drm/i915: Fix SKL+ watermarks for 90/270 rotation") from the drm-intel-fixes tree and commit: 7084b50bdd8f ("drm/i915/skl+: calculate pixel_rate &

[Intel-gfx] linux-next: manual merge of the drm tree with the drm-intel-fixes tree

Hi Dave, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/i915/intel_display.c between commit: 9a775e0308b5 ("drm/i915: Fix scaling check for 90/270 degree plane rotation") from the drm-intel-fixes tree and commit: c2c446ad2943 ("drm: Add DRM_MODE_ROTATE_ and

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add GuC timeout config options to Kconfig.debug

== Series Details == Series: drm/i915: Add GuC timeout config options to Kconfig.debug URL : https://patchwork.freedesktop.org/series/25741/ State : success == Summary == Series 25741v1 drm/i915: Add GuC timeout config options to Kconfig.debug

[Intel-gfx] [RFC] drm/i915: Add GuC timeout config options to Kconfig.debug

It is sometimes useful for debug purposes to be able to set GuC timeout lengths. This patch adds GuC load and request timeouts values to Kconfig.debug, which can then be optionally set as required for debug cases. A default value equal to the current hard-coded values are provided. In the case

Re: [Intel-gfx] [PATCH v8 6/6] drm/i915/gvt: Adding user interface for dma-buf

On Fri, 9 Jun 2017 14:50:42 +0800 Xiaoguang Chen wrote: > User space should create the management fd for the dma-buf operation first. > Then user can query the plane information and create dma-buf if necessary > using the management fd. > > Signed-off-by: Xiaoguang

Re: [Intel-gfx] [PATCH v8 4/6] vfio: Define vfio based vgpu's dma-buf operations

On Fri, 9 Jun 2017 14:50:40 +0800 Xiaoguang Chen wrote: > Here we defined a new ioctl to create a fd for a vfio device based on > the input type. Now only one type is supported that is a dma-buf > management fd. > Two ioctls are defined for the dma-buf management fd:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Don't enable backlight at setup time. (rev2)

== Series Details == Series: drm/i915: Don't enable backlight at setup time. (rev2) URL : https://patchwork.freedesktop.org/series/25677/ State : success == Summary == Series 25677v2 drm/i915: Don't enable backlight at setup time.

[Intel-gfx] [PATCH v2] drm/i915: Don't enable backlight at setup time.

Maarten and Ville noticed that we are enabling backlight via DP aux very early in the modeset_init path via the intel_dp_aux_setup_backlight() function, since commit e7156c833903 ("drm/i915: Add Backlight Control using DPCD for eDP connectors (v9)"). Looks like all we need to do during

[Intel-gfx] ✓ Fi.CI.BAT: success for Reorganize the register picking macros

== Series Details == Series: Reorganize the register picking macros URL : https://patchwork.freedesktop.org/series/25730/ State : success == Summary == Series 25730v1 Reorganize the register picking macros https://patchwork.freedesktop.org/api/1.0/series/25730/revisions/1/mbox/ Test

[Intel-gfx] [PATCH 3/7] drm/i915: use variable arguments for the macros that call _PICK

There's no need to create a new macro every time the number of parameters change. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_reg.h | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h

[Intel-gfx] [PATCH 2/7] drm/i915: _MMIO_PORT3 takes a port as an argument

The macro takes a port as an argument, not a pipe. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_reg.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index

[Intel-gfx] [PATCH 6/7] drm/i915: also move version 2 of the register picking macros up

Make sure all the macros are next to each other so it's easier to spot all the options available. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_reg.h | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git

[Intel-gfx] [PATCH 5/7] drm/i915: add _PICK macro for the "a + index * (b - a)" macros

Instead of duplicating the macro everywhere, add a single definition for it and call it just like we do with the _PICK3 macros. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_reg.h | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff

[Intel-gfx] [PATCH 4/7] drm/i915: rename _PICK to _PICK3

All of the macros that call _PICK are named _X_3, so let's rename _PICK to _PICK3. The reason we're doing this is because we're going to have _PICK and _PICK2. Consider _PICK3 as the third variation of the PICK macros (well, actually it *is* the third variation...). Signed-off-by: Paulo Zanoni

[Intel-gfx] [PATCH 7/7] drm/i915: extract a _PICK2 macro

Do it just like we do with _PICK and _PICK3, so our code looks a little more uniform. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_reg.h | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h

[Intel-gfx] [PATCH 1/7] drm/i915: reorder the register picking macros

We currently have pipe, plane, trans, port, pll and phy versions of these macros. Reorder their definitions so all macros of each type are in their own group, separated by blank lines. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_reg.h | 11 --- 1

[Intel-gfx] [PATCH 0/7] Reorganize the register picking macros

We have 3 different types of macros to pick registers with multiple instances and each of these types is coded in a different way. I like consistency, so I wrote this series in order to try to make our code a little more clear regarding our options and their differences. Besides the consistency

Re: [Intel-gfx] [PATCH] drm/i915: Don't enable backlight at setup time.

On Tue, 2017-06-13 at 09:48 +0300, Jani Nikula wrote: > On Mon, 12 Jun 2017, Dhinakaran Pandiyan > wrote: > > Maarten and Ville noticed that we are enabling backlight via DP aux very > > early in the modeset_init path via the intel_dp_aux_setup_backlight() > >

Re: [Intel-gfx] [PATCH] Revert "drm/i915/skl: New ddb allocation algorithm"

On Tue, Jun 13, 2017 at 11:07 AM, Matt Roper wrote: > On Tue, Jun 13, 2017 at 10:52:30AM -0700, Rodrigo Vivi wrote: >> This reverts commit bb9d85f6e9de8fef5236c076530eab67a2f2431b. >> >> New ddb allocation algorithm is a show stopper on my SKL system. >> >> Besides not

Re: [Intel-gfx] [PATCH] drm/i915: Don't enable backlight at setup time.

On Tue, 2017-06-13 at 08:29 +0200, Maarten Lankhorst wrote: > Op 12-06-17 om 22:16 schreef Dhinakaran Pandiyan: > > Maarten and Ville noticed that we are enabling backlight via DP aux very > > early in the modeset_init path via the intel_dp_aux_setup_backlight() > > function. Looks like all we

Re: [Intel-gfx] [PATCH i-g-t] tests/chamelium: Require HPD storm control for basic hotplug test

NAK, igt_hpd_storm_set_threshold is expected to be called in both situations with and without hpd storm control support. The function should be able to notice when the host doesn't have the debugfs nodes for hpd storm control, and just return without doing anything in that case: void

[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/i915/skl: New ddb allocation algorithm"

== Series Details == Series: Revert "drm/i915/skl: New ddb allocation algorithm" URL : https://patchwork.freedesktop.org/series/25724/ State : success == Summary == Series 25724v1 Revert "drm/i915/skl: New ddb allocation algorithm"

Re: [Intel-gfx] [PATCH] Revert "drm/i915/skl: New ddb allocation algorithm"

On Tue, Jun 13, 2017 at 10:52:30AM -0700, Rodrigo Vivi wrote: > This reverts commit bb9d85f6e9de8fef5236c076530eab67a2f2431b. > > New ddb allocation algorithm is a show stopper on my SKL system. > > Besides not be able to get external DP 4k@60 (through USB type C), > It fully hang my screen when

[Intel-gfx] [PATCH] Revert "drm/i915/skl: New ddb allocation algorithm"

This reverts commit bb9d85f6e9de8fef5236c076530eab67a2f2431b. New ddb allocation algorithm is a show stopper on my SKL system. Besides not be able to get external DP 4k@60 (through USB type C), It fully hang my screen when unplugging the USB type C. Cc: Mahesh Kumar

Re: [Intel-gfx] Fixes that failed to backport to v4.12-rc1

On 13/06/17 01:27, Jani Nikula wrote: On Mon, 15 May 2017, Jani Nikula wrote: Continuing [1] for v4.12-rc1 The following commits have been marked as Cc: stable or fixing something in v4.12-rc1 or earlier, but failed to cherry-pick to drm-intel-fixes. Please see if they

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: SKL+ render decompression support (rev5)

== Series Details == Series: drm/i915: SKL+ render decompression support (rev5) URL : https://patchwork.freedesktop.org/series/17507/ State : success == Summary == Series 17507v5 drm/i915: SKL+ render decompression support

[Intel-gfx] [PATCH v5 2/2] drm/i915: Add render decompression support

From: Ville Syrjälä SKL+ display engine can scan out certain kinds of compressed surfaces produced by the render engine. This involved telling the display engine the location of the color control surfae (CCS) which describes which parts of the main surface are

[Intel-gfx] [PATCH v4 1/2] drm/i915: Implement .get_format_info() hook for CCS

From: Ville Syrjälä SKL+ display engine can scan out certain kinds of compressed surfaces produced by the render engine. This involved telling the display engine the location of the color control surfae (CCS) which describes which parts of the main surface are

[Intel-gfx] [PATCH v4 0/2] drm/i915: SKL+ render decompression support

From: Ville Syrjälä Here's yet another iteration of CCS support. The first major change is that we now treat fb->offsets[] as raw byte offsets instead of linear offsets since that's what userspace seems to want. This means we'll not allow non-tile aligned offsets

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: make function cnl_ddi_dp_set_dpll_hw_state static

== Series Details == Series: drm/i915/cnl: make function cnl_ddi_dp_set_dpll_hw_state static URL : https://patchwork.freedesktop.org/series/25716/ State : success == Summary == Series 25716v1 drm/i915/cnl: make function cnl_ddi_dp_set_dpll_hw_state static

Re: [Intel-gfx] [PATCH v2 5/5] drm/i915: Start writeback from the shrinker

On pe, 2017-06-09 at 12:03 +0100, Chris Wilson wrote: > When we are called to relieve mempressue via the shrinker, the only way > we can make progress is either by discarding unwanted pages (those > objects that userspace has marked MADV_DONTNEED) or by reclaiming the > dirty objects via swap. As

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Only restrict noreclaim in the early shrink passes

On pe, 2017-06-09 at 12:03 +0100, Chris Wilson wrote: > In our first pass, we do not want to use reclaim at all as we want to > solely reap the i915 buffer caches (its purgeable pages). But we don't > mind it initiates IO or pulls via the FS (but it shouldn't anyway as we > say no to reclaim!).

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: Remove __GFP_NORETRY from our buffer allocator

On pe, 2017-06-09 at 12:03 +0100, Chris Wilson wrote: > I tried __GFP_NORETRY in the belief that __GFP_RECLAIM was effective. It > struggles with handling reclaim of our dirty buffers and relies on > reclaim via kswapd. As a result, a single pass of direct reclaim is > unreliable when i915

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915: Spin for struct_mutex inside shrinker

On pe, 2017-06-09 at 12:03 +0100, Chris Wilson wrote: > Having resolved whether or not we would deadlock upon a call to > mutex_lock(>struct_mutex), we can then spin for the contended > struct_mutex if we are not the owner. We cannot afford to simply block > and wait for the mutex, as the owner

[Intel-gfx] [PATCH][drm-next] drm/i915/cnl: make function cnl_ddi_dp_set_dpll_hw_state static

From: Colin Ian King The function cnl_ddi_dp_set_dpll_hw_state does not need to be in global scope, so make it static. Cleans up sparse warning: "symbol 'cnl_ddi_dp_set_dpll_hw_state' was not declared. Should it be static?" Signed-off-by: Colin Ian King

Re: [Intel-gfx] [PATCH 2/6] drm/i915/hsw: use intel_compute_linetime_wm function for linetime wm

Hi, On Tuesday 13 June 2017 06:42 PM, Ville Syrjälä wrote: On Tue, Jun 13, 2017 at 11:34:46AM +0530, Mahesh Kumar wrote: linetime wm is time taken to fill a single display line with given clock rate, multiplied by 8. This patch reuses the common code of hsw_compute_linetime_wm &

[Intel-gfx] ✓ Fi.CI.BAT: success for Fixed16.16 wrapper cleanup & wm optimization (rev2)

== Series Details == Series: Fixed16.16 wrapper cleanup & wm optimization (rev2) URL : https://patchwork.freedesktop.org/series/25692/ State : success == Summary == Series 25692v2 Fixed16.16 wrapper cleanup & wm optimization

Re: [Intel-gfx] [PATCH 2/6] drm/i915/hsw: use intel_compute_linetime_wm function for linetime wm

On Tue, Jun 13, 2017 at 11:34:46AM +0530, Mahesh Kumar wrote: > linetime wm is time taken to fill a single display line with given clock > rate, multiplied by 8. > This patch reuses the common code of hsw_compute_linetime_wm & > skl_compute_linetime_wm. > > Signed-off-by: Mahesh Kumar

[Intel-gfx] [PATCH 5/9] drm/i915/hsw: use intel_compute_linetime_wm function for linetime wm

linetime wm is time taken to fill a single display line with given clock rate, multiplied by 8. This patch reuses the common code of hsw_compute_linetime_wm & skl_compute_linetime_wm. Changes since V1: - don't expose intel_compute_linetime_wm out of intel_pm.c (Maarten) Signed-off-by: Mahesh

[Intel-gfx] [PATCH 7/9] drm/i915/skl+: unify cpp value in WM calculation

use same cpp value in different phase of plane WM caluclation. Signed-off-by: Mahesh Kumar Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_pm.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git

[Intel-gfx] [PATCH 8/9] drm/i915/skl+: Optimize WM calculation

Plane configuration parameters doesn't change for each WM-level calculation. Currently we compute same parameters 8 times for each wm-level. This patch optimizes it by calculating these parameters in beginning & reuse during each level-wm calculation. Signed-off-by: Mahesh Kumar

[Intel-gfx] [PATCH 9/9] drm/i915/gen10: Calculate and enable transition WM

GEN > 9 require transition WM to be programmed if IPC is enabled. This patch calculates & enable transition WM for supported platforms. If transition WM is enabled, Plane read requests are sent at high priority until filling above the transition watermark, then the requests are sent at lower

[Intel-gfx] [PATCH 2/9] drm/i915: Always perform internal fixed16 division in 64 bits

This patch combines fixed_16_16_div & fixed_16_16_div_u64 wrappers. And new fixed_16_16_div wrapper always performs division operation in u64 internally, to avoid any data loss which was happening in earlier version of wrapper. earlier wrapper was converting u32 to fixed16 in 32 bit so we were

[Intel-gfx] [PATCH 0/9] Fixed16.16 wrapper cleanup & wm optimization

This series Include patches for: clean fixed16.16 naming & make them consistent reuse intel_compute_linetime_wm in hsw optimize wm calculation code enable/Implement trans wm calculation Changes Since V1: - Split fixed16 cleanup code in more logical patches

[Intel-gfx] [PATCH 6/9] drm/i915/skl+: WM calculation don't require height

height of plane was require to swap width/height in case of 90/270 rotation. Now src structure contains already swapped values, So we don't have to calculate height of the plane. Signed-off-by: Mahesh Kumar Reviewed-by: Maarten Lankhorst

[Intel-gfx] [PATCH 4/9] drm/i915: Addition wrapper for fixed16.16 operation

This patch introduce addition wrapper for fixed point 16.16 operations. Which will be used by later patches to avoid direct member variables access of fixed_16_16_t structure. add_fixed16 : takes 2 fixed_16_16_t variable & returns fixed_16_16_t add_fixed16_u32 : takes fixed_16_16_t & u32 variable

[Intel-gfx] [PATCH 1/9] drm/i915: take-out common clamping code of fixed16 wrappers

This patch creates a new function for clamping u64 to fixed16. And make use of this function in other fixed16 wrappers. Signed-off-by: Mahesh Kumar --- drivers/gpu/drm/i915/i915_drv.h | 28 1 file changed, 12 insertions(+), 16 deletions(-)

[Intel-gfx] [PATCH 3/9] drm/i915: cleanup fixed-point wrappers naming

This patch make naming of fixed-point wrappers consistent operation__<1st operand>_<2nd operand> also shorten the name for fixed_16_16 to fixed16 s/u32_to_fixed_16_16/u32_to_fixed16 s/fixed_16_16_to_u32/fixed16_to_u32 s/fixed_16_16_to_u32_round_up/fixed16_to_u32_round_up

Re: [Intel-gfx] [PATCH i-g-t] tests: Rename I915_MAX_PIPES to IGT_MAX_PIPES

On Tue, Jun 13, 2017 at 03:41:14PM +0300, Arkadiusz Hiler wrote: > On Tue, Jun 13, 2017 at 10:35:34AM +0300, Jani Nikula wrote: > > On Mon, 12 Jun 2017, Harry Wentland wrote: > > > The email was sent but might be stuck in the moderation queue since Leo > > > (Sun peng) is

Re: [Intel-gfx] drm/i915: Make MMIO_PORT flexible.

On Mon, Jun 12, 2017 at 10:26:00AM -0700, Rodrigo Vivi wrote: > On Mon, Jun 12, 2017 at 10:11 AM, Ville Syrjälä > wrote: > > On Mon, Jun 12, 2017 at 04:28:28PM +, Vivi, Rodrigo wrote: > >> On Mon, 2017-06-12 at 17:56 +0300, Ville Syrjälä wrote: > >> > On Fri,

Re: [Intel-gfx] [PATCH i-g-t] tests/chamelium: Require HPD storm control for basic hotplug test

On Tue, 2017-06-13 at 15:44 +0300, Paul Kocialkowski wrote: > The basic hotplug test (test_basic_hotplug) makes calls to > igt_hpd_storm_set_threshold, which requires HPD storm control. > > This adds a check for that control, since it was missing. This is a resend of yesterday's patch with the

[Intel-gfx] [PATCH i-g-t] tests/chamelium: Require HPD storm control for basic hotplug test

The basic hotplug test (test_basic_hotplug) makes calls to igt_hpd_storm_set_threshold, which requires HPD storm control. This adds a check for that control, since it was missing. Signed-off-by: Paul Kocialkowski --- tests/chamelium.c | 2 ++ 1 file changed,

Re: [Intel-gfx] [PATCH i-g-t] tests: Rename I915_MAX_PIPES to IGT_MAX_PIPES

On Tue, Jun 13, 2017 at 10:35:34AM +0300, Jani Nikula wrote: > On Mon, 12 Jun 2017, Harry Wentland wrote: > > The email was sent but might be stuck in the moderation queue since Leo > > (Sun peng) is fairly new on the FDO mailing lists. > > > > Jani, Daniel, can you check

Re: [Intel-gfx] [PATCH IGT] tests/chamelium: Close DRM file descriptor after tests

On Mon, Jun 12, 2017 at 06:21:45PM +0300, Paul Kocialkowski wrote: > On Mon, 2017-06-12 at 17:39 +0300, Paul Kocialkowski wrote: > > This adds a call to close the DRM file descriptor. It is reauired as IGT > > will attempt to become DRM master after running the test, resulting in a > > failure. >

[Intel-gfx] ✓ Fi.CI.BAT: success for Enable OA unit for Gen 8 and 9 in i915 perf (rev13)

== Series Details == Series: Enable OA unit for Gen 8 and 9 in i915 perf (rev13) URL : https://patchwork.freedesktop.org/series/20084/ State : success == Summary == Series 20084v13 Enable OA unit for Gen 8 and 9 in i915 perf

[Intel-gfx] [PATCH v17 09/11] drm/i915: add KBL GT2/GT3 check macros

Add macros to detect GT2/GT3 skus so we can apply the proper OA configuration later. Signed-off-by: Lionel Landwerlin Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/i915_drv.h | 4 1 file changed, 4 insertions(+) diff --git

[Intel-gfx] [PATCH v17 11/11] drm/i915/perf: add GLK support

Add OA support for Geminilake (pretty much identical to Broxton), and also add the associated OA configurations. Signed-off-by: Lionel Landwerlin Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/Makefile |3 +-

[Intel-gfx] [PATCH v17 01/11] drm/i915: expose _SLICE_MASK GETPARM

From: Robert Bragg Enables userspace to determine the maximum number of slices that can be enabled on the device and also know what specific slices can be enabled. This information is required, for example, to be able to analyse some OA counter reports where the counter

[Intel-gfx] [PATCH v17 03/11] drm/i915/perf: rework mux configurations queries

Gen8+ might have mux configurations per slices/subslices. Depending on whether slices/subslices have been fused off, only part of the configuration needs to be applied. This change reworks the mux configurations query mechanism to allow more than one set of registers to be programmed. v2:

[Intel-gfx] [PATCH v17 04/11] drm/i915/perf: Add 'render basic' Gen8+ OA unit configs

From: Robert Bragg Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic render metrics on Broadwell, Cherryview, Skylake and Broxton. These are auto generated from an XML description of metric sets, currently maintained in gputop, ref:

[Intel-gfx] [PATCH v17 08/11] drm/i915/perf: remove perf.hook_lock

From: Robert Bragg In earlier iterations of the i915-perf driver we had a number of callbacks/hooks from other parts of the i915 driver to e.g. notify us when a legacy context was pinned and these could run asynchronously with respect to the stream file operations and might

[Intel-gfx] [PATCH v17 02/11] drm/i915: expose _SUBSLICE_MASK GETPARM

From: Robert Bragg Assuming a uniform mask across all slices, this enables userspace to determine the specific sub slices can be enabled. This information is required, for example, to be able to analyse some OA counter reports where the counter configuration depends on the

[Intel-gfx] [PATCH v17 07/11] drm/i915/perf: per-gen timebase for checking sample freq

From: Robert Bragg An oa_exponent_to_ns() utility and per-gen timebase constants where recently removed when updating the tail pointer race condition WA, and this restores those so we can update the _PROP_OA_EXPONENT validation done in read_properties_unlocked() to not

[Intel-gfx] [PATCH v17 05/11] drm/i915/perf: Add OA unit support for Gen 8+

From: Robert Bragg Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all share (more-or-less) the same OA unit design. Of particular note in comparison to Haswell: some OA unit HW config state has become per-context state and as a consequence it is somewhat

[Intel-gfx] [PATCH v17 00/11] Enable OA unit for Gen 8 and 9 in i915 perf

Hi, This is a just a final iteration to run through the CI with a couple of nits on patch 5. I've dropped the patches that add the sseu configuration tracking as they still have some issues and I would like to get the basic stuff merged first (this has been dragging for too long). Cheers,

Re: [Intel-gfx] [i-g-t PATCH v3 3/3] Convert shell script tests to C version

On 12.06.2017 14:14, Arkadiusz Hiler wrote: > On Tue, Jun 06, 2017 at 11:54:14AM +0300, Abdiel Janulgue wrote: >> v3: Drop redundant test covered by drv_hangman/basic. Descend thru >> debugfs path when reading sysfs entries (Chris). >> >> v2: Use internal igt_debugfs functions instead of cat

Re: [Intel-gfx] [PATCH 6/6] drm/i915/gen10: Calculate and enable transition WM

Hi, On Tuesday 13 June 2017 02:59 PM, Lankhorst, Maarten wrote: Hey, Mahesh Kumar schreef op di 13-06-2017 om 11:34 [+0530]: GEN > 9 require transition WM to be programmed if IPC is enabled. This patch calculates & enable transition WM for supported platforms. If transition WM is enabled,

Re: [Intel-gfx] [PATCH 1/6] drm/i915: cleanup fixed-point wrappers naming

On Tuesday 13 June 2017 01:19 PM, Mahesh Kumar wrote: On Tuesday 13 June 2017 01:08 PM, Lankhorst, Maarten wrote: Mahesh Kumar schreef op di 13-06-2017 om 11:34 [+0530]: This patch make naming of fixed-point wrappers consistent operation__<1st operand>_<2nd operand> also shorten the name

Re: [Intel-gfx] [PATCH 6/6] drm/i915/gen10: Calculate and enable transition WM

Hey, Mahesh Kumar schreef op di 13-06-2017 om 11:34 [+0530]: > GEN > 9 require transition WM to be programmed if IPC is enabled. > This patch calculates & enable transition WM for supported platforms. > If transition WM is enabled, Plane read requests are sent at high > priority until filling

Re: [Intel-gfx] Fixes that failed to backport to v4.12-rc1

On Thu, 08 Jun 2017, Ville Syrjälä wrote: > On Thu, Jun 08, 2017 at 05:47:23PM +0300, Jani Nikula wrote: >> On Thu, 08 Jun 2017, Ville Syrjälä wrote: >> > On Wed, Jun 07, 2017 at 04:45:07PM +0300, Jani Nikula wrote: >> >> On Mon, 15

Re: [Intel-gfx] Fixes that failed to backport to v4.12-rc1

On Mon, 15 May 2017, Jani Nikula wrote: > Continuing [1] for v4.12-rc1 > > The following commits have been marked as Cc: stable or fixing something > in v4.12-rc1 or earlier, but failed to cherry-pick to > drm-intel-fixes. Please see if they are worth backporting, and

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/glk: Split GLK DSI device ready functionality

== Series Details == Series: series starting with [1/2] drm/i915/glk: Split GLK DSI device ready functionality URL : https://patchwork.freedesktop.org/series/25700/ State : success == Summary == Series 25700v1 Series without cover letter

[Intel-gfx] [PATCH 1/2] drm/i915/glk: Split GLK DSI device ready functionality

This patch divides glk_dsi_device_ready() function into two part. First part will program LP wake and MIPI DSI mode to MIPI_CTRL reg using newly defined function glk_dsi_enable_io(). glk_dsi_enable_io() will be called from intel_dsi_pre_enable. Second part will do remaining device ready activities

[Intel-gfx] [PATCH 2/2] drm/i915/glk: Add cold boot sequence for GLK DSI

As per BSEPC, if device ready bit is '0' in enable IO sequence then its a cold boot/reset scenario eg: S3/S4 resume. If cold boot scenario detected in enable IO, then prepare port immediately. In normal boot scenario, prepare port after glk_dsi_device_ready(). Without cold boot sequence enabled,

Re: [Intel-gfx] [PATCH 2/6] drm/i915/hsw: use intel_compute_linetime_wm function for linetime wm

Mahesh Kumar schreef op di 13-06-2017 om 11:34 [+0530]: > linetime wm is time taken to fill a single display line with given > clock > rate, multiplied by 8. > This patch reuses the common code of hsw_compute_linetime_wm & > skl_compute_linetime_wm. > > Signed-off-by: Mahesh Kumar

Re: [Intel-gfx] [PATCH 1/6] drm/i915: cleanup fixed-point wrappers naming

On Tuesday 13 June 2017 01:08 PM, Lankhorst, Maarten wrote: Mahesh Kumar schreef op di 13-06-2017 om 11:34 [+0530]: This patch make naming of fixed-point wrappers consistent operation__<1st operand>_<2nd operand> also shorten the name for fixed_16_16 to fixed16

Re: [Intel-gfx] [PATCH 2/6] drm/i915/hsw: use intel_compute_linetime_wm function for linetime wm

On Tuesday 13 June 2017 01:00 PM, Lankhorst, Maarten wrote: Mahesh Kumar schreef op di 13-06-2017 om 11:34 [+0530]: linetime wm is time taken to fill a single display line with given clock rate, multiplied by 8. This patch reuses the common code of hsw_compute_linetime_wm &

Re: [Intel-gfx] [PATCH IGT] tests/chamelium: Require HPD storm control for basic hotplug test

On Tue, 2017-06-13 at 10:37 +0300, Paul Kocialkowski wrote: > On Mon, 2017-06-12 at 16:25 +0300, Paul Kocialkowski wrote: > > The basic hotplug test (test_basic_hotplug) makes calls to > > igt_hpd_storm_set_threshold, which requires HPD storm control. > > > > This adds a check for that control,

Re: [Intel-gfx] [PATCH 1/6] drm/i915: cleanup fixed-point wrappers naming

Mahesh Kumar schreef op di 13-06-2017 om 11:34 [+0530]: > This patch make naming of fixed-point wrappers consistent > operation__<1st operand>_<2nd operand> > also shorten the name for fixed_16_16 to fixed16 > > s/u32_to_fixed_16_16/u32_to_fixed16 > s/fixed_16_16_to_u32/fixed16_to_u32 >

Re: [Intel-gfx] [PATCH IGT] tests/chamelium: Require HPD storm control for basic hotplug test

On Mon, 2017-06-12 at 16:25 +0300, Paul Kocialkowski wrote: > The basic hotplug test (test_basic_hotplug) makes calls to > igt_hpd_storm_set_threshold, which requires HPD storm control. > > This adds a check for that control, since it was missing. +Lyude for Chamelium patches > Signed-off-by:

Re: [Intel-gfx] [PATCH IGT v2] tests/chamelium: Close DRM file descriptor after tests

On Tue, 2017-06-13 at 10:32 +0300, Paul Kocialkowski wrote: > From: Paul Kocialkowski > > This adds a call to close the DRM file descriptor. It is required as IGT > will attempt to become DRM master after running the test, resulting in a > failure. +Lyude for

Re: [Intel-gfx] [PATCH i-g-t] tests: Rename I915_MAX_PIPES to IGT_MAX_PIPES

On Mon, 12 Jun 2017, Harry Wentland wrote: > The email was sent but might be stuck in the moderation queue since Leo > (Sun peng) is fairly new on the FDO mailing lists. > > Jani, Daniel, can you check if Leo's IGT emails are stuck in the > moderation queue? Done. I've

[Intel-gfx] [PATCH i-g-t v2] tests: Increase value of I915_MAX_PIPES to 6

From: "Leo (Sunpeng) Li" Increasing max pipe count to 6 to support AMD GPU's. Since some tests' behavior depends on this value, small changes are made to remove this dependency: * kms_ccs: Early abort if wanted_pipe is out-of-bounds. * kms_concurrent: Check if pipe is

[Intel-gfx] [PATCH IGT v2] tests/chamelium: Close DRM file descriptor after tests

From: Paul Kocialkowski This adds a call to close the DRM file descriptor. It is required as IGT will attempt to become DRM master after running the test, resulting in a failure. Signed-off-by: Paul Kocialkowski ---

[Intel-gfx] [PATCH i-g-t] tests: Rename I915_MAX_PIPES to IGT_MAX_PIPES

From: "Leo (Sunpeng) Li" Name should not be driver-specific. Signed-off-by: Leo (Sunpeng) Li --- lib/igt_kms.c | 2 +- lib/igt_kms.h | 5 +++-- tests/kms_atomic_transition.c | 12 ++-- tests/kms_busy.c

[Intel-gfx] [PATCH i-g-t v3] tests: Increase value of I915_MAX_PIPES to 6

From: "Leo (Sunpeng) Li" Increasing max pipe count to 6 to support AMD GPU's. Since some tests' behavior depends on this value, small changes are made to remove this dependency: * kms_ccs: Early abort if wanted_pipe is out-of-bounds. * kms_concurrent: Check if pipe is

[Intel-gfx] [PATCH IGT v2 0/1] tests/chamelium: Close DRM file descriptor after tests

Changes since v1: * Fixed typo due to slow adaptation to qwerty layout ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests: Increase value of I915_MAX_PIPES to 6

On 2017-06-09 05:49 AM, Arkadiusz Hiler wrote: On Thu, Jun 08, 2017 at 09:48:58PM +, Deucher, Alexander wrote: -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of sunpeng...@amd.com Sent: Thursday, June 08, 2017 3:11 PM To:

Re: [Intel-gfx] [PATCH] drm/i915: Don't enable backlight at setup time.

On Mon, 12 Jun 2017, Dhinakaran Pandiyan wrote: > Maarten and Ville noticed that we are enabling backlight via DP aux very > early in the modeset_init path via the intel_dp_aux_setup_backlight() > function. Looks like all we need to do during _setup_backlight() is >

Re: [Intel-gfx] [PATCH] drm/i915: Don't enable backlight at setup time.

Op 12-06-17 om 22:16 schreef Dhinakaran Pandiyan: > Maarten and Ville noticed that we are enabling backlight via DP aux very > early in the modeset_init path via the intel_dp_aux_setup_backlight() > function. Looks like all we need to do during _setup_backlight() is > read the current brightness

[Intel-gfx] ✓ Fi.CI.BAT: success for Fixed16.16 wrapper cleanup & wm optimization

== Series Details == Series: Fixed16.16 wrapper cleanup & wm optimization URL : https://patchwork.freedesktop.org/series/25692/ State : success == Summary == Series 25692v1 Fixed16.16 wrapper cleanup & wm optimization https://patchwork.freedesktop.org/api/1.0/series/25692/revisions/1/mbox/

[Intel-gfx] [PATCH 1/6] drm/i915: cleanup fixed-point wrappers naming

This patch make naming of fixed-point wrappers consistent operation__<1st operand>_<2nd operand> also shorten the name for fixed_16_16 to fixed16 s/u32_to_fixed_16_16/u32_to_fixed16 s/fixed_16_16_to_u32/fixed16_to_u32 s/fixed_16_16_to_u32_round_up/fixed16_to_u32_round_up

  1   2   >