[Intel-gfx] [PATCH] drm/i915: Always program CSR if CSR is uninitialized

The current CSR loading code depends on the CSR program memory to be cleared after boot. This is unfortunately not true on all hardware. Instead make use of the FW_UNINITIALIZED state in init and check for FW_LOADED to prevent init path from skipping the actual programming. Signed-off-by: Patrik

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Avoid EBUSY retry on intel_dp_aux_ch.

On Wed, 2015-10-21 at 12:19 +0300, Ville Syrjälä wrote: > On Wed, Oct 21, 2015 at 10:28:51AM -0700, Rodrigo Vivi wrote: > > EBUSY retries are already in place at drm level. > > We don't need to replicate the job here. > > > > Signed-off-by: Rodrigo Vivi > > --- > >

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Kill intel_dp_dpcd_read_wake

On Wed, 2015-10-21 at 12:23 +0300, Ville Syrjälä wrote: > On Wed, Oct 21, 2015 at 10:28:54AM -0700, Rodrigo Vivi wrote: > > We have an inconsistency on our code on using > > intel_dp_dpcd_read_wake with > > retries and when using drm_dp_dpcd_read helper without retry. > > > > Must probably with

Re: [Intel-gfx] [PATCH 1/3] drm: Track drm_mm nodes with an interval tree

On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote: > In addition to the last-in/first-out stack for accessing drm_mm nodes, > we occasionally and in the future often want to find a drm_mm_node by an > address. To do so efficiently we need to track the nodes in an interval > tree -

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Add soft-pinning API for execbuffer

> -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter > Sent: Wednesday, October 21, 2015 4:08 PM > To: Daniel, Thomas > Cc: Chris Wilson; intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 3/3] drm/i915: Add soft-pinning API

Re: [Intel-gfx] [PATCH 11/22] drm/i915: Don't pass plane+plane_state to intel_pin_and_fence_fb_obj()

On Wed, Oct 21, 2015 at 05:22:40PM +0300, Ville Syrjälä wrote: > On Wed, Oct 21, 2015 at 02:22:10PM +0100, Tvrtko Ursulin wrote: > > > > On 21/10/15 14:09, Ville Syrjälä wrote: > > > On Wed, Oct 21, 2015 at 01:17:10PM +0100, Tvrtko Ursulin wrote: > > >> > > >> On 21/10/15 12:28, Daniel Vetter

[Intel-gfx] [PATCH] drm/915: Pad GTT views of exec objects up to user specified size

Our GPUs impose certain requirements upon buffers that depend upon how exactly they are used. Typically this is expressed as that they require a larger surface than would be naively computed by pitch * height. Normally such requirements are hidden away in the userspace driver, but when we accept

Re: [Intel-gfx] [PATCH] drm/i915: add hotplug activation period to hotplug update mask

On Wed, Oct 21, 2015 at 05:22:43PM +0300, Jani Nikula wrote: > commit 0706f17c307b056ff6f1848320ba82d76945a6ff > Author: Egbert Eich > Date: Wed Sep 23 16:15:27 2015 +0200 > > drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt, v2 > > added a check with

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Kill intel_dp_dpcd_read_wake

On Wed, Oct 21, 2015 at 02:31:33PM +, Vivi, Rodrigo wrote: > On Wed, 2015-10-21 at 12:23 +0300, Ville Syrjälä wrote: > > On Wed, Oct 21, 2015 at 10:28:54AM -0700, Rodrigo Vivi wrote: > > > We have an inconsistency on our code on using > > > intel_dp_dpcd_read_wake with > > > retries and when

Re: [Intel-gfx] [PATCH 1/3] drm: Track drm_mm nodes with an interval tree

Hi On Wed, Oct 21, 2015 at 5:11 PM, Daniel Vetter wrote: > On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote: >> In addition to the last-in/first-out stack for accessing drm_mm nodes, >> we occasionally and in the future often want to find a drm_mm_node by an >>

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Store and print dmc firmware version

