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 na
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 Kasireddy
---
tests/kms_rot
> 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 t
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
>appl
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 scaling. Also dp MST is
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
+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:
g
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
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
> >
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.
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 probab
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 cur
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) mode because the
gem_
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 beh
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 use
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 its
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
---
drive
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 activate/deactiva
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
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
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 w
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 Zano
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 documentation
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_f
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
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
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
> > ---
> > drivers/gpu/drm/i915/intel_fbc.c | 6 --
> > 1 file ch
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 g
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
> drivers/gpu/drm/i915/i9
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
On Wed, Oct 21, 2015 at 8:
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 stat
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
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,
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
---
drivers/gpu/drm/i915/i915_debugfs.c | 7 ++
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 a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu
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
---
drivers/gpu/drm/i915/i915_gpu_error.c
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 insertions(+)
diff --git a/drivers/
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.
Signed-off-by
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 files changed, 11 insertions(+)
diff --git a/drivers/
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
---
drivers/gpu/drm/i915/i915_debugfs.c | 22 ++
1 file cha
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
firm
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
--- a/drivers/gpu/drm/i915
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.
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 +
drivers/gpu/drm/i9
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 100644
--- a/drivers/gpu/d
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 no
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
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 +++--
driv
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 bandwi
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 po
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 wrot
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 reviewing the NV12 stuff it became
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
>> address. To do so effic
> -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 fo
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 - lookup
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] d
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 J
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 u
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 WARN to ensure on
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 t
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
> > ---
> > drivers/gpu/drm/i915/intel_dp.
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, ville.syrj...@linux.inte
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
> > - handle fb->offsets[] properly
>
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 hold for G4X, w
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 sk
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 va
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 fix
> intel_firmware_decode
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ä
intel_pin_and_fence_fb_obj() only needs the fra
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 needs the framebuffer, and the d
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 17:29
Hi Daniel,
[auto build test ERROR on drm-intel/for-linux-next -- if it's inappropriate
base, please suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-tegra-Use-drm_gem_object_reference_unlocked/20151021-160838
config
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 behavior, so let's just silence it.
>
> Signed-off-by: Paulo Zanoni
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
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 documentation. Also notice that there's already a
> huge gap between the commen
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 the CRTC. Let's start this by renaming the
> functions that touch the
On Wed, Oct 21, 2015 at 10:20:33AM +0200, Daniel Vetter wrote:
> Requested by Chris, and since we're no longer rebasing the -next queue
> I can't rectify history.
Hey, if I am requesting stuff, can I ask that new functions stop calling
struct intel_engine_cs *ring? :)
-Chris
--
Chris Wilson, Int
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 needs the framebuffer, and the desird
rotation (to find the right GTT view for it), so no need to pass all
kinds of plan
On Wed, Oct 21, 2015 at 03:09:55PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 21, 2015 at 12:15:42PM +0200, Daniel Vetter wrote:
> > 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
Animesh Manna writes:
> On 9/18/2015 8:47 PM, Mika Kuoppala wrote:
>> Add debugfs entry for csr/dmc fw to inspect firmware
>> loading status and version.
>>
>> Signed-off-by: Mika Kuoppala
>> ---
>> drivers/gpu/drm/i915/i915_debugfs.c | 32
>> drivers/gpu/drm/
On Wed, Oct 21, 2015 at 12:13:13PM +0100, Dave Gordon wrote:
> On 20/10/15 00:10, yu@intel.com wrote:
> >From: Alex Dai
> >
> >The size / offset information of all firmware ingredients are
> >now caculated from header. Driver will validate the header and
> >rsa key size. If any component is ou
On Wed, Oct 21, 2015 at 02:36:34PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 21, 2015 at 12:53:34PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 14, 2015 at 07:29:00PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > The page aligned surface address calculatio
On Wed, Oct 21, 2015 at 12:15:42PM +0200, Daniel Vetter wrote:
> 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().
> >
> > Al
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 reviewing the NV12 stuff it became clear to me no one
> > had really given fb->offsets[] handling any serious th
On Wed, Oct 14, 2015 at 07:29:14PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> intel_compute_page_offset() can dig up the correct pitch from the fb
> itself, no need for the caller to pass it in.
>
> A bit of extra care is needed for the lower level
> _intel_compute_pag
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
> - handle fb->offsets[] properly
> - make the rotation handling reasier for the plane code
I think this is to
On Wed, Oct 14, 2015 at 07:29:12PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> intel_compute_page_offsets() gets passed a bunch of the framebuffer
> metadate sepearately. Just pass the framebuffer itself to make life
> simpler for the caller, and make it less likely they
On Wed, Oct 14, 2015 at 07:29:11PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Don't increment obj->framebuffer_references until we know we actually
> managed to create the framebuffer.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu
On Wed, Oct 14, 2015 at 07:29:10PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We convert the fb->offsets[] into x/y offsets, so they must be
> (macro)pixel aligned.
>
> Signed-off-by: Ville Syrjälä
Patches 16-18: Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/
On Wed, Oct 21, 2015 at 01:22:43PM +0200, Daniel Vetter wrote:
> On Wed, Oct 14, 2015 at 07:29:02PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > SKL+ needs >4K alignment for tiled surfaces, so make
> > intel_compute_page_offset() handle it.
> >
> > The way we do it
On Wed, Oct 21, 2015 at 12:53:34PM +0200, Daniel Vetter wrote:
> On Wed, Oct 14, 2015 at 07:29:00PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The page aligned surface address calculation needs to know which way
> > things are rotated. The contract now says that t
On Wed, Oct 14, 2015 at 07:29:06PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> In case we have multiple different rotated views into the same object,
> each one may need its own vma due to being of different sizes. So don't
> treat all rotated views as equal.
>
> Signed
On Wed, Oct 14, 2015 at 07:29:07PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> rotate_pages() doesn't modify the passed in dma addresses, so make
> them const.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c |
Please ignore, Daniel beat me to it.
On Wed, 21 Oct 2015, Jani Nikula wrote:
> dim.rst:116: (WARNING/2) Title underline too short.
>
> Signed-off-by: Jani Nikula
> ---
> dim.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dim.rst b/dim.rst
> index 91308f420338..ebb
On Wed, 21 Oct 2015, Daniel Vetter wrote:
> I forgotten to lenghten the underlining appropriately. Reported by
> Thomas Wood.
Ack, please ignore the patch I sent before checking the rest of my email
first.
Jani.
>
> Signed-off-by: Daniel Vetter
> ---
> dim.rst | 2 +-
> 1 file changed, 1 ins
On Wed, Oct 21, 2015 at 01:22:43PM +0200, Daniel Vetter wrote:
> On Wed, Oct 14, 2015 at 07:29:02PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > SKL+ needs >4K alignment for tiled surfaces, so make
> > intel_compute_page_offset() handle it.
> >
> > The way we do it
dim.rst:116: (WARNING/2) Title underline too short.
Signed-off-by: Jani Nikula
---
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
+++ b/dim.rst
@@ -113,7 +113,7 @@ branch, assuming that patches g
On Wed, Oct 14, 2015 at 07:29:05PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Each gtt view only has a single type, and so don't need to contain data
> for both rotated and partial views. So we can move the data into the
> same union to avoid wasting space.
>
> Also re
On Thu, Oct 15, 2015 at 02:01:38PM +0200, Daniel Vetter wrote:
> On Thu, Oct 15, 2015 at 12:15:21PM +0100, Tvrtko Ursulin wrote:
> >
> > Hi,
> >
> > On 14/10/15 17:29, ville.syrj...@linux.intel.com wrote:
> > >From: Ville Syrjälä
> > >
> > >Just for clarity set the type for i915_ggtt_view_normal
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 needs the framebuffer, and the desird
> rotation (to find the right GTT view for it), so no need to pass all
> kinds of plane stuff.
>
> Signed-off-by: Ville
On Wed, Oct 14, 2015 at 07:29:02PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> SKL+ needs >4K alignment for tiled surfaces, so make
> intel_compute_page_offset() handle it.
>
> The way we do it is first we compute the closest tile boundary
> as before, and then figure o
1 - 100 of 144 matches
Mail list logo
