[Intel-gfx] [RFC] Idleness DRRS test

2016-08-31 Thread Nautiyal Ankit
From: aknautiy Idleness DRRS: By default the DRRS state will be at DRRS_HIGH_RR. When a Display content is Idle for more than 1Sec Idleness will be declared and DRRS_LOW_RR will be invoked, changing the refresh rate to the lower most refresh rate supported by the p

Re: [Intel-gfx] [PATCH v2] drm/i915: Nonblocking request submission

2016-08-31 Thread Joonas Lahtinen
On ti, 2016-08-30 at 12:18 +0100, Chris Wilson wrote: > Now that we have fences in place to drive request submission, we can > employ those to queue requests after their dependencies as opposed to > stalling in the middle of an execbuf ioctl. (However, we still choose to > spin before enabling the

[Intel-gfx] [PATCH 2/9] drm/i915: Replace intel_plane->wait_req with plane->fence

2016-08-31 Thread Chris Wilson
Now that we subclass our request from struct fence, we start using the common primitives more freely and so avoid hand-rolling routines already provided for by the helpers. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_atomic_plane.c | 3 -- drivers/gpu/drm/i915/intel_display.c

[Intel-gfx] [PATCH 9/9] drm/i915: Remove i915_gem_object_to_ggtt()

2016-08-31 Thread Chris Wilson
With the last user of this convenience wrapper gone, we can kill the wrapper and in the process make the lookup function static. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 12 drivers/gpu/drm/i915/i915_gem_gtt.c | 24 2 files chang

[Intel-gfx] [PATCH 5/9] drm/i915: Track pinned vma in intel_plane_state

2016-08-31 Thread Chris Wilson
With atomic plane states we are able to track an allocation right from preparation, during use and through to the final free after being swapped out for a new plane. We can couple the VMA we pin for the framebuffer (and its rotation) to this lifetime and avoid all the clumsy lookups in between. Si

[Intel-gfx] [PATCH 6/9] drm/i915: Quick spring clean of intel_prepare_plane_fb()

2016-08-31 Thread Chris Wilson
Just a quick tidy now to make the next patch neater. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c | 43 +--- 1 file changed, 25 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_

[Intel-gfx] [PATCH 4/9] drm/i915: Always prepare planes at the start of an atomic commit

2016-08-31 Thread Chris Wilson
The generic atomic helper likes to skip a prepare_plane_fb() if it decides that the plane->fb is unchanged. This is wrong for us for a couple of reasons: - if the pipe is reconfigured (i.e. a size change) but the framebuffer is untouched, we still have to flush any rendering prior to the re

[Intel-gfx] [PATCH 7/9] drm/i915: Set crtc_state->fb_changed whenever a VMA is changed

2016-08-31 Thread Chris Wilson
Since an fb may have multiple VMA (due to rotations etc), we need to wait a vblank and unpin the old VMA not if the fb itself is changed, but if the underlying VMA is changed. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c | 10 +++--- 1 file changed, 7 insertions(+), 3

[Intel-gfx] [PATCH 1/9] drm: Add reference counting to drm_atomic_state

2016-08-31 Thread Chris Wilson
drm_atomic_state has a complicated single owner model that tracks the single reference from allocation through to destruction on another thread - or perhaps on a local error path. We can simplify this tracking by using reference counting (at a cost of a few more atomics). This is even more benefici

[Intel-gfx] [PATCH 8/9] drm/i915: Update debugfs describe_obj() to show fault-mappable

2016-08-31 Thread Chris Wilson
The current meaning of whether an object has a GGTT vma is very ill-defined (and note we don't check for any partials either), it just means that at some point it was in the GGTT but it may not be now. The information we really care about here is whether it is taking up precious mappable aperture s

[Intel-gfx] [PATCH 3/9] drm/i915: Move intel_prepare_plane_fb() and intel_cleanup_plane_fb()

2016-08-31 Thread Chris Wilson
In the next patch, a few rearrangements are made to make these static. First, we move them so the changes are not lost in the noise. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_display.c | 239 ++- 1 file changed, 120 insertions(+), 119 deletions(-)

Re: [Intel-gfx] [PATCH 1/7] drm/i915/hsw+: set intel_crtc active once pipe is active

2016-08-31 Thread Maarten Lankhorst
Op 29-08-16 om 14:35 schreef Kumar, Mahesh: > Set the intel_crtc->active flag after pipe/crtc is actually active in > haswell_crtc_enable function. > > Signed-off-by: Kumar, Mahesh I think more state needs to be pre-calculated, rather than touching intel_crtc->active. Something like using the .in

Re: [Intel-gfx] [PATCH 12/18] drm/i915: Drive request submission through fence callbacks

2016-08-31 Thread John Harrison
On 30/08/2016 09:18, Chris Wilson wrote: Drive final request submission from a callback from the fence. This way the request is queued until all dependencies are resolved, at which point it is handed to the backend for queueing to hardware. At this point, no dependencies are set on the request, s

Re: [Intel-gfx] [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status

2016-08-31 Thread Mika Kahola
On Sat, 2016-08-27 at 14:33 +0100, Matthew Auld wrote: > Currently it's entirely possible to go through the link training step > without first determining the lane_count, which is silly since we end > up > doing a bunch of aux transfers of size = 0, as highlighted by > WARN_ON(!msg->buffer != !msg-

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/9] drm: Add reference counting to drm_atomic_state

2016-08-31 Thread Patchwork
== Series Details == Series: series starting with [1/9] drm: Add reference counting to drm_atomic_state URL : https://patchwork.freedesktop.org/series/11818/ State : failure == Summary == Series 11818v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/11818/revision

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Remove i915_gem_object_to_ggtt()

2016-08-31 Thread Joonas Lahtinen
On ke, 2016-08-31 at 10:11 +0100, Chris Wilson wrote: > With the last user of this convenience wrapper gone, we can kill the > wrapper and in the process make the lookup function static. > > Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Regards, Joonas -- Joonas Lahtinen Open Sourc

Re: [Intel-gfx] [PATCH igt 1/2] igt: Add test case for EXEC_OBJECT_ASYNC

2016-08-31 Thread Joonas Lahtinen
On ti, 2016-08-30 at 11:00 +0100, Chris Wilson wrote: > +static void store_dword(int fd, unsigned ring, > + uint32_t target, uint32_t offset, uint32_t value) > +{ I'd prefer a library function (as you obviously copied this from gem_exec_store.c), as we have more similar functio

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

2016-08-31 Thread Maarten Lankhorst
Hey, Op 29-08-16 om 14:35 schreef Kumar, Mahesh: > This patch implements new DDB allocation algorithm as per HW team > suggestion. This algo takecare of scenario where we allocate less DDB > for the planes with lower relative pixel rate, but they require more DDB > to work. > It also takes care of

Re: [Intel-gfx] [PATCH] FOR_UPSTREAM [VPG]: drm/i915/skl+: Implement Transition WM

2016-08-31 Thread Zanoni, Paulo R
Em Ter, 2016-08-30 às 19:32 +, Zanoni, Paulo R escreveu: > Hi > > Em Seg, 2016-08-29 às 18:05 +0530, Kumar, Mahesh escreveu: > > > > This patch enables Transition WM for SKL+ platforms. > > > > Transition WM are used if IPC is enabled, to decide, number of > > blocks > > to be fetched before

Re: [Intel-gfx] [PATCH 1/7] drm/i915/hsw+: set intel_crtc active once pipe is active

2016-08-31 Thread Mahesh Kumar
earlier implementation of "DDB writing" was using this flag before wait_for_vblank if we need to expand the DDB & it overlap with other pipe's DDB. In that case, I observed on corner case requiring a cd-clock change, intel_update_watermarks was waiting for vblank, when it was called from haswel

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

2016-08-31 Thread Mahesh Kumar
Hi, In this series, I'm not equalizing watermarks among planes of all CRTC's, these patches equalizing it only among Planes of single CRTC from DDB pool allocated for that CRTC, which doesn't require wait_for_vblank So it'll not affect the FPS. On Wednesday 31 August 2016 07:08 PM, Maarten Lan

[Intel-gfx] [PATCH 03/10] drm: Move all decl for drm_edid.c to drm_edid.h

2016-08-31 Thread Daniel Vetter
Some were still left in drm_crtc.h. Also include drm_edid.h in the rst files. Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-kms-helpers.rst | 3 +++ include/drm/drm_crtc.h| 30 +- include/drm/drm_edid.h| 30 +++

[Intel-gfx] [PATCH 00/10] More splitting&documenting for drm_crtc.c

2016-08-31 Thread Daniel Vetter
Hi all, It's not entirely done yet, there's a few (very small bits) left in drm_crtc.c which aren't for struct drm_crtc. But I figured it's better to keep things in manageable pieces. More important this now contains my proposal for how to best document (atomic) property extensions. I grouped and

[Intel-gfx] [PATCH 01/10] drm: Move a few macros away from drm_crtc.h

2016-08-31 Thread Daniel Vetter
Now that there's less stuff in there I noticed that I overlooked them. Sprinkle some docs over them while at it. Signed-off-by: Daniel Vetter --- include/drm/drm_connector.h | 24 ++-- include/drm/drm_crtc.h| 32 include/drm/drm_enco

[Intel-gfx] [PATCH 07/10] drm/doc: Polish plane composition property docs

2016-08-31 Thread Daniel Vetter
Try to spec a bit more precisely how they all fit together, now that at least the code is for all the additional properties is in one place. Also remove the entries for the standardized properties from the table, because that thing is supremely unmaintaineable. Cc: Ville Syrjälä Cc: Sean Paul C

[Intel-gfx] [PATCH 05/10] drm/doc: Polish for drm_plane.[hc]

2016-08-31 Thread Daniel Vetter
Big thing is untangling and carefully documenting the different uapi types of planes. I also sprinkled a few more cross references around to make this easier to discover. As usual, remove the kerneldoc for internal functions which are not exported. Aside: We should probably go OCD on all the ioctl

[Intel-gfx] [PATCH 06/10] drm: Conslidate blending properties in drm_blend.[hc]

2016-08-31 Thread Daniel Vetter
Imo zpos, rotatation, blending eq (once we have it) and all that should be in drm_blend.c, since those are all about how exactly the pixels are rendered onto the CRTC's visible area. Also noticed that one exported function accidentally ended up in drm_crtc_internal.h, move it to the right place too

[Intel-gfx] [PATCH 08/10] drm: Extract drm_color_mgmt.[hc]

2016-08-31 Thread Daniel Vetter
For both the new degamm/lut/gamma atomic combo, and the old legacy gamma tables. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/Makefile| 2 +- drivers/gpu/drm/drm_color_mgmt.c| 248 drivers/gpu/drm/drm_crtc.c | 220 --

[Intel-gfx] [PATCH 02/10] drm: Extract drm_bridge.h

2016-08-31 Thread Daniel Vetter
We don't want to burry the bridge structures kerneldoc in drm_crtc.h. Cc: Archit Taneja Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-kms-helpers.rst | 7 ++ drivers/gpu/drm/drm_bridge.c | 5 +- include/drm/drm_bridge.h | 218 ++

[Intel-gfx] [PATCH 10/10] drm: Remove dirty property from docs

2016-08-31 Thread Daniel Vetter
We removed it in commit 6ab10b76ff6252bd9be0849c40f5865e39a29961 Author: Daniel Vetter Date: Fri Aug 12 22:48:45 2016 +0200 drm/kms: Nuke dirty_info property Signed-off-by: Daniel Vetter --- Documentation/gpu/kms-properties.csv | 1 - 1 file changed, 1 deletion(-) diff --git a/Document

[Intel-gfx] [PATCH 09/10] drm/doc: Document color space handling

2016-08-31 Thread Daniel Vetter
Again move it from the unmaintainable csv into DOC free-form overview sections. Cc: Lionel Landwerlin Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-kms.rst| 12 + Documentation/gpu/kms-properties.csv | 5 drivers/gpu/drm/drm_color_mgmt.c | 48 +

[Intel-gfx] [PATCH 04/10] drm: Extract drm_plane.[hc]

2016-08-31 Thread Daniel Vetter
Just pure code movement, cleanup and polish will happen in later patches. v2: Don't forget all the ioctl! To extract those cleanly I decided to put check_src_coords into drm_framebuffer.c (and give it a drm_framebuffer_ prefix), since that just checks framebuffer constraints. Signed-off-by: Danie

[Intel-gfx] [PATCH v2 3/7] drm/i915: sseu: Simplify debugfs status/info printing

2016-08-31 Thread Imre Deak
Reviewed-by: Robert Bragg Reviewed-by: Ben Widawsky Tested-by: Ben Widawsky Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_debugfs.c | 64 - 1 file changed, 34 insertions(+), 30 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/driver

[Intel-gfx] [PATCH v2 4/7] drm/i915: sseu: Convert slice count field to mask

2016-08-31 Thread Imre Deak
In an upcoming patch we'll need the actual mask of slices in addition to their count, so replace the count field with a mask. v2: - Use hweight8() on u8 typed vars instead of hweight32(). (Ben) Reviewed-by: Robert Bragg (v1) Reviewed-by: Ben Widawsky (v1) Tested-by: Ben Widawsky (v1) Signed-of

[Intel-gfx] [PATCH v2 5/7] drm/i915: sseu: Convert subslice count fields to subslice mask

2016-08-31 Thread Imre Deak
In an upcoming patch we'll need the actual mask of subslices in addition to their count, so convert the subslice_per_slice field to a mask. Also we can easily calculate subslice_total from the other fields, so instead of storing a cached version of this, add a helper to calculate it. v2: - Use hwe

[Intel-gfx] [PATCH v2 0/7] drm/i915: Read out slice/subslice masks

2016-08-31 Thread Imre Deak
This is v2 of [1] rebased on latest -nightly and addressing the comments from Ben. It's needed by the per-slice/-subslice INSTDONE readout patchset from Ben that I'm planning to send as a follow-up to this. [1] https://lists.freedesktop.org/archives/intel-gfx/2015-October/078543.html Imre Deak (7

[Intel-gfx] [PATCH v2 2/7] drm/i915: sseu: Use sseu_dev_info in device info

2016-08-31 Thread Imre Deak
Move all slice/subslice/eu related properties to the sseu_dev_info struct. No functional change. v2: - s/info/sseu/ based on the new struct name. (Ben) Reviewed-by: Robert Bragg (v1) Reviewed-by: Ben Widawsky (v1) Tested-by: Ben Widawsky (v1) Signed-off-by: Imre Deak --- drivers/gpu/drm/i91

[Intel-gfx] [PATCH v2 7/7] drm/i915/bdw: sseu: Fix sseu status parsing

2016-08-31 Thread Imre Deak
Currently when checking for fused off EUs we may ignore the EU count in an enabled slice if there is any disabled slice preceding the enabled one (with a lower slice ID). Perhaps this can't happen in reality, but there is no reason to have this assumption built-in, the code is clearer without it.

[Intel-gfx] [PATCH v2 6/7] drm/i915: sseu: Add debug printf for slice/subslice masks

2016-08-31 Thread Imre Deak
Reviewed-by: Robert Bragg Reviewed-by: Ben Widawsky Tested-by: Ben Widawsky Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_debugfs.c | 4 drivers/gpu/drm/i915/intel_device_info.c | 2 ++ 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/dri

[Intel-gfx] [PATCH v2 1/7] drm/i915: sseu: Move sseu_dev_status to i915_drv.h

2016-08-31 Thread Imre Deak
The data in this struct is provided both by getting the slice/subslice/eu features available on a given platform and the actual runtime state of these same features which depends on the HW's current power saving state. Atm members of this struct are duplicated in sseu_dev_status and intel_device_i

[Intel-gfx] [PULL] topic/drm-misc

2016-08-31 Thread Daniel Vetter
Hi Dave, More -misc stuff - moar drm_crtc.c split up&documentation - some fixes for the simple kms helpers (Andrea) - I included all the dri1 patches from David - we're not removing any code or drivers, and it seems to have worked as a wake-up call to motivate a few more people to upstream kms

Re: [Intel-gfx] [PATCH 0/2] drm/i915/opregion: proper handling of DIDL and CADL

2016-08-31 Thread tasev.stefanoska
Le 30/08/16 à 21:28, Paolo Stivanin a écrit : Hello, nope, also after suspend nothing changed. I also tried using evtest before and after the patch and I got the same result: nothing shows up when I press FN+F8/F9 (brightness) Hello, Tested on an asus ux305FA, work only after fresh boot, not w

Re: [Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

2016-08-31 Thread James Bottomley
On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote: > We seem to have an xrandr regression with skylake now. What's > happening is that I can get output on to a projector, but the system > is losing video when I change the xrandr sessions (like going from a > --above b to a --same-as b).

Re: [Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

2016-08-31 Thread James Bottomley
On Wed, 2016-08-31 at 11:23 -0700, James Bottomley wrote: > On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote: > > We seem to have an xrandr regression with skylake now. What's > > happening is that I can get output on to a projector, but the > > system is losing video when I change the xr

Re: [Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

2016-08-31 Thread Zanoni, Paulo R
Hi Em Qua, 2016-08-31 às 14:43 -0700, James Bottomley escreveu: > On Wed, 2016-08-31 at 11:23 -0700, James Bottomley wrote: > > > > On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote: > > > > > > We seem to have an xrandr regression with skylake now.  What's > > > happening is that I can g

Re: [Intel-gfx] Skylake graphics regression: projector failure with 4.8-rc3

2016-08-31 Thread James Bottomley
On Wed, 2016-08-31 at 21:51 +, Zanoni, Paulo R wrote: > Hi > > Em Qua, 2016-08-31 às 14:43 -0700, James Bottomley escreveu: > > On Wed, 2016-08-31 at 11:23 -0700, James Bottomley wrote: > > > > > > On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote: > > > > > > > > We seem to have an x

[Intel-gfx] [PATCH v5 1/4] drm/i915: Store port enum in intel_encoder

2016-08-31 Thread Dhinakaran Pandiyan
Storing the port enum in intel_encoder makes it convenient to know the port attached to an encoder. Moving the port information up from intel_digital_port to intel_encoder avoids unecessary intel_digital_port access and handles MST encoders cleanly without requiring conditional checks for them (tha

[Intel-gfx] [PATCH v5 3/4] drm/i915: Move audio_connector to intel_encoder

2016-08-31 Thread Dhinakaran Pandiyan
With DP MST, a digital_port can carry more than one audio stream. Hence, more than one audio_connector needs to be attached to intel_digital_port in such cases. However, each stream is associated with an unique encoder. So, instead of creating an array of audio_connectors per port, move audio_conne

[Intel-gfx] [PATCH v5 4/4] drm/i915: start adding dp mst audio

2016-08-31 Thread Dhinakaran Pandiyan
From: Libin Yang (This patch is developed by Dave Airlie originally) This patch adds support for DP MST audio in i915. Enable audio codec when DP MST is enabled if has_audio flag is set. Disable audio codec when DP MST is disabled if has_audio flag is set. Another separated patches to support

[Intel-gfx] [PATCH v5 2/4] drm/i915: Switch to using port stored in intel_encoder

2016-08-31 Thread Dhinakaran Pandiyan
Now that we have the port enum stored in intel_encoder, use that instead of dereferencing intel_dig_port. Saves us a few locals. struct intel_encoder variables have been renamed to be consistent and convey type information. v2: Fix incorrect 'enum port' member names - s/attached_port/port Signed

[Intel-gfx] [PATCH v5 0/4] Prep. for DP audio MST support

2016-08-31 Thread Dhinakaran Pandiyan
This series lays the groundwork for more DP MST audio work that will follow. Rebased and fixed typos this time. v2: Different solution replacing the enc_to_dig_port() fix (Ville, Lyude). No changes to MST audio enabling and move audio_connector patches. Reordered the patches (Lyude) v3: Differen

Re: [Intel-gfx] [PATCH v5 2/4] drm/i915: Switch to using port stored in intel_encoder

2016-08-31 Thread Lyude Paul
Reviewed-by: Lyude On Wed, 2016-08-31 at 17:20 -0700, Dhinakaran Pandiyan wrote: > Now that we have the port enum stored in intel_encoder, use that instead of > dereferencing intel_dig_port. Saves us a few locals. > > struct intel_encoder variables have been renamed to be consistent and > convey