Re: [Intel-gfx] [PATCH] drm/i915: VGA also requires the power well

-Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Sunday, August 04, 2013 4:50 PM To: Paulo Zanoni Cc: Ville Syrjälä; intel-gfx@lists.freedesktop.org; Zanoni, Paulo R Subject: Re: [Intel-gfx] [PATCH] drm/i915: VGA also requires

Re: [Intel-gfx] Minor bug in intel-gpu-tools

Copying the appropriate mailing list. Thanks for the report! From: Patrick McMunn [mailto:doctorwho...@gmail.com] Sent: Thursday, December 19, 2013 7:59 AM To: Zanoni, Paulo R Subject: Minor bug in intel-gpu-tools I noticed that if I run ./configure --enable-shader-debugger, the configure

Re: [Intel-gfx] [PATCH] drm/i915: Fix build warning on 32-bit

Em Sex, 2015-08-14 às 12:35 +0200, Thierry Reding escreveu: From: Thierry Reding tred...@nvidia.com The gtt.stolen_size field is of type size_t, and so should be printed using %zu to avoid build warnings on either 32-bit and 64-bit builds. While the suggestion from Chris sounds good, this

Re: [Intel-gfx] [PATCH 08/16] drm/i915: avoid the last 8mb of stolen on BDW/SKL

Em Sáb, 2015-08-15 às 09:29 +0100, Chris Wilson escreveu: On Fri, Aug 14, 2015 at 06:34:13PM -0300, Paulo Zanoni wrote: The FBC hardware for these platforms doesn't have access to the bios_reserved range, so it always assumes the maximum (8mb) is used. So avoid this range while

Re: [Intel-gfx] [PATCH 0/7] More PSR patches

Em Sex, 2015-08-21 às 01:04 +, Rodrigo Vivi escreveu: This patch series brings stability to PSR on VLV, CHV, HSW and BDW. It fixes issues Matthew Garrett without causing the blank and frozen screens Ivan Mitev was facing. It also move the VLV/CHV workaround of that big delay from

Re: [Intel-gfx] [PATCH] drm/i915/skl: Update DDI buffer translation programming.

Em Qua, 2015-08-05 às 14:59 -0700, Rodrigo Vivi escreveu: SKL-Y can now use the same programming for all VccIO values after an adjustment to I_boost. SKL-U DP table adjustments. 1. Remove SKL Y 0.95V from SKL H and S columns in all tables. The other SKL Y column removes the 0.85V

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Remove duplicated dpcd write on hsw_psr_enable_sink.

Em Qui, 2015-08-20 às 17:55 -0700, Rodrigo Vivi escreveu: This is wrong since my commit (89251b17). The intention of that commit was to remove this one here that is also wrong anyway, but it was forgotten. You mentioned the current code is wrong, but it would be really nice if you could

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Fix PSR disable sequence on core platforms.

Em Qui, 2015-08-20 às 17:55 -0700, Rodrigo Vivi escreveu: According to spec the disable sequence is: Driver will do the following on PSR Disable. 1. Disable PSR in PSR control register, SRD_CTL[bit 31]. 2. Poll on PSR idle 3. Wait for VBlank 4. Disable VSC DIP. Shouldn't this be done at

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

Em Qui, 2015-08-20 às 17:55 -0700, Rodrigo Vivi escreveu: Many reasons here: - Hardware tracking also has hidden corner cases Can you please elaborate more on that? I really really really really really think we should try as hard as possible to cook some IGT cases if something is affecting us

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

Em Qui, 2015-08-20 às 17:55 -0700, Rodrigo Vivi escreveu: This affects PSR on VLV, CHV, HSW and BDW. When debuging the frozen screen caused by HW tracking with low power state I noticed that if we keep moving the mouse non stop you will miss the screen updates for a while. At least until we

Re: [Intel-gfx] [PATCH 15/16] Revert drm/i915: Allocate fbcon from stolen memory

Em Sáb, 2015-08-15 às 09:24 +0100, Chris Wilson escreveu: On Fri, Aug 14, 2015 at 06:34:20PM -0300, Paulo Zanoni wrote: This reverts commit 0ffb0ff283cca16f72caf29c44496d83b0c291fb. Technology has evolved and now we have eDP panels with 3200x1800 resolution. In the meantime, the BIOS

Re: [Intel-gfx] [SKL-DMC-BUGFIX 0/5] SKL PC10 entry fixes.

Em Ter, 2015-08-04 às 17:01 +0530, Sunil Kamath escreveu: On Tuesday 04 August 2015 12:17 AM, Zanoni, Paulo R wrote: Em Seg, 2015-08-03 às 21:55 +0530, Animesh Manna escreveu: The following patches helps to solve PC10 entry issue for SKL. Detailed description about the changes done

Re: [Intel-gfx] [SKL-DMC-BUGFIX 0/5] SKL PC10 entry fixes.