Damien Lespiau writes: > On Thu, Oct 08, 2015 at 12:03:30PM +0100, Damien Lespiau wrote: >> The DMC firmware version decoding was different in my patch and I'm sure >> it worked then. Maye the header has changed :( > > By the way, if this is indeed the case, could you

Re: [Intel-gfx] [PATCH v2 21/22] drm/i915: Rewrite fb rotation GTT handling

On Wed, Oct 21, 2015 at 02:01:01PM +0200, Daniel Vetter wrote: > On Thu, Oct 15, 2015 at 08:59:45PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Redo the fb rotation handling in order to: > > - eliminate the NV12 special casing > > -

Re: [Intel-gfx] [PATCH 00/22] drm/i915: Handle fb->offsets[] and rewrite fb rotation handling to be more generic

On Wed, Oct 21, 2015 at 02:09:00PM +0200, Daniel Vetter wrote: > On Wed, Oct 14, 2015 at 06:59:38PM +0200, Daniel Vetter wrote: > > On Wed, Oct 14, 2015 at 07:28:52PM +0300, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > > So while

Re: [Intel-gfx] [PATCH v2] drm/i915: Don't pass *DP around to link training functions

On 10/21/2015 7:22 PM, Ander Conselvan de Oliveira wrote: It just makes the code more confusing, so just reference intel_dp->DP directly. Note that this also fix a bug where the value of intel_dp->DP could be different than the last value written to the hw, due to an early return that would

Re: [Intel-gfx] [PATCH 11/22] drm/i915: Don't pass plane+plane_state to intel_pin_and_fence_fb_obj()

On Wed, Oct 21, 2015 at 02:22:10PM +0100, Tvrtko Ursulin wrote: > > On 21/10/15 14:09, Ville Syrjälä wrote: > > On Wed, Oct 21, 2015 at 01:17:10PM +0100, Tvrtko Ursulin wrote: > >> > >> On 21/10/15 12:28, Daniel Vetter wrote: > >>> On Wed, Oct 14, 2015 at 07:29:03PM +0300,

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Add soft-pinning API for execbuffer

On Tue, Oct 06, 2015 at 01:59:12PM +, Daniel, Thomas wrote: > > -Original Message- > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > > Sent: Tuesday, October 6, 2015 11:53 AM > > To: intel-gfx@lists.freedesktop.org > > Cc: Chris Wilson; Daniel, Thomas > > Subject: [PATCH 3/3]

[Intel-gfx] [PATCH 1/2] drm/i915/skl+: Enable gamma and CSC on bottom color. (v2)

To stay consisent with how we're programming all the other planes, enable gamma and CSC on the bottom color. Without this, we fail the the kms_universal_plane functional tests because the black primary plane is brighter (gamma corrected) than the disabled plane case. If the bottom color is also

[Intel-gfx] [PATCH 1/7] drm/i915/skl: Print the DMC firmware status in debugfs

From: Damien Lespiau Create a new debufs file for it, we'll have a few more things to add there. v2: Fix checkpatch warning about static const array Signed-off-by: Damien Lespiau (v1) Signed-off-by: Mika Kuoppala

[Intel-gfx] [PATCH 2/7] drm/i915/skl: Store and print the DMC firmware version we load

From: Damien Lespiau That can be handy later on to tell which DMC firmware version the user has, by just looking at the dmesg or a debugfs file. v2: use DRM_DEBUG_DRIVER (Chris) Signed-off-by: Damien Lespiau (v1) Signed-off-by: Mika Kuoppala

[Intel-gfx] [PATCH 5/7] drm/i915/bxt: Expose DC5 entry count

For bxt CSR firmware exposes a count of dc5 entries. Expose it through debugs Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_debugfs.c | 3 +++ drivers/gpu/drm/i915/i915_reg.h | 1 + 2 files changed, 4 insertions(+) diff --git

