Re: [Intel-gfx] [PATCH 1/8] drm: Add crtc->name and use it in debug messages

On Thu, 12 Nov 2015, ville.syrj...@linux.intel.com wrote: > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index 24c5434..ea00a69 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -677,6 +677,9 @@ int drm_crtc_init_with_planes(struct

[Intel-gfx] [PATCH maintainer-tools] dim: Remove git commit --amend from dim_apply

Calling git --amend invokes the editor, which will not run if it relies on the terminal for input. So don't do that from dim_apply. Signed-off-by: Ander Conselvan de Oliveira --- dim | 2 -- 1 file changed, 2 deletions(-) diff --git a/dim b/dim index

Re: [Intel-gfx] [PATCH maintainer-tools] dim: Remove git commit --amend from dim_apply

On Fri, Nov 13, 2015 at 02:05:39PM +0200, Ander Conselvan de Oliveira wrote: > Calling git --amend invokes the editor, which will not run if it relies > on the terminal for input. So don't do that from dim_apply. > > Signed-off-by: Ander Conselvan de Oliveira >

Re: [Intel-gfx] [PATCH 06/10] drm/i915/skl: don't toggle PW1 and MISC power wells on-demand

On Wed, Nov 04, 2015 at 07:24:15PM +0200, Imre Deak wrote: > With the DMC firmware installed we don't need to handle HW resources > that are handled automatically by the firmware. Besides beeing redundant > this can also interfere with the firmware, possibly getting it into a > broken/blocked

Re: [Intel-gfx] [PATCH 07/10] drm/i915/gen9: simplify DC toggling code

On Wed, Nov 04, 2015 at 07:24:16PM +0200, Imre Deak wrote: > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/i915/i915_reg.h | 1 + > drivers/gpu/drm/i915/intel_runtime_pm.c | 66 > ++--- > 2 files changed, 29 insertions(+), 38

Re: [Intel-gfx] [PATCH 08/10] drm/i915/skl: disable DC states before display core init/uninit

On Wed, Nov 04, 2015 at 07:24:17PM +0200, Imre Deak wrote: > We need to disable the DC states during display core init to sanitize > the HW state we inherit from the BIOS. We need to disable it during > display core uninit too, since the power well framework will leave it > enabled (since we get

Re: [Intel-gfx] [PATCH v3 0/7] drm/i915: improve the RPM device suspended assert

On Thu, 12 Nov 2015, Imre Deak wrote: > This is v3 of [1]. I addressed the review comments from Ville and Chris > and added an RPM atomic section check as well requested by Chris. I was > also considering using lockdep for more coverage, but decided to leave > that out for

Re: [Intel-gfx] [PATCH 05/10] drm/i915/skl: init/uninit display core as part of the HW power domain state

On Wed, Nov 04, 2015 at 07:24:14PM +0200, Imre Deak wrote: > We need to initialize the display core part early, before initializing > the rest of the display power state. This is also described in the bspec > termed "Display initialization sequence". Atm we run this sequence > during driver

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Delay first PSR activation.

>-Original Message- >From: Vivi, Rodrigo >Sent: Friday, November 13, 2015 3:08 AM >To: intel-gfx@lists.freedesktop.org; R, Durgadoss >Subject: Re: [Intel-gfx] [PATCH 1/4] drm/i915: Delay first PSR activation. > >On Thu, 2015-11-12 at 13:50 +, R, Durgadoss wrote: >> Hi Rodrigo, >> >> >

Re: [Intel-gfx] [PATCH 0/4] PSR Critical fixes

On Wed, Nov 11, 2015 at 11:37:06AM -0800, Rodrigo Vivi wrote: > Let's split critical PSR fixes from the series that contains other > reworks, stabilization and improvements. > > The second patch in this series isn't considered critical in terms > of functionality, but it depends on the first one

Re: [Intel-gfx] [PATCH maintainer-tools] dim: Replace git commit --amend from dim_apply with dimrc option

On Fri, 13 Nov 2015, Ander Conselvan de Oliveira wrote: > Introduce DIM_POST_APPLY_ACTION to dimrc that allows the user to specify > a command to be run after a patch is applied. Use eval so enviroment > variables can be overriden with the option. For

[Intel-gfx] [PATCH v3 6/9] drm/i915: Set crtc->name to "pipe A", "pipe B", etc.

From: Ville Syrjälä v2: Fix intel_crtc leak on failure to allocate the name Use a local 'name' variable to make things easier v3: Pass the name as a function arguemnt to drm_crtc_init_with_planes() (Jani) Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 4/9] drm/i915: Use crtc->name in debug messages

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 55 drivers/gpu/drm/i915/intel_fbdev.c | 5 ++-- 2 files changed, 33 insertions(+), 27 deletions(-)

[Intel-gfx] [PATCH v2 3/9] drm: Add plane->name and use it in debug prints

From: Ville Syrjälä v2: kstrdup() the name passed by the caller (Jani) Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c| 12 ++-- drivers/gpu/drm/drm_atomic_helper.c | 4 ++--

[Intel-gfx] [PATCH v3 0/9] drm: Give crtcs and planes actual names (v3)

From: Ville Syrjälä Another attempt to give crtcs and planes human friendly names. This time I pulled out coccinelle and added a 'name' parameter to all the crtc and plane init functions. Third time's the charm, eh? Previous series at:

[Intel-gfx] [PATCH 5/9] drm/i915: Use plane->name in debug prints

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 38 +--- 1 file changed, 22 insertions(+), 16 deletions(-) diff --git

Re: [Intel-gfx] [PATCH 4/6] drm/i915: Add support for stealing purgable stolen pages

Hi, On 11/11/15 10:36, ankitprasad.r.sha...@intel.com wrote: From: Chris Wilson If we run out of stolen memory when trying to allocate an object, see if we can reap enough purgeable objects to free up enough contiguous free space for the allocation. This is in principle very much like

Re: [Intel-gfx] [PATCH maintainer-tools] dim: Remove git commit --amend from dim_apply

On Fri, 2015-11-13 at 15:07 +, Tvrtko Ursulin wrote: > On 13/11/15 14:40, Ander Conselvan De Oliveira wrote: > > On Fri, 2015-11-13 at 12:31 +, Tvrtko Ursulin wrote: > > > On 13/11/15 12:16, Chris Wilson wrote: > > > > On Fri, Nov 13, 2015 at 02:05:39PM +0200, Ander Conselvan de Oliveira >

Re: [Intel-gfx] [PATCH maintainer-tools] dim: Replace git commit --amend from dim_apply with dimrc option

Hi Ander, On Fri, Nov 13, 2015 at 05:05:09PM +0200, Ander Conselvan de Oliveira wrote: > Introduce DIM_POST_APPLY_ACTION to dimrc that allows the user to specify > a command to be run after a patch is applied. Use eval so enviroment > variables can be overriden with the option. For example: > >

Re: [Intel-gfx] [PATCH 00/13] Yet another FBC series, v3 part 1

Hey, On 13 November 2015 at 16:36, Zanoni, Paulo R wrote: > Em Sex, 2015-11-13 às 15:49 +, Daniel Stone escreveu: >> On 4 November 2015 at 19:10, Paulo Zanoni >> wrote: >> > So Ville pointed a problem on patch 02/26 of the previous series,

[Intel-gfx] [PATCH] drm/i915: Fix GT frequency rounding

When we set and later readback a frequency value through sysfs interface, igt/pm_rpm assumes that we get same value back if it matches hw granularity. On bxt we have found out that this is not always the case. Currently frequency - hw ratio - frequency conversions round down, with few exceptions

[Intel-gfx] [PATCH maintainer-tools] dim: Replace git commit --amend from dim_apply with dimrc option

Introduce DIM_POST_APPLY_ACTION to dimrc that allows the user to specify a command to be run after a patch is applied. Use eval so enviroment variables can be overriden with the option. For example: DIM_POST_APPLY_ACTION="EDITOR=\"gedit -w\" git commit --amend" Signed-off-by: Ander Conselvan de

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Broxton doesn't use gen9 scaling for rps frequencies.

On to, 2015-11-12 at 10:14 -0800, Bob Paauwe wrote: > On Thu, 12 Nov 2015 10:35:00 +0200 > Imre Deak wrote: > > > On Wed, 2015-11-11 at 13:36 -0800, Bob Paauwe wrote: > > > On Tue, 10 Nov 2015 11:04:22 +0200 > > > Mika Kuoppala wrote: > > > >

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Clarify plane state during CRTC state dumps

On Thu, Nov 12, 2015 at 04:31:57PM -0800, Matt Roper wrote: > During state dumping, list planes that have an FB but are invisible > (e.g., because they're offscreen or clipped by other planes) as "not > visible" rather than "enabled." While we're at it, throw the bpp value > into the debugging

[Intel-gfx] [PATCH] drm/i915: Fix crtc_y assignment in intel_find_initial_plane_obj()

From: Ville Syrjälä Let's set crtc_y to 0 instead of setting src_y twice. Multiple assignments in one statement is a good way to hide bugs. Please don't do that. Cc: Maarten Lankhorst Fixes: be5651f2d581 ("drm/i915: Update

[Intel-gfx] [PATCH 1/9] drm: Pass 'name' to crtc and plane init functions

From: Ville Syrjälä Allow the driver to pass a crtc and plane names to the crtc and plane init functions. Will be used later to populate the crtc and plane name that gets printed in debug messages. Done with coccinelle for the most part. It choked on

[Intel-gfx] [PATCH 8/9] drm/i915: Don't leak primary/cursor planes on crtc init failure

From: Ville Syrjälä Call intel_plane_destroy() instead of drm_plane_cleanup() so that we also free the plane struct itself when bailing out of the crtc init. And make intel_plane_destroy() NULL tolerant to avoid having to check for it in the caller.

[Intel-gfx] [PATCH v2 7/9] drm/i915: Fix plane init failure paths

From: Ville Syrjälä Deal with errors from drm_universal_plane_init() in primary and cursor plane init paths (sprites were already covered). Also make the code neater by using goto for error handling. v2: Rebased due to drm_universal_plane_init() 'name' parameter

[Intel-gfx] [PATCH v2 2/9] drm: Add crtc->name and use it in debug messages

From: Ville Syrjälä v2: kstrdup() the name passed by the caller (Jani) Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c| 41 ++- drivers/gpu/drm/drm_atomic_helper.c | 56

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Setup clipped src/dest coordinates during FB reconstruction

On Thu, Nov 12, 2015 at 04:31:59PM -0800, Matt Roper wrote: > Plane state objects contain two copies of src/dest coordinates: the > original (requested by userspace) coordinates in the base > drm_plane_state object, and a second, clipped copy (i.e., what we > actually want to program to the

Re: [Intel-gfx] [PATCH 00/13] Yet another FBC series, v3 part 1

Hi Paulo, On 4 November 2015 at 19:10, Paulo Zanoni wrote: > So Ville pointed a problem on patch 02/26 of the previous series, and the nice > fix for that would make me rebase most of the subsequent patches. In order to > avoid blocking the other patches on the review

Re: [Intel-gfx] [PATCH] igt/igt_kms: Introduce get_first_connected_output (v2)

On 5 November 2015 at 01:34, Vivek Kasireddy wrote: > In some cases, we just need one valid (connected) output to perform > a test. This macro can help in these situations by not having to > put the test code inside a for loop that iterates over all the outputs. > > v2:

Re: [Intel-gfx] [PATCH 00/13] Yet another FBC series, v3 part 1

Em Sex, 2015-11-13 às 15:49 +, Daniel Stone escreveu: > Hi Paulo, > > On 4 November 2015 at 19:10, Paulo Zanoni > wrote: > > So Ville pointed a problem on patch 02/26 of the previous series, > > and the nice > > fix for that would make me rebase most of the

[Intel-gfx] [PATCH v3 9/9] drm/i915: Give meaningful names to all the planes

From: Ville Syrjälä Let's name our planes in a way that makes sense wrt. the spec: - skl+ -> "plane 1A", "plane 2A", "plane 1C", "cursor A" etc. - g4x+ -> "primary A", "primary B", "sprite A", "cursor C" etc. - pre-g4x -> "plane A", "cursor B" etc. v2: Rebase on

[Intel-gfx] [PATCH igt 01/10] lib/igt_fb: fix fb->size when provided by the user

I want to have a little more control over the size of the buffers in kms_frontbuffer_tracking, so I decided to start calling igt_create_fb_with_bo_size() instead of igt_create_fb(). The problem is that create_bo_for_fb() returns its own calculated size as size_ret instead of the actual used size.

[Intel-gfx] [PATCH igt 06/10] kms_frontbuffer_tracking: do page flips using the planes API

Add a new FLIP_PLANES enum so we can do "page flips" using it too. The goal is to exercise the fast modeset paths on the Kernel. Signed-off-by: Paulo Zanoni --- tests/kms_frontbuffer_tracking.c | 36 1 file changed, 36 insertions(+)

[Intel-gfx] [PATCH igt 00/10] igt_fb buffer sizes + kms_frontbuffer_tracking

Hello I've been carrying some local IGT patches that reduced the size of buffers created by igt_create_fb() so they would fit the stolen memory, but when I decided to test the tree without them, I concluded the lack of sane sizes was even causing test failures. So here's my attempt to fix this.

[Intel-gfx] [PATCH igt 10/10] kms_frontbuffer_tracking: add tilingchange subtest

During the review of a recent FBC patch, Ville pointed a problem that happens when we use the page flip IOCTL to switch between buffers that have different tiling formats. This test should catch the problem introduced by that patch - which was not merged, by the way, so the test should be passing.

[Intel-gfx] [PATCH igt 05/10] kms_frontbuffer_tracking: set our own size for the FBs we create

If we just call igt_create_fb(), the automatic size calculated by create_bo_for_fb() may be way too big for the FBC CFB, and this will result in SKIPs due to not enough stolen memroy. So in order to avoid that, let's compute our own sizes. Besides this, I want to make sure that both the untiled

[Intel-gfx] [PATCH igt 03/10] lib/igt_fb: fix open-coded ALIGN()

Maybe this will help someone's life in the future. Signed-off-by: Paulo Zanoni --- lib/igt_fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/igt_fb.c b/lib/igt_fb.c index 088bc0d..2818c9f 100644 --- a/lib/igt_fb.c +++ b/lib/igt_fb.c @@ -104,7

[Intel-gfx] [PATCH igt 04/10] lib/igt_fb: also pass the stride to igt_create_fb_with_bo_size()

If the caller is going to specify a custom size, it's likely that he will also specify a custom stride. The automatic stride picked by create_bo_for_fb() is too huge for tiled buffers, so if the caller wants smaller buffers, then he'll need a smaller stride too, otherwise the Kernel will reject

[Intel-gfx] [PATCH igt 08/10] kms_frontbuffer_tracking: expand badstride and stridechange

Make those subtests try to change the stride using multiple APIs so we can catch errors that affect full modesets, fast modesets and page flips. Signed-off-by: Paulo Zanoni --- tests/kms_frontbuffer_tracking.c | 52 1 file

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Support for pread/pwrite from/to non shmem backed objects

On 11/11/15 10:36, ankitprasad.r.sha...@intel.com wrote: From: Ankitprasad Sharma This patch adds support for extending the pread/pwrite functionality for objects not backed by shmem. The access will be made through gtt interface. This will cover objects

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Add support for mapping an object page by page

Hi, On 09/11/15 10:56, ankitprasad.r.sha...@intel.com wrote: From: Chris Wilson Introduced a new vm specfic callback insert_page() to program a single pte in ggtt or ppgtt. This allows us to map a single page in to the mappable aperture space. This can be iterated

Re: [Intel-gfx] [PATCH maintainer-tools] dim: Remove git commit --amend from dim_apply

On 13/11/15 14:40, Ander Conselvan De Oliveira wrote: On Fri, 2015-11-13 at 12:31 +, Tvrtko Ursulin wrote: On 13/11/15 12:16, Chris Wilson wrote: On Fri, Nov 13, 2015 at 02:05:39PM +0200, Ander Conselvan de Oliveira wrote: Calling git --amend invokes the editor, which will not run if it

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Dump pipe config after initial FB is reconstructed

On Thu, Nov 12, 2015 at 04:31:58PM -0800, Matt Roper wrote: > We dump during HW state readout, but that's too early to reflect how the > primary plane is actually configured. Hmm. Would be nice if we could read out everything at the same place, and then saniitize later. And maybe we could

[Intel-gfx] [PATCH igt 02/10] lib/igt_fb: fix igt_create_fb_with_bo_size() documentation

If we pass zero as the bo_size we won't get the minimum needed size, we'll just get a size that works. The size is decided by create_bo_for_fb(). The selected size is really not minimal for tiled objects. Signed-off-by: Paulo Zanoni --- lib/igt_fb.c | 2 +- 1 file

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Delay first PSR activation.

On Fri, 2015-11-13 at 09:09 +, R, Durgadoss wrote: > > -Original Message- > > From: Vivi, Rodrigo > > Sent: Friday, November 13, 2015 3:08 AM > > To: intel-gfx@lists.freedesktop.org; R, Durgadoss > > Subject: Re: [Intel-gfx] [PATCH 1/4] drm/i915: Delay first PSR > > activation. > > >

Re: [Intel-gfx] [PATCH] drm/i915: Fix GT frequency rounding

On Fri, Nov 13, 2015 at 07:29:41PM +0200, Mika Kuoppala wrote: > When we set and later readback a frequency value through > sysfs interface, igt/pm_rpm assumes that we get same value back > if it matches hw granularity. > > On bxt we have found out that this is not always the case. > Currently

Re: [Intel-gfx] [RFC] Docs: drm: Move KMS properties table out to source files

On Mon, 2015-09-28 at 11:33 -0600, Jonathan Corbet wrote: > On Mon, 28 Sep 2015 10:36:59 +0100 > Graham Whaley wrote: > > > I've still not thought of a way of tweaking the kernel-doc and > > pandoc > > processing to work around this either, as they are done as > >

Re: [Intel-gfx] [PATCH] drm/i915: Fix crtc_y assignment in intel_find_initial_plane_obj()

On Fri, 13 Nov 2015, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Let's set crtc_y to 0 instead of setting src_y twice. > > Multiple assignments in one statement is a good way to hide bugs. > Please don't do that. > > Cc: Maarten Lankhorst

[Intel-gfx] [PATCH 05/12] drm/i915: introduce intel_fbc_{enable, disable}

The goal is to call FBC enable/disable only once per modeset, while activate/deactivate/update will be called multiple times. The enable() function will be responsible for deciding if a CRTC will have FBC on it and then it will "lock" FBC on this CRTC: it won't be possible to change FBC's CRTC

[Intel-gfx] [PATCH 03/12] drm/i915: pass the crtc as an argument to intel_fbc_update()

There's no need to reevaluate the status of every single crtc when a single crtc changes its state. With this, we're cutting the case where due to a change in pipe B, intel_fbc_update() is called, then intel_fbc_find_crtc() concludes FBC should be enabled on pipe A, then it completely rechecks

[Intel-gfx] [PATCH 04/12] drm/i915: introduce is_active/activate/deactivate to the FBC terminology

The long term goal is to have enable/disable as the higher level functions and activate/deactivate as the lower level functions, just like we do for PSR and for the CRTC. This way, we'll run enable and disable once per modeset, while update, activate and deactivate will be run many times. With

[Intel-gfx] [PATCH 01/12] drm/i915: fix the CFB size check

In function find_compression_threshold() we try to over-allocate CFB space in order to reduce reallocations and fragmentation, and we're not considering that at the CFB size check. Consider it. There is also a longer-term plan to kill dev_priv->fbc.uncompressed_size, but this will come later.

[Intel-gfx] [PATCH 00/12] Yet another FBC series, v3 part 2

Hi Here are other 12 patches from the last series of 26 which I sent two weeks ago. The only things missing are the patch that does the flip optimizations - since it had a bug caught by Ville - and a patch requested by Chris related to getting framebuffer references or proving we don't need them.

[Intel-gfx] [PATCH 09/12] drm/i915: wait for a vblank instead of 50ms when enabling FBC

Instead of waiting for 50ms, just wait until the next vblank, since it's the minimum requirement. This moves PC7 residency on my specific BDW machine running Cinnamon from 60-70% to 84-89%. Without FBC, I get 20-25%. I'm using a 3200x1800 eDP panel. Notice: this was the case when the patch was

[Intel-gfx] [PATCH 10/12] drm/i915: kill fbc.uncompressed_size

Directly call intel_fbc_calculate_cfb_size() in the only place that actually needs it, and use the proper check before removing the stolen node. IMHO, this change makes our code easier to understand. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_drv.h | 1

Re: [Intel-gfx] [PATCH] drm/i915: Fix GT frequency rounding

On Fri, 13 Nov 2015 19:29:41 +0200 Mika Kuoppala wrote: > When we set and later readback a frequency value through > sysfs interface, igt/pm_rpm assumes that we get same value back > if it matches hw granularity. > > On bxt we have found out that this is not

Re: [Intel-gfx] [PATCH] drm/i915: Fix crtc_y assignment in intel_find_initial_plane_obj()

On Fri, Nov 13, 2015 at 07:36:08PM +0200, Jani Nikula wrote: > On Fri, 13 Nov 2015, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Let's set crtc_y to 0 instead of setting src_y twice. > > > > Multiple assignments in one statement is a good way

Re: [Intel-gfx] [PATCH 04/31] drm/i915: Handle actual IPS enabled state.

On Fri, Nov 13, 2015 at 06:20:00PM +, Daniel Stone wrote: > Hi Rodrigo, > > On 5 November 2015 at 18:49, Rodrigo Vivi wrote: > > With this we know if IPS is actually enabled. > > It might not be activated on BDW since Hardware take > > the decision and do its

Re: [Intel-gfx] Fixing i915/opregion issues with firmware which lists more then 8 output devices

On Fri, 06 Nov 2015, Hans de Goede wrote: > Hi, > > On 06-11-15 11:19, Jani Nikula wrote: >> On Thu, 05 Nov 2015, Hans de Goede wrote: >>> Hi, >>> >>> As discussed in the past, the i915 opregion code does not do the >>> right thing wrt the CADL field

Re: [Intel-gfx] [PATCH 0/4] PSR Critical fixes

On Fri, 2015-11-13 at 17:08 +0200, Ville Syrjälä wrote: > On Wed, Nov 11, 2015 at 11:37:06AM -0800, Rodrigo Vivi wrote: > > Let's split critical PSR fixes from the series that contains other > > reworks, stabilization and improvements. > > > > The second patch in this series isn't considered

Re: [Intel-gfx] [PATCH v2 10/12] drm/i915/gen9: Turn DC handling into a power well

On to, 2015-11-12 at 15:30 +0200, Imre Deak wrote: > On to, 2015-11-12 at 13:24 +0100, Patrik Jakobsson wrote: > > On Wed, Nov 11, 2015 at 08:57:19PM +0200, Imre Deak wrote: > > > On ma, 2015-11-09 at 16:48 +0100, Patrik Jakobsson wrote: > > > > Handle DC off as a power well where enabling the

Re: [Intel-gfx] [PATCH 04/31] drm/i915: Handle actual IPS enabled state.

Hi Rodrigo, On 5 November 2015 at 18:49, Rodrigo Vivi wrote: > With this we know if IPS is actually enabled. > It might not be activated on BDW since Hardware take > the decision and do its transition. However we have > the visibility of the state on our driver what we

[Intel-gfx] [PATCH 02/12] drm/i915: set dev_priv->fbc.crtc before scheduling the enable work

This thing where we need to get the crtc either from the work structure or the fbc structure itself is confusing and unnecessary. Set fbc.crtc right when scheduling the enable work so we can always use it. The problem is not what gets passed and how to retrieve it. The problem is that when we're

Re: [Intel-gfx] [PATCH 04/31] drm/i915: Handle actual IPS enabled state.

Hi, On 13 November 2015 at 18:38, Ville Syrjälä wrote: > On Fri, Nov 13, 2015 at 06:20:00PM +, Daniel Stone wrote: >> Maybe that's not the best approach, but I think we need to find a way >> to take the synchronous vblank wait out of the modeset path. Using a

[Intel-gfx] [PATCH 12/12] drm/i915: only nuke FBC when a drawing operation triggers a flush

There's no need to stop and restart FBC: a nuke should be fine. v2: Make it simpler (Chris). v3: Rewrite the patch again due to patch order changes. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_fbc.c | 8 ++-- 1 file changed, 6 insertions(+), 2

[Intel-gfx] [PATCH 06/12] drm/i915: alloc/free the FBC CFB during enable/disable

One of the problems with the current code is that it frees the CFB and releases its drm_mm node as soon as we flip FBC's enable bit. This is bad because after we disable FBC the hardware may still use the CFB for the rest of the frame, so in theory we should only release the drm_mm node one frame

[Intel-gfx] [PATCH 11/12] drm/i915: get rid of FBC {, de}activation messages

When running Cinnamon I see way too many pairs of these messages: many per second. Get rid of them as they're just telling us FBC is working as expected. We already have the messages for enable/disable, so we don't really need messages for activation/deactivation. v2: Rebase after changing the

[Intel-gfx] [PATCH 07/12] drm/i915: check for FBC planes in the same place as the pipes

This moves the pre-gen4 check from update() to enable(). The HAS_DDI in the original code is not needed since only gen 2/3 have the plane swapping code. v2: Rebase. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/intel_fbc.c | 9 +++-- 1 file changed, 3

Re: [Intel-gfx] [PATCH 07/12] drm/i915: check for FBC planes in the same place as the pipes

On Fri, Nov 13, 2015 at 05:53:39PM -0200, Paulo Zanoni wrote: > This moves the pre-gen4 check from update() to enable(). The HAS_DDI > in the original code is not needed since only gen 2/3 have the plane > swapping code. > > v2: Rebase. > > Signed-off-by: Paulo Zanoni

Re: [Intel-gfx] [PATCH 09/12] drm/i915: wait for a vblank instead of 50ms when enabling FBC

Em Sex, 2015-11-13 às 21:03 +, Chris Wilson escreveu: > On Fri, Nov 13, 2015 at 05:53:41PM -0200, Paulo Zanoni wrote: > > Instead of waiting for 50ms, just wait until the next vblank, since > > it's the minimum requirement. > > > > This moves PC7 residency on my specific BDW machine running >

Re: [Intel-gfx] [PATCH 09/12] drm/i915: wait for a vblank instead of 50ms when enabling FBC

On Fri, Nov 13, 2015 at 09:17:04PM +, Zanoni, Paulo R wrote: > Em Sex, 2015-11-13 às 21:03 +, Chris Wilson escreveu: > > On Fri, Nov 13, 2015 at 05:53:41PM -0200, Paulo Zanoni wrote: > > > Instead of waiting for 50ms, just wait until the next vblank, since > > > it's the minimum

Re: [Intel-gfx] [PATCH 04/12] drm/i915: introduce is_active/activate/deactivate to the FBC terminology

On Fri, Nov 13, 2015 at 05:53:36PM -0200, Paulo Zanoni wrote: > The long term goal is to have enable/disable as the higher level > functions and activate/deactivate as the lower level functions, just > like we do for PSR and for the CRTC. This way, we'll run enable and > disable once per modeset,

Re: [Intel-gfx] [PATCH 10/12] drm/i915: kill fbc.uncompressed_size

On Fri, Nov 13, 2015 at 05:53:42PM -0200, Paulo Zanoni wrote: > Directly call intel_fbc_calculate_cfb_size() in the only place that > actually needs it, and use the proper check before removing the stolen > node. IMHO, this change makes our code easier to understand. > > Signed-off-by: Paulo

Re: [Intel-gfx] [PATCH 11/12] drm/i915: get rid of FBC {, de}activation messages

On Fri, Nov 13, 2015 at 05:53:43PM -0200, Paulo Zanoni wrote: > When running Cinnamon I see way too many pairs of these messages: many > per second. Get rid of them as they're just telling us FBC is working > as expected. We already have the messages for enable/disable, so we > don't really need

Re: [Intel-gfx] [PATCH 06/12] drm/i915: alloc/free the FBC CFB during enable/disable

On Fri, Nov 13, 2015 at 05:53:38PM -0200, Paulo Zanoni wrote: > One of the problems with the current code is that it frees the CFB and > releases its drm_mm node as soon as we flip FBC's enable bit. This is > bad because after we disable FBC the hardware may still use the CFB > for the rest of the

Re: [Intel-gfx] [PATCH 09/12] drm/i915: wait for a vblank instead of 50ms when enabling FBC

On Fri, Nov 13, 2015 at 11:20:19PM +0200, Ville Syrjälä wrote: > On Fri, Nov 13, 2015 at 09:03:43PM +, Chris Wilson wrote: > > On Fri, Nov 13, 2015 at 05:53:41PM -0200, Paulo Zanoni wrote: > > > Instead of waiting for 50ms, just wait until the next vblank, since > > > it's the minimum

[Intel-gfx] [PATCH 1/2] lib/kbl: move KBL check from IS_SKYLAKE() to IS_GEN9()

Remove the KBL check from IS_SKYLAKE() following the kernel definition. Then, add the KBL check to IS_GEN9(). The idea is to avoid confusion. On the kernel side, the mix of SKY and KBL was nacked so the platforms are split. Signed-off-by: Wayne Boyer ---

[Intel-gfx] [PATCH 2/2] lib/kbl: Add Kabylake GT4 PCI IDs

Add the Kabylake GT4 PCI IDs as defined in this kernel patch. commit 8b10c0cf21ec84618d4bf02c73c0543500ece68d Author: Deepak S Date: Wed Oct 28 12:21:12 2015 -0700 drm/i915/kbl: Add Kabylake GT4 PCI ID Signed-off-by: Wayne Boyer

Re: [Intel-gfx] [PATCH 04/31] drm/i915: Handle actual IPS enabled state.

On 13 November 2015 at 20:28, Ville Syrjälä wrote: > On Fri, Nov 13, 2015 at 06:55:18PM +, Daniel Stone wrote: >> On 13 November 2015 at 18:38, Ville Syrjälä >> wrote: >> > On Fri, Nov 13, 2015 at 06:20:00PM +, Daniel Stone

Re: [Intel-gfx] [PATCH 02/12] drm/i915: set dev_priv->fbc.crtc before scheduling the enable work

On Fri, Nov 13, 2015 at 05:53:34PM -0200, Paulo Zanoni wrote: > This thing where we need to get the crtc either from the work > structure or the fbc structure itself is confusing and unnecessary. > Set fbc.crtc right when scheduling the enable work so we can always > use it. > > The problem is

Re: [Intel-gfx] [PATCH 09/12] drm/i915: wait for a vblank instead of 50ms when enabling FBC

On Fri, Nov 13, 2015 at 05:53:41PM -0200, Paulo Zanoni wrote: > Instead of waiting for 50ms, just wait until the next vblank, since > it's the minimum requirement. > > This moves PC7 residency on my specific BDW machine running Cinnamon > from 60-70% to 84-89%. Without FBC, I get 20-25%. I'm

Re: [Intel-gfx] [PATCH 03/12] drm/i915: pass the crtc as an argument to intel_fbc_update()

On Fri, Nov 13, 2015 at 05:53:35PM -0200, Paulo Zanoni wrote: > There's no need to reevaluate the status of every single crtc when a > single crtc changes its state. > > With this, we're cutting the case where due to a change in pipe B, > intel_fbc_update() is called, then intel_fbc_find_crtc()

Re: [Intel-gfx] [PATCH 05/12] drm/i915: introduce intel_fbc_{enable, disable}

On Fri, Nov 13, 2015 at 05:53:37PM -0200, Paulo Zanoni wrote: > The goal is to call FBC enable/disable only once per modeset, while > activate/deactivate/update will be called multiple times. > > The enable() function will be responsible for deciding if a CRTC will > have FBC on it and then it

Re: [Intel-gfx] [PATCH 04/31] drm/i915: Handle actual IPS enabled state.

On Fri, Nov 13, 2015 at 06:55:18PM +, Daniel Stone wrote: > Hi, > > On 13 November 2015 at 18:38, Ville Syrjälä > wrote: > > On Fri, Nov 13, 2015 at 06:20:00PM +, Daniel Stone wrote: > >> Maybe that's not the best approach, but I think we need to find a way

Re: [Intel-gfx] [PATCH 02/12] drm/i915: set dev_priv->fbc.crtc before scheduling the enable work

2015-11-13 18:56 GMT-02:00 Chris Wilson : > On Fri, Nov 13, 2015 at 05:53:34PM -0200, Paulo Zanoni wrote: >> This thing where we need to get the crtc either from the work >> structure or the fbc structure itself is confusing and unnecessary. >> Set fbc.crtc right when

Re: [Intel-gfx] [PATCH 09/12] drm/i915: wait for a vblank instead of 50ms when enabling FBC

On Fri, Nov 13, 2015 at 09:03:43PM +, Chris Wilson wrote: > On Fri, Nov 13, 2015 at 05:53:41PM -0200, Paulo Zanoni wrote: > > Instead of waiting for 50ms, just wait until the next vblank, since > > it's the minimum requirement. > > > > This moves PC7 residency on my specific BDW machine

Re: [Intel-gfx] [PATCH 09/12] drm/i915: wait for a vblank instead of 50ms when enabling FBC

Em Sex, 2015-11-13 às 23:26 +0200, Ville Syrjälä escreveu: > On Fri, Nov 13, 2015 at 11:20:19PM +0200, Ville Syrjälä wrote: > > On Fri, Nov 13, 2015 at 09:03:43PM +, Chris Wilson wrote: > > > On Fri, Nov 13, 2015 at 05:53:41PM -0200, Paulo Zanoni wrote: > > > > Instead of waiting for 50ms,

Re: [Intel-gfx] [PATCH 02/12] drm/i915: set dev_priv->fbc.crtc before scheduling the enable work

On Fri, Nov 13, 2015 at 07:13:40PM -0200, Paulo Zanoni wrote: > 2015-11-13 18:56 GMT-02:00 Chris Wilson : > > On Fri, Nov 13, 2015 at 05:53:34PM -0200, Paulo Zanoni wrote: > >> This thing where we need to get the crtc either from the work > >> structure or the fbc

Re: [Intel-gfx] [PATCH 01/12] drm/i915: fix the CFB size check

On Fri, Nov 13, 2015 at 05:53:33PM -0200, Paulo Zanoni wrote: > In function find_compression_threshold() we try to over-allocate CFB > space in order to reduce reallocations and fragmentation, and we're > not considering that at the CFB size check. Consider it. > > There is also a longer-term

Re: [Intel-gfx] [PATCH 12/12] drm/i915: only nuke FBC when a drawing operation triggers a flush

On Fri, Nov 13, 2015 at 05:53:44PM -0200, Paulo Zanoni wrote: drm/i915: Only trigger a FBC recompress after flushing a drawing operation > There's no need to stop and restart FBC: a nuke should be fine. There's no need to stop and restart FBC, which is quite expensive as we have to revalidate

Re: [Intel-gfx] [PATCH 09/12] drm/i915: wait for a vblank instead of 50ms when enabling FBC

On Fri, Nov 13, 2015 at 09:38:50PM +, Zanoni, Paulo R wrote: > Em Sex, 2015-11-13 às 23:26 +0200, Ville Syrjälä escreveu: > > On Fri, Nov 13, 2015 at 11:20:19PM +0200, Ville Syrjälä wrote: > > > On Fri, Nov 13, 2015 at 09:03:43PM +, Chris Wilson wrote: > > > > On Fri, Nov 13, 2015 at

[Intel-gfx] [Regression report] Weekly regression report WW46

WW46 Regression report There was no new reported regressions this week. Actual Regressions: +---+---+++ | BugId | Summary | Created on | Bisect |

Re: [Intel-gfx] [PATCH] igt/igt_kms: Introduce get_first_connected_output (v2)

On Fri, 13 Nov 2015 15:59:21 + Thomas Wood wrote: > On 5 November 2015 at 01:34, Vivek Kasireddy > wrote: > > In some cases, we just need one valid (connected) output to perform > > a test. This macro can help in these situations by not

[Intel-gfx] [PATCH] drm/i915: PSR: Let's rely more on frontbuffer tracking.

The ultimate goal here is to remove the dependency we currently have on audio driver power to get PSR working. With audio driver runtime PM disabled the Hardware tracking believes graphics is fully active and prevent PSR Entry, or in other words continuously exit PSR. When we introduced PSR we

[Intel-gfx] [PATCH igt] tools/aubdump: Link with -ldl.

aubdump.c uses dlsym(), so it needs to link with -ldl. Otherwise: /bin/sh: symbol lookup error: /usr/lib64/intel_aubdump.so: undefined symbol: dlsym Signed-off-by: Matt Turner --- tools/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [Intel-gfx] [PATCH 10/10] drm/i915/skl: remove redundant DDI/IRQ reinitialization during PW1 enabling

On Wed, Nov 04, 2015 at 07:24:19PM +0200, Imre Deak wrote: > We don't need to reinit DDI and IRQs during PW1 enabling any more, since > we don't toggle PW1 on-demand any more. We enable PW1 only as part of > the display core init sequence and after this we initialize both DDI and > IRQs later in

Re: [Intel-gfx] [PATCH 09/10] drm/i915/skl: make sure LCPLL is disabled when uniniting CDCLK

On Wed, Nov 04, 2015 at 07:24:18PM +0200, Imre Deak wrote: > Suppressing LCPLL disabling was added to avoid interfering with the DMC > firmware. It is not needed any more since we uninit CDCLK now with the > DMC deactivated (DC states disabled). We also must disable it during system > suspend as

  1   2   >