Em Seg, 2015-08-03 às 21:55 +0530, Animesh Manna escreveu: The following patches helps to solve PC10 entry issue for SKL. Detailed description about the changes done to solve the issue is mentioned in commit message of each patch. All these patches are send earlier for review as part of

Re: [Intel-gfx] [PATCH] drm/i915: Use dpcd read wake for sink crc calls.

Em Qui, 2015-08-20 às 16:23 -0700, Rodrigo Vivi escreveu: Let's use a native read with retry as suggested per spec to fix Sink CRC on SKL when PSR is enabled. With PSR enabled panel is probably taking more time to wake and dpcd read is faling. Does this commit actually fix any known problem

Re: [Intel-gfx] [PATCH 04/18] drm/i915: extract crtc_is_valid() on the FBC code

Em Qui, 2015-10-22 às 09:52 +0200, Maarten Lankhorst escreveu: > Op 20-10-15 om 15:49 schreef Paulo Zanoni: > > We're going to kill intel_fbc_find_crtc(), that's why a big part of > > the logic moved from intel_fbc_find_crtc() to crtc_is_valid(). > > > > Signed-off-by: Paulo Zanoni

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

Em Ter, 2015-10-20 às 16:59 +0100, Chris Wilson escreveu: > On Tue, Oct 20, 2015 at 11:49:49AM -0200, Paulo Zanoni wrote: > > There's no need to stop and restart FBC: a nuke should be fine. > > > > Signed-off-by: Paulo Zanoni > > --- > >  

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

Em Ter, 2015-10-20 às 17:03 +0100, Chris Wilson escreveu: > On Tue, Oct 20, 2015 at 11:49:51AM -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

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

Em Qua, 2015-10-21 às 18:31 +0100, ch...@chris-wilson.co.uk escreveu: > On Wed, Oct 21, 2015 at 05:08:42PM +0000, Zanoni, Paulo R wrote: > > Em Ter, 2015-10-20 às 16:59 +0100, Chris Wilson escreveu: > > > On Tue, Oct 20, 2015 at 11:49:49AM -0200, Paulo Zanoni wrote: > > >

Re: [Intel-gfx] [PATCH 07/18] drm/i915: fix the __intel_fbc_update() comments

Em Qua, 2015-10-21 às 13:37 +0100, Chris Wilson escreveu: > On Tue, Oct 20, 2015 at 11:49:53AM -0200, Paulo Zanoni wrote: > > Don't try to list in comments the cases where we should enable or > > disable FBC: it varies a lot with the hardware generations and the > > code should be the

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

Em Qua, 2015-10-21 às 09:24 +0200, Daniel Vetter escreveu: > On Wed, Oct 21, 2015 at 10:20:55AM +0300, Ville Syrjälä wrote: > > On Wed, Oct 21, 2015 at 09:11:08AM +0200, Daniel Vetter wrote: > > > On Tue, Oct 20, 2015 at 11:50:01AM -0200, Paulo Zanoni wrote: > > > > One of the problems with the

Re: [Intel-gfx] [PATCH 13/18] drm/i915: remove too-frequent FBC debug message

Em Qua, 2015-10-21 às 14:01 +0100, Chris Wilson escreveu: > On Tue, Oct 20, 2015 at 11:49:59AM -0200, Paulo Zanoni wrote: > > If we run igt/kms_frontbuffer_tracking, this message will appear > > thousands of times, eating a significant part of our dmesg buffer. > > It's part of the expected FBC

Re: [Intel-gfx] [PATCH 07/18] drm/i915: fix the __intel_fbc_update() comments

Em Qua, 2015-10-21 às 18:38 +0100, ch...@chris-wilson.co.uk escreveu: > On Wed, Oct 21, 2015 at 05:32:16PM +0000, Zanoni, Paulo R wrote: > > Em Qua, 2015-10-21 às 13:37 +0100, Chris Wilson escreveu: > > > On Tue, Oct 20, 2015 at 11:49:53AM -0200, Paulo Zanoni wrote: > &g

Re: [Intel-gfx] [PATCH 05/26] drm/i915: extract fbc_on_pipe_a_only()

Em Qui, 2015-10-29 às 13:05 +0100, Maarten Lankhorst escreveu: > Op 27-10-15 om 17:50 schreef Paulo Zanoni: > > Make the code easier to read. > > > > Suggested-by: Chris Wilson > > Signed-off-by: Paulo Zanoni > > --- > >  

Re: [Intel-gfx] [PATCH 02/26] drm/i915: don't stop+start FBC at every flip

Em Qui, 2015-10-29 às 19:30 +0200, Ville Syrjälä escreveu: > On Wed, Oct 28, 2015 at 07:20:12PM +0200, Ville Syrjälä wrote: > > On Wed, Oct 28, 2015 at 04:56:39PM +0000, Zanoni, Paulo R wrote: > > > Em Ter, 2015-10-27 às 20:32 +0200, Ville Syrjälä escreveu: > > > >

Re: [Intel-gfx] [PATCH 02/26] drm/i915: don't stop+start FBC at every flip