[Intel-gfx] [PATCH 6/7] drm/i915: Add dmc firmware load state and version to error state

We have had one case where buggy csr/dmc firmware version influenced gt side and caused a hang. Add dmc firmware loading state and version to error state. v2: - Rebased on top of Damien's patches - included fw load state Signed-off-by: Mika Kuoppala ---

[Intel-gfx] [PATCH 7/7] drm/i915: Add csr programming registers to dmc debugfs entry

We check these to determine firmware loading status. Include them to help to debug causes of firmware loading fails. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_debugfs.c | 4 drivers/gpu/drm/i915/i915_reg.h | 3 +++ 2 files changed, 7

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

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.

[Intel-gfx] [PATCH 3/7] drm/i915/skl: Refuse to load outdated dmc firmware

There is known issue on GT interrupt delivery with DC6 and firmwares <1.21. There is a suspicion that this causes spurious gpu hangs on driver init and with some workloads, as upgrading the firmware to 1.21 makes these problems disappear. As of now the current version included in distribution

[Intel-gfx] [PATCH 4/7] drm/i915/skl: Expose DC5/DC6 entry counts

From: Damien Lespiau The CSR firmware expose two counters, handy to check if we are indeed entering DC5/DC6. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/i915_debugfs.c | 7 +++ drivers/gpu/drm/i915/i915_reg.h | 4 2

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

Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_debugfs.c | 4 drivers/gpu/drm/i915/i915_dma.c | 2 ++ 2 files changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 3fb83ea..24504a3 100644 ---

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

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 0/7] drm/i915: read out slice/subslice masks

The per-slice/subslice INSTDONE patchset from Ben [1] will need the subslice/slice masks in addition to the corresponding counts that we maintain atm. So I added support to store the masks instead of the counts and calculate the counts whenever we need them based on the masks. While at it I also

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Add dmc firmware load state and version to error state

On Wed, Oct 21, 2015 at 06:41:51PM +0300, Mika Kuoppala wrote: > We have had one case where buggy csr/dmc firmware version influenced > gt side and caused a hang. Add dmc firmware loading state and > version to error state. > > v2: - Rebased on top of Damien's patches > - included fw load

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Add csr programming registers to dmc debugfs entry

On Wed, Oct 21, 2015 at 06:41:52PM +0300, Mika Kuoppala wrote: > We check these to determine firmware loading status. Include > them to help to debug causes of firmware loading fails. > > Signed-off-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_debugfs.c | 4

Re: [Intel-gfx] [RFCv2 DP-typeC 5/6] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

On Wed, 2015-10-14 at 17:30 +0530, Durgadoss R wrote: > To support USB type C alternate DP mode, the display driver needs to > know the number of lanes required by the DP panel as well as number > of lanes that can be supported by the type-C cable. Sometimes, the > type-C cable may limit the

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

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-gfx] [PATCH 2/7] drm/i915: sseu: use sseu_dev_info in device info

Move all slice/subslice/eu related properties to the sseu_dev_info struct. No functional change. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_debugfs.c | 25 drivers/gpu/drm/i915/i915_dma.c | 34

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

Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_debugfs.c | 55 +++-- 1 file changed, 29 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index de188d0..183c1f2

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

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. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_debugfs.c | 14 +++--- drivers/gpu/drm/i915/i915_dma.c | 37

Re: [Intel-gfx] [PATCH 11/22] drm/i915: Don't pass plane+plane_state to intel_pin_and_fence_fb_obj()

On Wed, Oct 21, 2015 at 05:20:02PM +0200, Daniel Vetter wrote: > On Wed, Oct 21, 2015 at 05:22:40PM +0300, Ville Syrjälä wrote: > > On Wed, Oct 21, 2015 at 02:22:10PM +0100, Tvrtko Ursulin wrote: > > > > > > On 21/10/15 14:09, Ville Syrjälä wrote: > > > > On Wed, Oct 21, 2015 at 01:17:10PM +0100,

