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 having to > > put the test code inside a for loop that

[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 | +---+---

[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 le

[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 a/tools/Makefile.am b/tools/Ma

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 05:53:

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 th

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 Reviewed-by: Chris Wilson

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 plan

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 Zanon

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 structure itself is confusing and

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 wrote: >> >> Maybe that's not the best approach, but I think we n

[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 --- lib/intel_chipset.h | 12 +++-

[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 --- lib/intel_chipset.h | 7 --- 1 file

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, just

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, w

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 requireme

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 requirement

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 runnin

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

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 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 scheduling the enable work so

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() co

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 wil

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 me

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 using

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 not

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 > >> to take the synchronous vb

[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 i

[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 the

[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 this

[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 unt

[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. Sig

[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 insertions(+), 6 deletions(-) d

[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 ori

[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 - drivers/gpu/drm/i915/in

[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 deletions(-) diff --git a/drive

[Intel-gfx] [PATCH 08/12] drm/i915: use a single intel_fbc_work struct

This was already on my TODO list, and was requested both by Chris and Ville, for different reasons. The advantages are avoiding a frequent malloc/free pair, and the locality of having the work structure embedded in dev_priv. The maximum used memory is also smaller since previously we could have mul

[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 a

[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 pat

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 always the case. > Currently frequenc

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 > > different > > passes/phases that

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 >> workqueue is another option, b

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 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 criti

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 when there are more then 8 outputs, >>> this i

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 transition. However we have > > t

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 didn't > had until this pat

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 powe

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 fre

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 to hide bugs. > > Please don't

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 > Fixes: be5651f2d581 ("drm/i915: Updat

[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 o

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 backed by stolen memory as well as oth

[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 missing properties in find_initial_plane_obj") Signed-off-by: Ville Sy

[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(+) diff --git a/tests/kms_fr

[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. Th

[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 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 changed, 1 insertion(+), 1 dele

[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 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 the

[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 an

[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 changed, 48 insertions(+), 4 del

[Intel-gfx] [PATCH igt 07/10] kms_frontbuffer_tracking: move flip_type to struct test_mode

Handle it just like we handle t->format. IMHO, it's better. Signed-off-by: Paulo Zanoni --- tests/kms_frontbuffer_tracking.c | 81 1 file changed, 40 insertions(+), 41 deletions(-) diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tra

[Intel-gfx] [PATCH igt 09/10] kms_frontbuffer_tracking: assert the stride changes at stridechange()

We were previously using igt_create_fb(), which decided the stride by itself: there was no guarantee that making a buffer 512 pixels bigger would make its stride change. We're setting our own stride now so we have some guarantees, but let's put an assertion just to make sure we're doing the right t

[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 +104,7 @@ static int creat

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, >> > and the nice >> > fix for that would make me re

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 introdu

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 hardwa

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 subsequent patches. > > In order to

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 evictin

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 out

[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 top of the fixed/cleaned error pa

[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 Signed-off-by: Ville Syrjälä --

[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 msm/mdp/mdp5/mdp5_plane.c like so: "BAD:!

[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. Signed-off-by: Ville Syrjälä --- drivers/gp

[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 a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 6fac133..77496e

[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 +++-- drivers/gpu/drm/drm_crtc.c | 15

[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(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/g

[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 ++-- drivers/gpu/drm/drm_crtc.c | 11 ++- include/drm/drm_crtc.h

[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ä --- drivers/gpu/drm/i915/intel_display.c | 13 --

[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: http://lists.freedesktop.org/archives/dri-devel/2015-Novembe

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: Added a brief documentation

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 of patch 02 and in order to

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 example: > > DIM_POST_APPLY_ACTION="EDITOR=\"

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: > > D

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: > > > > > > > Bob Paauwe writes: > > > > > > > > > Signed-

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 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 a

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 r

[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 O

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 over to access the whole obj

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

On Fri, Nov 13, 2015 at 04:33:50PM +0200, Jani Nikula wrote: > On Fri, 13 Nov 2015, Ville Syrjälä wrote: > > On Fri, Nov 13, 2015 at 12:16:59PM +, Chris Wilson wrote: > >> On Fri, Nov 13, 2015 at 02:05:39PM +0200, Ander Conselvan de Oliveira > >> wrote: > >> > Calling git --amend invokes the

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

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 relies > > > on the terminal for input. So don't

Re: [Intel-gfx] Warnings on boot resume on Dell XPS 13 (Skylake)

On Thu, 2015-11-12 at 08:58 -0800, Andrew Lutomirski wrote: > I have a brand-new XPS 13 Skylake laptop. It's running 4.3 plus some > wireless-next bits. Everything seems to more-or-less work (even > suspend/resume, although resume feels a bit slower than it should be > to my untrained eye, which

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

On Fri, 13 Nov 2015, Ville Syrjälä wrote: > On Fri, Nov 13, 2015 at 12:16:59PM +, 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 relies >> > on the terminal for input. So

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

On pe, 2015-11-13 at 10:52 +0200, Jani Nikula wrote: > 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 c

[Intel-gfx] [PATCH v4 6/7] drm/i915: add support for checking RPM atomic sections

In some cases we want to check whether we hold an RPM wakelock reference for the whole duration of a sequence. To achieve this add a new RPM atomic sequence counter that we increment any time the wakelock refcount drops to zero. Check whether the sequence number stays the same during the atomic se

[Intel-gfx] [PATCH v4 5/7] drm/i915: check that we hold an RPM wakelock ref before we put it

v2-v3: - unchanged v4: - keep the corresponding check in the get helper (Chris) Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_runtime_pm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c index 02b390

Re: [Intel-gfx] [PATCH] drm/i915: Do a better job at disabling primary plane in the noatomic case.

On Thu, 2015-11-12 at 14:58 +0100, Maarten Lankhorst wrote: > Op 12-11-15 om 14:37 schreef Ander Conselvan De Oliveira: > > On Wed, 2015-11-11 at 15:36 +0100, Maarten Lankhorst wrote: > > > When disable_noatomic is called plane_mask is not reliable yet, > > > and plane_state->visible = true even af

  1   2   >