Em Ter, 2015-10-27 às 20:32 +0200, Ville Syrjälä escreveu: > On Tue, Oct 27, 2015 at 02:50:04PM -0200, Paulo Zanoni wrote: > > The hardware already takes care of disabling and recompressing FBC > > when we do a page flip, so all we need to do is to update the fence > > registers and move on. > >

Re: [Intel-gfx] [PATCH 02/26] drm/i915: don't stop+start FBC at every flip

Em Ter, 2015-10-27 às 19:50 +, Chris Wilson escreveu: > On Tue, Oct 27, 2015 at 02:50:04PM -0200, Paulo Zanoni wrote: > > @@ -1021,13 +1078,48 @@ void intel_fbc_flush(struct > > drm_i915_private *dev_priv, > >   if (origin == ORIGIN_GTT) > >   return; > >   > > + /* Hardware

Re: [Intel-gfx] [PATCH 23/26] drm/i915: use a single intel_fbc_work struct

Em Ter, 2015-10-27 às 20:29 +, Chris Wilson escreveu: > On Tue, Oct 27, 2015 at 02:50:25PM -0200, Paulo Zanoni wrote: > > diff --git a/drivers/gpu/drm/i915/i915_drv.h > > b/drivers/gpu/drm/i915/i915_drv.h > > index a9434d1..fdbe068 100644 > > --- a/drivers/gpu/drm/i915/i915_drv.h > > +++

Re: [Intel-gfx] [PATCH 04/18] drm/i915: extract crtc_is_valid() on the FBC code

Em Ter, 2015-10-20 às 16:52 +0100, Chris Wilson escreveu: > On Tue, Oct 20, 2015 at 11:49:50AM -0200, Paulo Zanoni wrote: > > We're going to kill intel_fbc_find_crtc(), that's why a big part of > > the logic moved from intel_fbc_find_crtc() to crtc_is_valid(). > > > > Signed-off-by: Paulo Zanoni

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

Em Qua, 2015-10-21 às 13:34 +0100, Chris Wilson escreveu: > On Tue, Oct 20, 2015 at 11:49:56AM -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

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

Em Ter, 2015-11-10 às 14:04 +0100, Maarten Lankhorst escreveu: > Op 10-11-15 om 13:20 schreef Zanoni, Paulo R: > > Em Ter, 2015-11-10 às 11:22 +0100, Maarten Lankhorst escreveu: > > > Op 04-11-15 om 20:10 schreef Paulo Zanoni: > > > > In function find_compress

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

Em Qua, 2015-11-11 às 16:27 +0200, Ville Syrjälä escreveu: > On Tue, Nov 10, 2015 at 02:04:48PM +0100, Maarten Lankhorst wrote: > > Op 10-11-15 om 13:20 schreef Zanoni, Paulo R: > > > Em Ter, 2015-11-10 às 11:22 +0100, Maarten Lankhorst escreveu: > > > > Op 04-11-15

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

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

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 10/13] drm/i915: fix the CFB size check

Em Ter, 2015-11-10 às 11:22 +0100, Maarten Lankhorst escreveu: > Op 04-11-15 om 20:10 schreef Paulo Zanoni: > > In function find_compression_threshold() we try to over-allocate > > CFB > > space in order to reudce reallocations and fragmentation, and we're > > not considering that at the CFB size

Re: [Intel-gfx] [PATCH 12/13] drm/i915: remove in_dbg_master check from intel_fbc.c

Em Qua, 2015-11-04 às 14:19 -0600, Jason Wessel escreveu: > On 11/04/2015 02:13 PM, Jesse Barnes wrote: > > On 11/04/2015 11:10 AM, Paulo Zanoni wrote: > > >  From our maintainer Daniel Vetter a few days ago: > > >    "Oh dear this is dead code. kdbg uses the fbcon, which always > > > uses > > >   

Re: [Intel-gfx] [PATCH i-g-t 8/8] tests/kms_fbc_crc: ensure context is initialized correctly

Em Seg, 2015-11-02 às 11:48 +, Thomas Wood escreveu: > Initialization was included in commit a976d7e (tests/kms_fbc_crc: > refactor context > handling code), but won't be executed since it is declared before the > first > label within a switch statement. > > kms_fbc_crc.c:178:2: warning:

Re: [Intel-gfx] [PATCH] drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style WM (v4)

Em Qui, 2015-10-15 às 15:42 -0700, Matt Roper escreveu: > Just pull the info out of the state structures rather than staging > it in an additional set of structures.  To make this more > straightforward, we change the signature of several internal WM > functions to take the crtc state as a

Re: [Intel-gfx] [PATCH 04/16] drm/i915: set ILK_DPFC_FENCE_YOFF to 0 on SNB

Em Sex, 2015-08-28 às 17:46 +0300, Ville Syrjälä escreveu: > On Fri, Aug 14, 2015 at 06:34:09PM -0300, Paulo Zanoni wrote: > > The doc is pretty clear that this register should be set to 0 on > > SNB. > > We already write y_offset to DPFC_CPU_FENCE_OFFSET a few lines > > below. > > Bspec says: >

Re: [Intel-gfx] [PATCH] drm/i915: Partial revert of atomic watermark series

ince I'll have to apply tons of additional patches on top of each bisect step... I'll try to discover what else is causing the problem. Anyway, thanks for the help! > > Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-Octob > er/077190.html > Cc: "Zanoni, Paulo R&quo

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

Em Qua, 2015-11-18 às 17:38 +0100, Daniel Vetter escreveu: > On Wed, Nov 18, 2015 at 5:20 PM, Paulo Zanoni > wrote: > > 2015-11-18 13:59 GMT-02:00 Daniel Vetter : > > > On Fri, Nov 13, 2015 at 03:12:41PM -0200, Paulo Zanoni wrote: > > > > Hello > > > > > > >

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

Em Qua, 2015-11-18 às 11:21 -0800, Rodrigo Vivi escreveu: > The ultimate goal here is to remove the dependency we > currently have on audio driver power to get PSR working. > Since with audio driver runtime PM disabled the Hardware tracking > believes graphics is fully active and prevent PSR

Re: [Intel-gfx] [PATCH 2/2] drm/i915: PSR: Mask LPSP hw tracking back again.

Em Qua, 2015-11-18 às 11:21 -0800, Rodrigo Vivi escreveu: > When we introduced PSR we let LPSP masked allowing us to get PSR > independently from the audio runtime PM. However in one of the > attempts to get PSR enabled by default one user reported one specific > case where he would miss screen

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Refactor common ringbuffer allocation code

Em Qui, 2015-09-03 às 13:01 +0100, Chris Wilson escreveu: > A small, very small, step to sharing the duplicate code between > execlists and legacy submission engines, starting with the ringbuffer > allocation code. > > Signed-off-by: Chris Wilson > Cc: Arun Siluvery

Re: [Intel-gfx] [PATCH 2/4] drm/i915: restrict unclaimed register checking

Em Sex, 2015-09-04 às 09:53 +0300, Mika Kuoppala escreveu: > Paulo Zanoni writes: > > > The unclaimed register bit is only triggered when someone touches > > the > > specified register range. > > > > I got the impression that we get the unclaimed access also > for

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Reduce frequency of unspecific HSW reg debugging

Em Sex, 2015-09-04 às 10:02 +0300, Mika Kuoppala escreveu: > Paulo Zanoni writes: > > > From: Chris Wilson > > > > Delay the expensive read on the FPGA_DBG register from once per > > mmio to > > once per forcewake section when we are doing

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Reduce frequency of unspecific HSW reg debugging

Em Sex, 2015-09-04 às 11:40 +0300, Mika Kuoppala escreveu: > Daniel Vetter writes: > > > On Thu, Sep 03, 2015 at 04:51:45PM -0300, Paulo Zanoni wrote: > > > From: Chris Wilson > > > > > > Delay the expensive read on the FPGA_DBG register from once per

Re: [Intel-gfx] [PATCH 2/2] drm/i915: restrict unclaimed register checking

Em Qua, 2015-08-26 às 08:44 +0100, Chris Wilson escreveu: > On Tue, Aug 25, 2015 at 07:03:42PM -0300, Paulo Zanoni wrote: > > The unclaimed register bit is only triggered when someone touches > > the > > specified register range. > > > > For the normal use case (with i915.mmio_debug=0), this

Re: [Intel-gfx] [PATCH 5/7] drm/i915: fix FBC buffer size checks

Em Qua, 2015-09-23 às 17:59 +0100, Chris Wilson escreveu: > On Wed, Sep 23, 2015 at 12:52:25PM -0300, Paulo Zanoni wrote: > > According to my experiments, the maximum sizes mentioned in the > > specification delimit how far in the buffer the hardware tracking > > can > > go. And the hardware seems

Re: [Intel-gfx] [PATCH 00/15] Atomic watermark updates (v5)

Em Qua, 2015-09-30 às 17:20 +0200, Daniel Vetter escreveu: > On Thu, Sep 24, 2015 at 03:53:05PM -0700, Matt Roper wrote: > > Previous version of the series was here: > > http://lists.freedesktop.org/archives/intel-gfx/2015-September/07 > > 5883.html > > > > Pretty minimal changes since the last

Re: [Intel-gfx] [PATCH 3/3] drm/i915: fix FBC buffer size checks

Em Qui, 2015-10-01 às 15:22 +0300, Ville Syrjälä escreveu: > On Wed, Sep 30, 2015 at 05:05:45PM -0300, Paulo Zanoni wrote: > > According to my experiments (and later confirmation from the > > hardware > > developers), the maximum sizes mentioned in the specification > > delimit > > how far in the

Re: [Intel-gfx] [PATCH 2/3] drm/i915: fix CFB size calculation

Em Qui, 2015-10-01 às 15:23 +0300, Ville Syrjälä escreveu: > On Thu, Oct 01, 2015 at 03:14:13PM +0300, Ville Syrjälä wrote: > > On Wed, Sep 30, 2015 at 05:05:44PM -0300, Paulo Zanoni wrote: > > > We were considering the whole framebuffer height, but the spec > > > says we > > > should only

Re: [Intel-gfx] [PATCH 2/3] drm/i915: fix CFB size calculation

Em Qui, 2015-10-01 às 21:11 +0300, Ville Syrjälä escreveu: > On Thu, Oct 01, 2015 at 05:47:11PM +0000, Zanoni, Paulo R wrote: > > Em Qui, 2015-10-01 às 15:23 +0300, Ville Syrjälä escreveu: > > > On Thu, Oct 01, 2015 at 03:14:13PM +0300, Ville Syrjälä wrote: > > > >

Re: [Intel-gfx] [PATCH] fixup! drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style WM (v3)

Em Qui, 2015-10-01 às 16:03 -0700, Matt Roper escreveu: > Cc: Paulo Zanoni > Signed-off-by: Matt Roper > --- > Paulo, I'm not positive that this is the cause of the issues you're > seeing, but > I did find this unwanted behavior change while

Re: [Intel-gfx] [PATCH i-g-t 1/2] build: fix unused-result warnings

Em Seg, 2015-09-07 às 12:34 +0100, Thomas Wood escreveu: > Signed-off-by: Thomas Wood > --- > benchmarks/kms_vblank.c| 7 --- > debugger/eudb.c| 4 +++- > lib/igt_aux.c | 8 ++-- > overlay/gpu-top.c | 4 +++- >

Re: [Intel-gfx] [PATCH igt 2/2] kms_frontbuffer_tracking: standardize the used FB sizes

Em Sex, 2015-12-04 às 16:28 +0100, Daniel Vetter escreveu: > On Wed, Dec 02, 2015 at 10:47:01AM -0200, Paulo Zanoni wrote: > > We want to make sure that both tiled and untiled buffers have the > > same > > size for the same width/height/format. This will allow better > > control > > over the

Re: [Intel-gfx] [maintainer-tools PATCH 2/2] dim: add a QUICKSTART section to dim.rst

Em Sex, 2015-12-04 às 10:40 +0200, Jani Nikula escreveu: > On Thu, 03 Dec 2015, Paulo Zanoni wrote: > > Because just running dim help doesn't give you the greater picture > > of > > the workflow. All the text here is based on an email written by > > Daniel > > Vetter, so

Re: [Intel-gfx] [PATCH i-g-t] RFC: split PM workarounds into separate lib

Em Ter, 2015-12-08 às 10:50 +0200, David Weinehall escreveu: > Since the defaults for some external power management related > settings > prevents us from testing our power management functionality properly, > we have to work around it. Currently this is done from the individual > test cases, but

Re: [Intel-gfx] [PATCH 00/11] Yet another FBC series, v3 part 2 v2

Em Qua, 2015-12-02 às 12:37 +, Chris Wilson escreveu: > On Wed, Dec 02, 2015 at 10:15:16AM -0200, Paulo Zanoni wrote: > > Hi > > > > This series includes the implementation for the review feedback > > given by Chris. > > I also removed the patch that transformed our 50ms timeout into a > >

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

Em Sáb, 2015-11-14 às 01:17 +0200, Ville Syrjälä escreveu: > On Fri, Nov 13, 2015 at 09:38:50PM +0000, 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: > > > >

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

Em Qui, 2015-11-19 às 13:16 +0200, Jani Nikula escreveu: > On Wed, 18 Nov 2015, "Zanoni, Paulo R" <paulo.r.zan...@intel.com> > wrote: > > Em Qua, 2015-11-18 às 11:21 -0800, Rodrigo Vivi escreveu: > > > Cc: Paulo Zanoni <paulo.r.zan...@intel.com> &

Re: [Intel-gfx] [V2 PATCH 2/2] drm/i915: start adding dp mst audio

Em Qui, 2015-11-19 às 13:07 +0200, Ander Conselvan De Oliveira escreveu: > (Cc'ing Paulo for the audio power domain question) > > On Wed, 2015-11-11 at 13:33 +0800, libin.y...@linux.intel.com wrote: > > From: Libin Yang > > > > This patch adds support for DP MST

Re: [Intel-gfx] Screen update issue (drm/i915/fbc: enable FBC by default on HSW and BDW)

Em Qua, 2016-06-08 às 22:35 +0100, Steven Honeyman escreveu: > Hi, Hi CC'ing the mailing list. > > With commit a98ee79317b4091cafb502b4ffdbbbe1335e298c to enable FBC by > default, I get a strange issue with screen update/refresh (sorry if > my > terminology is off - I'm not a graphics dev!). >

Re: [Intel-gfx] [PATCH] i915/fbc: Disable on HSW by default for now

Em Qui, 2016-06-09 às 11:58 -0400, Lyude escreveu: > From https://bugs.freedesktop.org/show_bug.cgi?id=96461 : > > This was kind of a difficult bug to track down. If you're using a > Haswell system running GNOME and you have fbc completely enabled and > working, playing videos can result in video

Re: [Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

Em Seg, 2016-06-13 às 13:47 +0200, Stefan Richter escreveu: > On Jun 10 Paulo Zanoni wrote: > > > > Since my test machines don't produce FIFO underrun errors, I tested > > this by > > creating a debugfs file that just calls > > intel_fbc_handle_fifo_underrun(). I'd > > appreciate some Tested-by

Re: [Intel-gfx] [PATCH] drm/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake

Em Sex, 2016-06-17 às 17:39 +0100, Chris Wilson escreveu: > Erratum SKL075: Display Flicker May Occur When Both VT-d And FBC Are > Enabled > > "Display flickering may occur when both FBC (Frame Buffer > Compression) > and VT - d (Intel® Virtualization Technology for Directed I/O) are > enabled >

Re: [Intel-gfx] [PATCH v3] drm/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake

Em Ter, 2016-06-21 às 08:25 +0100, Chris Wilson escreveu: > Erratum SKL075: Display Flicker May Occur When Both VT-d And FBC Are > Enabled > > "Display flickering may occur when both FBC (Frame Buffer > Compression) > and VT - d (Intel® Virtualization Technology for Directed I/O) are > enabled >

Re: [Intel-gfx] [PATCH v3] drm/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake

Em Qua, 2016-06-22 às 21:34 +0100, Chris Wilson escreveu: > On Tue, Jun 21, 2016 at 03:31:25PM +0200, Daniel Vetter wrote: > > > > On Tue, Jun 21, 2016 at 08:25:27AM +0100, Chris Wilson wrote: > > > > > > Erratum SKL075: Display Flicker May Occur When Both VT-d And FBC > > > Are Enabled > > > >

Re: [Intel-gfx] [PATCH] i915/fbc: Disable on HSW by default for now

Em Sex, 2016-06-10 às 08:44 +0200, Stefan Richter escreveu: > On Jun 09 Zanoni, Paulo R wrote: > > > > Em Qui, 2016-06-09 às 11:58 -0400, Lyude escreveu: > > > > > > From https://bugs.freedesktop.org/show_bug.cgi?id=96461 : > > > > > > This w

Re: [Intel-gfx] [PATCH v4 8/8] drm/i915: Remove vblank wait from hsw_enable_ips.

Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu: > intel_post_plane_update did an extra vblank wait that's no longer > needed when enabling ips. > > Signed-off-by: Maarten Lankhorst > --- >  drivers/gpu/drm/i915/intel_display.c | 3 --- >  1 file

Re: [Intel-gfx] [PATCH v4 6/8] drm/i915: Nuke fbc members from intel_crtc->atomic, v2.

Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu: > Factor out intel_fbc_supports_rotation ^ not anymore > and use it in > pre_plane_update as well. This leaves intel_crtc->atomic > empty, so remove it too. > > Changes since v1: > - Add a intel_fbc_supports_rotation helper.

Re: [Intel-gfx] [RFC 00/22] Add support for GuC-based SLPC

und up  > later. Will keep it vrefresh for now. I was under the impression that the VSyncFTUsec field wanted the more precise solution. Maybe Tom or someone else could clarify this to us. > > Thanks > Sagar > > > On 2/4/2016 1:55 AM, Zanoni, Paulo R wrote: > > Em Qua, 2016

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Instrument PSR parameter for debuging with link standby x link off.

Em Seg, 2016-02-01 às 10:49 -0800, Rodrigo Vivi escreveu: > Unfortunately we don't know all panels and platforms out there and we > found internal prototypes without VBT proper set but where only > link in standby worked well. > > So, before enable PSR by default let's instrument the PSR

Re: [Intel-gfx] [PATCH igt 1/3] lib/igt_fb: also call __gem_set_tiling for Y tiling

Em Sex, 2016-01-29 às 21:06 +0200, Ville Syrjälä escreveu: > On Fri, Jan 29, 2016 at 04:46:30PM -0200, Paulo Zanoni wrote: > > The interesting thing is that if we don't do this, we still get a > > Y tiled framebuffer, but there won't be a fence around it, which > > makes > > the GTT mmaps less

Re: [Intel-gfx] [RFC 00/22] Add support for GuC-based SLPC

Em Qua, 2016-01-20 às 18:26 -0800, tom.orou...@intel.com escreveu: > From: Tom O'Rourke > > SLPC (Single Loop Power Controller) is a replacement for > some host-based power management features.  The SLPC > implemenation runs in firmware on GuC. > > This series is a first

Re: [Intel-gfx] [PATCH 01/25] drm/i915/fbc: wait for a vblank instead of 50ms when enabling

fline with Daniel, so I just pushed the patches. Thanks, Paulo > > > On Tue, Jan 26, 2016 at 10:08 AM Zanoni, Paulo R <paulo.r.zanoni@inte > l.com> wrote: > > Em Ter, 2016-01-26 às 17:44 +, Rodrigo Vivi escreveu: > > > > > > > > > On

Re: [Intel-gfx] [PATCH v6 3/8] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v6.

Em Qua, 2016-02-24 às 11:24 +0100, Maarten Lankhorst escreveu: > Currently we perform our own wait in post_plane_update, > but the atomic core performs another one in wait_for_vblanks. > This means that 2 vblanks are done when a fb is changed, > which is a bit overkill. > > Merge them by creating

Re: [Intel-gfx] [PATCH v4.1 6/8] drm/i915: Nuke fbc members from intel_crtc->atomic, v3.

Em Seg, 2016-02-29 às 10:58 +0100, Maarten Lankhorst escreveu: > Whenever there's an update to the primary plane, > fbc_pre_update and fbc_post_update are called. Kill off > intel_crtc->atomic.update_fbc and now that intel_crtc->atomic > is empty, kill it off too. > > Changes since v1: > - Add a

Re: [Intel-gfx] [PATCH] drm/i915: Sink CRC: tune down error message at stop to debug_kms.

Em Qua, 2016-01-13 às 14:05 -0800, Rodrigo Vivi escreveu: > When we stop the sink CRC calculation we wait a while until the > counter > is reset to zero and return -ETIMEDOUT. However the sink crc was > calculated already by this point so we just ignore this return at > the main function. > > So,

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Instrument PSR parameter for possible quirks with link standby.

Em Qui, 2016-01-21 às 08:35 +0530, Thulasimani, Sivakumar escreveu: > > On 1/20/2016 10:32 PM, Zanoni, Paulo R wrote: > > Em Sex, 2015-12-11 às 08:39 -0800, Rodrigo Vivi escreveu: > > > Unfortunately we don't know all panels and platforms out there > > > and we &

Re: [Intel-gfx] [RFC 14/22] drm/i915/slpc: Notification of Display mode change

Em Qua, 2016-01-20 às 18:26 -0800, tom.orou...@intel.com escreveu: > From: Sagar Arun Kamble > > GuC SLPC need to be sent data related to Active pipes, refresh rates, > widi pipes, fullscreen pipes related via host to GuC display mode > change event. > This patch

Re: [Intel-gfx] [PATCH 04/25] drm/i915/fbc: introduce struct intel_fbc_reg_params

Em Qui, 2016-01-21 às 13:48 +0100, Maarten Lankhorst escreveu: > Op 19-01-16 om 14:35 schreef Paulo Zanoni: > > The early return inside __intel_fbc_update does not completely > > check > > all the parameters that affect the FBC register values. For > > example, > > we currently lack looking at

Re: [Intel-gfx] [PATCH 08/25] drm/i915/fbc: unconditionally update FBC during atomic commits

Em Qui, 2016-01-21 às 14:04 +0100, Maarten Lankhorst escreveu: > Op 19-01-16 om 14:35 schreef Paulo Zanoni: > > We unconditionally disable/update FBC even during the page flip > > IOCTLs, and an unconditional disable/update at every atomic commit > > touching the primary plane shouldn't impact PC

Re: [Intel-gfx] [PATCH 02/25] drm/i915/fbc: extract intel_fbc_can_activate()

Em Qui, 2016-01-21 às 12:35 +0100, Maarten Lankhorst escreveu: > Op 19-01-16 om 14:35 schreef Paulo Zanoni: > > Extract all the code that checks if the FBC configuration is valid > > to > > its own function, making __intel_fbc_update() much simpler. > > > > Signed-off-by: Paulo Zanoni

Re: [Intel-gfx] [PATCH 01/25] drm/i915/fbc: wait for a vblank instead of 50ms when enabling

Em Qui, 2016-01-21 às 15:17 +0100, Maarten Lankhorst escreveu: > Op 19-01-16 om 14:35 schreef Paulo Zanoni: > > Instead of waiting for 50ms, just wait until the next vblank, since > > it's the minimum requirement. The whole infrastructure of FBC is > > based > > on vblanks, so waiting for X

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for FBC crtc/fb locking + smaller fixes

Em Ter, 2016-01-19 às 14:50 +, Patchwork escreveu: > == Summary == > > Built on 20c388faff9d8c41ab27e825c685526561b892a2 drm-intel-nightly: > 2016y-01m-19d-13h-31m-46s UTC integration manifest > > Test kms_flip: > Subgroup basic-flip-vs-modeset: > pass   ->

Re: [Intel-gfx] [PATCH 01/25] drm/i915/fbc: wait for a vblank instead of 50ms when enabling

Em Qui, 2016-01-21 às 18:03 -0200, Paulo Zanoni escreveu: > Instead of waiting for 50ms, just wait until the next vblank, since > it's the minimum requirement. The whole infrastructure of FBC is > based > on vblanks, so waiting for X vblanks instead of X milliseconds sounds > like the correct way

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Instrument PSR parameter for possible quirks with link standby.

Em Sex, 2015-12-11 às 08:39 -0800, Rodrigo Vivi escreveu: > Unfortunately we don't know all panels and platforms out there and we > found internal prototypes without VBT proper set but where only > link in standby worked well. > > So, before enable PSR by default let's instrument the PSR

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Add PSR main link standby support back

Em Sex, 2015-12-11 às 08:39 -0800, Rodrigo Vivi escreveu: > Link standby support has been deprecated with 'commit 89251b177 > ("drm/i915: PSR: deprecate link_standby support for core > platforms.")' > > The reason for that is that main link in full off offers more power > savings and on HSW and

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_fbc_crc.c: No longer dependant on Cairo A setup function that used to use Cairo to draw 2 rectangles covering the whole screen has been changed to use igt_draw

Hi In our IGT/Kernel culture, patch commit titles (here, presented as the email subject) are usually small (under 70-80 chars) providing a quick summary of what the change does. Also, we try to make each patch contain a single logical and complete change. So, for example, one approach you could

Re: [Intel-gfx] [PATCH] tests/Android.mk: Make intel_residency CAIRO dependant

Em Ter, 2016-01-26 às 13:04 +, Derek Morton escreveu: > intel_residency has a cairo dependency through igt_fb.c. Remove it > if ANDROID_HAS_CAIRO is not defined. The patch looks good, so I pushed it so we can unbreak your build. Thanks, Paulo > > Signed-off-by: Derek Morton

Re: [Intel-gfx] [PATCH 01/25] drm/i915/fbc: wait for a vblank instead of 50ms when enabling

Em Ter, 2016-01-26 às 17:44 +, Rodrigo Vivi escreveu: > > > On Thu, Jan 21, 2016 at 12:03 PM Paulo Zanoni om> wrote: > > Instead of waiting for 50ms, just wait until the next vblank, since > > it's the minimum requirement. The whole infrastructure of FBC is > >

Re: [Intel-gfx] [PATCH] drm/i915: Sink CRC: tune down error message at stop to debug_kms.

Em Ter, 2016-01-19 às 22:21 +, Vivi, Rodrigo escreveu: > On Tue, 2016-01-19 at 17:46 +0000, Zanoni, Paulo R wrote: > > Em Qua, 2016-01-13 às 14:05 -0800, Rodrigo Vivi escreveu: > > > When we stop the sink CRC calculation we wait a while until the > > > counter > &

Re: [Intel-gfx] [PATCH 1/4] drm/i915: PSR Fix standby logic for PSR on non DDI-A for certain platforms.

Em Sex, 2015-12-11 às 08:39 -0800, Rodrigo Vivi escreveu: > Current platforms that support PSR on other port than A only support > link > standby mode. > > The logic here was wrong since 'commit 89251b177b ("drm/i915: PSR: > deprecate link_standby support for core platforms.") What's

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Change i915.enable_psr parameter to use per platform default.

Em Ter, 2016-02-16 às 12:27 +0200, Jani Nikula escreveu: > On Fri, 12 Feb 2016, Rodrigo Vivi wrote: > > This will give us flexibility to enable PSR by default > > independently so > > issues and corner cases in one platform won't affect others were we > > have > > it

Re: [Intel-gfx] [PATCH v4 1/8] drm/i915: Pass crtc state to modeset_get_crtc_power_domains.

Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu: > Use our newly created encoder_mask to iterate over the encoders. As someone who was not paying attention to the discussion of the previous patches related to this, I think it would be really good if your commit message could tell me

Re: [Intel-gfx] [PATCH v4 2/8] drm/i915: Unify power domain handling.

Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu: > Right now there's separate power domain handling for update_pipe and > modesets. Unify this and only grab POWER_DOMAIN_MODESET once. I would have split this in two separate commits: one for POWER_DOMAIN_MODESET, and the other for

Re: [Intel-gfx] [PATCH v4 3/8] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v4.

Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu: > Currently we perform our own wait in post_plane_update, > but the atomic core performs another one in wait_for_vblanks. > This means that 2 vblanks are done when a fb is changed, > which is a bit overkill. > > Merge them by creating

Re: [Intel-gfx] [PATCH v4 1/8] drm/i915: Pass crtc state to modeset_get_crtc_power_domains.

Em Qui, 2016-02-18 às 10:51 +0100, Maarten Lankhorst escreveu: > Op 17-02-16 om 18:54 schreef Zanoni, Paulo R: > > Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu: > > > Use our newly created encoder_mask to iterate over the encoders. > > As someone who

Re: [Intel-gfx] [PATCH v4 3/8] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v4.

Em Qui, 2016-02-18 às 14:22 +0100, Maarten Lankhorst escreveu: > Op 17-02-16 om 22:20 schreef Zanoni, Paulo R: > > Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu: > > > Currently we perform our own wait in post_plane_update, > > > but the atomi

  1   2   >