Re: [Intel-gfx] [PATCH 4/7] drm/i915/skl: Expose DC5/DC6 entry counts

Do you know how to calculate a residency with these counters? To be able to expose that through sysfs to powertop. Otherwise I believe we should also expose the counters itself to powertop that would be useful already. Anyway, for this patch: Reviewed-by: Rodrigo Vivi

Re: [Intel-gfx] [PATCH 3/7] drm/i915/skl: Refuse to load outdated dmc firmware

On Wed, Oct 21, 2015 at 06:41:48PM +0300, Mika Kuoppala wrote: > There is known issue on GT interrupt delivery with DC6 and > firmwares <1.21. There is a suspicion that this causes > spurious gpu hangs on driver init and with some workloads, > as upgrading the firmware to 1.21 makes these problems

[Intel-gfx] [PATCH v2] drm/i915: Don't pass *DP around to link training functions

It just makes the code more confusing, so just reference intel_dp->DP directly. Note that this also fix a bug where the value of intel_dp->DP could be different than the last value written to the hw, due to an early return that would skip the 'intel_dp->DP = DP' line. v2: Don't preserve old DP

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 +, 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: > > > > There's no need to stop

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Fix random aux transactions failures.

On 10/21/2015 12:53 PM, Daniel Vetter wrote: On Wed, Oct 21, 2015 at 09:18:06AM +0200, Daniel Vetter wrote: On Wed, Oct 21, 2015 at 10:28:53AM -0700, Rodrigo Vivi wrote: Mainly aux communications on sink_crc were failing a lot randomly on recent platforms. The first solution was to try to

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

On 8/25/2015 2:50 AM, Vivi, Rodrigo wrote: On Mon, 2015-08-24 at 19:54 +, Zanoni, Paulo R wrote: 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

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 07/18] drm/i915: fix the __intel_fbc_update() comments

On Wed, Oct 21, 2015 at 05:32:16PM +, 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: > > > Don't try to list in comments the cases where we should enable or > > > disable FBC: it varies a lot

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Avoid EBUSY retry on intel_dp_aux_ch.

On 10/21/2015 7:54 PM, Vivi, Rodrigo wrote: On Wed, 2015-10-21 at 12:19 +0300, Ville Syrjälä wrote: On Wed, Oct 21, 2015 at 10:28:51AM -0700, Rodrigo Vivi wrote: EBUSY retries are already in place at drm level. We don't need to replicate the job here. Signed-off-by: Rodrigo Vivi

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 04/18] drm/i915: extract crtc_is_valid() on the FBC code

On Wed, Oct 21, 2015 at 05:16:04PM +, Zanoni, Paulo R wrote: > 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-gfx] [PATCH] drm/i915/guc: Fix a false alert of memory leak when free LRC

From: Alex Dai There is a memory leak warning message from i915_gem_context_clean when GuC submission is enabled. The reason is that gem_request (so the LRC associated with it) is freed early than moving the vma list to inactive. We are not seeing this in ExecList (non-GuC)

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

On Wed, Oct 21, 2015 at 05:45:33PM +, Zanoni, Paulo R wrote: > 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

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 3/4] drm/i915: Fix random aux transactions failures.

On Wed, 2015-10-21 at 23:47 +0530, Thulasimani, Sivakumar wrote: > > On 10/21/2015 12:53 PM, Daniel Vetter wrote: > > On Wed, Oct 21, 2015 at 09:18:06AM +0200, Daniel Vetter wrote: > > > On Wed, Oct 21, 2015 at 10:28:53AM -0700, Rodrigo Vivi wrote: > > > > Mainly aux communications on sink_crc >

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

On Thu, 2015-10-22 at 00:01 +0530, Thulasimani, Sivakumar wrote: > > On 8/25/2015 2:50 AM, Vivi, Rodrigo wrote: > > On Mon, 2015-08-24 at 19:54 +, Zanoni, Paulo R wrote: > > > Em Qui, 2015-08-20 às 16:23 -0700, Rodrigo Vivi escreveu: > > > > Let's use a native read with retry as suggested per

Re: [Intel-gfx] linux-firmware-i915 pull request (skl dmc 1.23)

+intel-gfx@lists.freedesktop.org Hi, Please consider pulling i915 updates to linux-firmware.git: The following changes since commit 7dae4d9df09ae9cdf57d912ebda39836f482d059: linux-firmware/i915: Removing old Skylake DMC (2015-10-20 10:32:26 -0700) are available in the git repository at:

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

On Thu, Oct 22, 2015 at 12:01:21AM +0530, Thulasimani, Sivakumar wrote: > > > On 8/25/2015 2:50 AM, Vivi, Rodrigo wrote: > >On Mon, 2015-08-24 at 19:54 +, Zanoni, Paulo R wrote: > >>Em Qui, 2015-08-20 às 16:23 -0700, Rodrigo Vivi escreveu: > >>>Let's use a native read with retry as suggested

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Avoid EBUSY retry on intel_dp_aux_ch.

On Wed, 2015-10-21 at 23:31 +0530, Thulasimani, Sivakumar wrote: > > On 10/21/2015 7:54 PM, Vivi, Rodrigo wrote: > > On Wed, 2015-10-21 at 12:19 +0300, Ville Syrjälä wrote: > > > On Wed, Oct 21, 2015 at 10:28:51AM -0700, Rodrigo Vivi wrote: > > > > EBUSY retries are already in place at drm level.

Re: [Intel-gfx] [PATCH v7 11/25] drm/i915: Register color correction capabilities

On Tue, 2015-10-20 at 18:04 +0530, Shashank Sharma wrote: > From DRM color management: > > DRM color manager supports these color properties: > 1. "ctm": Color transformation matrix property, where a >color transformation matrix of 9 correction values gets >

Re: [Intel-gfx] 4.3-rc6 on i7 6700 = no graphics.

On 2015-10-21 11:29, Jani Nikula wrote: On Wed, 21 Oct 2015, Kenneth Johansson wrote: So I have a i76700 system that I'm trying to use the integrated graphics with. It sort of works with kernel 4.2 but vlc have some issue with the video overlay, its always on top and no

[Intel-gfx] [PATCH] igt/kms_rotation_crc: Add a subtest to validate Y-tiled obj + Y fb modifier (v2)

The main goal of this subtest is to verify whether flipping a framebuffer with a Y fb modifier (90/270 degree rotation) and with an associated Y-tiled object works or not. v2: Do not call paint_squares and just use one output. Cc: Tvrtko Ursulin Signed-off-by: Vivek

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 03/18] drm/i915: only nuke FBC when a drawing operation triggers a flush

On Wed, Oct 21, 2015 at 05:08:42PM +, 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: > > > There's no need to stop and restart FBC: a nuke should be fine. > > > > > > Signed-off-by: Paulo

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 05/18] drm/i915: set dev_priv->fbc.crtc before scheduling the enable work

On Wed, Oct 21, 2015 at 05:27:32PM +, Zanoni, Paulo R wrote: > 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

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Notify user about outdated dmc firmware

> On machines that had 1.19 symlinked, in filesystem, execlist submission > sometimes broke due to interrupt delivery problem. To reach a conclusion > that it was csr firmware, before 1.21 was out, took quite amount of work. > > I bet there are still machines with 1.19 only, and we get to > wade

[Intel-gfx] [PATCH] drm/i915: add hotplug activation period to hotplug update mask

commit 0706f17c307b056ff6f1848320ba82d76945a6ff Author: Egbert Eich Date: Wed Sep 23 16:15:27 2015 +0200 drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt, v2 added a check with WARN to ensure only bits within the mask are enabled. Turns out that doesn't

Re: [Intel-gfx] [PATCH 11/18] drm/i915: refactor FBC deactivation at init

On Tue, Oct 20, 2015 at 11:49:57AM -0200, Paulo Zanoni wrote: > Make sure we deactivate FBC at intel_fbc_init(), so we can remove the > call from intel_display.c. Though you should keep the comment as to why we want to sanitize incoming register state as a reminder. Does this function document it

Re: [Intel-gfx] [PATCH 14/22] drm/i915: Don't treat differently sized rotated views as equal

On Thu, Oct 15, 2015 at 02:24:51PM +0200, Daniel Vetter wrote: > On Thu, Oct 15, 2015 at 03:06:11PM +0300, Ville Syrjälä wrote: > > On Thu, Oct 15, 2015 at 02:02:24PM +0200, Daniel Vetter wrote: > > > On Thu, Oct 15, 2015 at 12:18:41PM +0100, Tvrtko Ursulin wrote: > > > > > > > > On 14/10/15

Re: [Intel-gfx] [PATCH 11/22] drm/i915: Don't pass plane+plane_state to intel_pin_and_fence_fb_obj()

On Wed, Oct 21, 2015 at 01:17:10PM +0100, Tvrtko Ursulin wrote: > > On 21/10/15 12:28, Daniel Vetter wrote: > > On Wed, Oct 14, 2015 at 07:29:03PM +0300, ville.syrj...@linux.intel.com > > wrote: > >> From: Ville Syrjälä > >> > >> intel_pin_and_fence_fb_obj() only

Re: [Intel-gfx] [PATCH 11/22] drm/i915: Don't pass plane+plane_state to intel_pin_and_fence_fb_obj()

On 21/10/15 14:09, Ville Syrjälä wrote: On Wed, Oct 21, 2015 at 01:17:10PM +0100, Tvrtko Ursulin wrote: On 21/10/15 12:28, Daniel Vetter wrote: On Wed, Oct 14, 2015 at 07:29:03PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä

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

On 10/22/2015 1:44 AM, Damien Lespiau wrote: On Thu, Oct 22, 2015 at 12:01:21AM +0530, Thulasimani, Sivakumar wrote: On 8/25/2015 2:50 AM, Vivi, Rodrigo wrote: On Mon, 2015-08-24 at 19:54 +, Zanoni, Paulo R wrote: Em Qui, 2015-08-20 às 16:23 -0700, Rodrigo Vivi escreveu: Let's use a

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/bxt: add revision id for A1 stepping and use it

On Tue, Oct 20, 2015 at 03:22:01PM +0300, Jani Nikula wrote: > Prefer inclusive ranges for revision checks rather than "below B0". Per > specs A2 is not used, so revid <= A1 matches revid < B0. > > Acked-by: Ville Syrjälä > Signed-off-by: Jani Nikula

Re: [Intel-gfx] [PATCH] drm/i915/skl+: Enable gamma and CSC on bottom color.

On Tue, Oct 20, 2015 at 11:16:20AM -0700, Matt Roper wrote: > On Tue, Oct 20, 2015 at 09:04:56AM -0700, Bob Paauwe wrote: > > To stay consisent with how we're programming all the other planes, > > enable gamma and CSC on the bottom color. Without this, we fail the > > the kms_universal_plane

Re: [Intel-gfx] [PATCH v3] drm/i915/skl: Assume no scaling is available when things are not as expected

On Tue, Oct 20, 2015 at 05:17:07PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Cdclk < crtc_clock is not allowed and suggests a different problem > elsewhere in the code. > > It is more robust and safe to assume no scaling is possible in > this case with no

Re: [Intel-gfx] [PATCH 3/3] drm/i915: refactor stepping info retrieval

On Tue, Oct 20, 2015 at 03:38:33PM +0300, Jani Nikula wrote: > Have only one if ladder for platforms and only one range check for > size. Makes it easier to handle new platforms. Remove the use of > negative return values in char, which might underflow to be positive for > some negative error

Re: [Intel-gfx] [PATCH v3] drm/i915/skl: Consider plane rotation when calculating stride in skl_do_mmio_flip

On Tue, Oct 20, 2015 at 04:20:21PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Previously rotation was ignored and wrong stride programmed > into the plane registers resulting in a corrupt image on screen. > > v2: Do not access potentialy old plane state at

Re: [Intel-gfx] [PATCH 01/18] drm/i915: change no_fbc_reason from enum to string

On Tue, Oct 20, 2015 at 11:49:47AM -0200, Paulo Zanoni wrote: > I wanted to add yet another check to intel_fbc_update() and realized > I would need to create yet another enum no_fbc_reason case. So I > remembered this patch series that Damien wrote a long time ago and > nobody ever reviewed, so I

Re: [Intel-gfx] [PATCH v3 38/43] drm/i915: Parametrize AUX registers

On Tue, 20 Oct 2015, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > v2: Keep some MISSING_CASE() stuff (Jani) > s/-1/-PIPE_B/ in the register macro > Fix typo in patch subject > v3: Use PORT_B registers for invalid ports in g4x_aux_ctl_reg()

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

On Tue, Oct 20, 2015 at 11:49:48AM -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. > > One of the important things to notice is that on the pre-gen6 >

Re: [Intel-gfx] [PATCH v2 39/43] drm/i915: Add dev_priv->psr_mmio_base

On Tue, 20 Oct 2015, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Drop the EDP_PSR_BASE() thing, and just stick the PSR register offset > under dev_priv, like we for DSI and GPIO for example. > > TODO: could probably move a bunch of this kind of

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

On Tue, Oct 20, 2015 at 11:50:01AM -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 disbale FBC the hardware may still use the CFB > for the rest of the

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

On Wed, Oct 21, 2015 at 09:04:39AM +0200, Daniel Vetter wrote: > On Tue, Oct 20, 2015 at 11:49:48AM -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 3/4] drm/i915: Fix random aux transactions failures.

On Wed, Oct 21, 2015 at 10:28:53AM -0700, Rodrigo Vivi wrote: > Mainly aux communications on sink_crc > were failing a lot randomly on recent platforms. > The first solution was to try to use intel_dp_dpcd_read_wake, but then > it was suggested to move retries to drm level. > > Since drm level

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

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

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Fix random aux transactions failures.

On Wed, Oct 21, 2015 at 09:18:06AM +0200, Daniel Vetter wrote: > On Wed, Oct 21, 2015 at 10:28:53AM -0700, Rodrigo Vivi wrote: > > Mainly aux communications on sink_crc > > were failing a lot randomly on recent platforms. > > The first solution was to try to use intel_dp_dpcd_read_wake, but then >

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

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 current code is that it frees the CFB and > > > releases its drm_mm

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Kill intel_dp_dpcd_read_wake

On Wed, Oct 21, 2015 at 10:28:54AM -0700, Rodrigo Vivi wrote: > We have an inconsistency on our code on using intel_dp_dpcd_read_wake with > retries and when using drm_dp_dpcd_read helper without retry. > > Must probably with the case were aux message size 0 wasn't being > properly handled. > >

Re: [Intel-gfx] [PATCH 03/22] drm/i915: Factor out intel_tile_width()

On Wed, Oct 14, 2015 at 07:28:55PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Pull the tile width calculations from intel_fb_stride_alignment() into a > new function intel_tile_width(). > > Also take the opportunity to pass aroun

Re: [Intel-gfx] [PATCH 06/22] drm/i915: Use intel_tile_{size, width, height}() in intel_gen4_compute_page_offset()

On Wed, Oct 14, 2015 at 07:28:58PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Make intel_gen4_compute_page_offset() ready for other tiling formats > besied X-tile by getting the tile dimensions through > intel_tile_{size,width,height}().

[Intel-gfx] [PATCH] dim.rst: Fix warning

I forgotten to lenghten the underlining appropriately. Reported by Thomas Wood. Signed-off-by: Daniel Vetter --- dim.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dim.rst b/dim.rst index 91308f420338..ebbc04bc3604 100644 --- a/dim.rst +++

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Avoid EBUSY retry on intel_dp_aux_ch.

On Wed, Oct 21, 2015 at 10:28:51AM -0700, Rodrigo Vivi wrote: > EBUSY retries are already in place at drm level. > We don't need to replicate the job here. > > Signed-off-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_dp.c | 20 ++-- > 1 file

[Intel-gfx] [PATCH v99 1/4] drm/i915: Map the ringbuffer using WB on LLC machines

If we have llc coherency, we can write directly into the ringbuffer using ordinary cached writes rather than forcing WC access. v2: An important consequence is that we can forgo the mappable request for WB ringbuffers, allowing for many more simultaneous contexts. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH v99 4/4] drm/i915: Treat ringbuffer writes as write to normal memory

Ringbuffers are now being written to either through LLC or WC paths, so treating them as simply iomem is no longer adequate. However, for the older !llc hardware, the hardware is documentated as treating the TAIL register update as serialising, so we can relax the barriers when filling the rings

Re: [Intel-gfx] [PATCH 02/22] drm/i915: Pass modifier instead of tiling_mode to gen4_compute_page_offset()

On Wed, Oct 14, 2015 at 07:28:54PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > In preparation for handling more than X tiling, pass the fb modifier to > gen4_compute_page_offset() instead of the obj->tiling_mode. > > Signed-off-by: Ville

Re: [Intel-gfx] [PATCH v99 2/4] drm/i915: Refactor duplicate object vmap functions

On Wed, Oct 21, 2015 at 11:44:02AM +0200, Daniel Vetter wrote: > On Wed, Oct 21, 2015 at 10:21:19AM +0100, Chris Wilson wrote: > > We now have two implementations for vmapping a whole object, one for > > dma-buf and one for the ringbuffer. If we couple the vmapping into the > > obj->pages

[Intel-gfx] [PATCH v99 3/4] drm,i915: Introduce drm_malloc_gfp()

I have instances where I want to use drm_malloc_ab() but with a custom gfp mask. And with those, where I want a temporary allocation, I want to try a high-order kmalloc() before using a vmalloc(). So refactor my usage into drm_malloc_gfp(). Signed-off-by: Chris Wilson

Re: [Intel-gfx] 4.3-rc6 on i7 6700 = no graphics.

On Wed, 21 Oct 2015, Kenneth Johansson wrote: > So I have a i76700 system that I'm trying to use the integrated graphics > with. > > It sort of works with kernel 4.2 but vlc have some issue with the video > overlay, its always on top and no scaling. Also dp MST is not working at

Re: [Intel-gfx] [RFC PATCH] drm/i915: Consider SPLL as another shared pll.

On Wed, Sep 16, 2015 at 09:23:59AM +0200, Maarten Lankhorst wrote: > When diagnosing a unrelated bug for someone on irc, it would seem the > hardware can > be brought up by the BIOS with the embedded displayport using the SPLL for > spread spectrum. > > Right now this is not handled well in

Re: [Intel-gfx] [PATCH v99 2/4] drm/i915: Refactor duplicate object vmap functions

On Wed, Oct 21, 2015 at 10:21:19AM +0100, Chris Wilson wrote: > We now have two implementations for vmapping a whole object, one for > dma-buf and one for the ringbuffer. If we couple the vmapping into the > obj->pages lifetime, then we can reuse an obj->vmapping for both and at > the same time

Re: [Intel-gfx] [PATCH 04/22] drm/i915: Redo intel_tile_height() as intel_tile_size() / intel_tile_width()

On Wed, Oct 14, 2015 at 07:28:56PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > I find more usual to think about tile widths than heights, so changing > the intel_tile_height() to calculate the tile height as > tile_size/tile_width is

  1   2   >