From: Damien Lespiau damien.lesp...@intel.com
In the future, we'll need the height of the fb to fetch from memory for
WM computation.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/intel_drv.h| 5 -
On Tue, Jul 15, 2014 at 09:17:41AM +0200, Daniel Vetter wrote:
From: Damien Lespiau damien.lesp...@intel.com
No need to list all the platforms explicitly.
The prefix is a bit inconsistent since we usually pick gen8_ for GT
related functions. But this anti-pattern is already established
On Mon, Jul 14, 2014 at 12:10:47PM -0700, Todd Previte wrote:
The Displayport Link Layer Compliance Testing Specification 1.2 rev 1.1
specifies that
repeated AUX transactions after a failure (NACK, DEFER or no response) must
have
a minimum delay of 400us before the resend can occur. Tests
On Fri, Jul 11, 2014 at 03:06:55PM +0100, Tvrtko Ursulin wrote:
On 07/11/2014 03:02 PM, Daniel Vetter wrote:
On Fri, Jul 11, 2014 at 12:06:02PM +0100, Chris Wilson wrote:
On Fri, Jul 11, 2014 at 12:00:26PM +0100, Tvrtko Ursulin wrote:
On 07/11/2014 11:28 AM, Chris Wilson wrote:
During the
On Tue, Jul 15, 2014 at 08:26:04AM +0100, Damien Lespiau wrote:
On Tue, Jul 15, 2014 at 09:17:41AM +0200, Daniel Vetter wrote:
From: Damien Lespiau damien.lesp...@intel.com
No need to list all the platforms explicitly.
The prefix is a bit inconsistent since we usually pick gen8_ for
People use it way too often, and it upsets the test library. The only
valid places to use this is of igt infrastructure self-tests where you
need to check something _without_ all the other abi use checks
igt_fail and friends do. For those tests just #define an internal
assert to hide it.
- Drop return values for test functions - we rely on the implicit
control flow from igt_ checks.
- Don't use assert directly, this upsets the test flow logic (and
results in a CRASH result instead of FAIL).
Cc: Tvrtko Ursulin tvrtko.ursu...@intel.com
Signed-off-by: Daniel Vetter
From: Sonika Jindal sonika.jin...@intel.com
This patchset provides support for 0/180 degree hardare rotaion for primary and
sprite planes. The rotation property is now made global and is part of
drm_mode_config. It is attached to different planes.
Sonika Jindal (3):
drm: Add rotation_property
From: Ville Syrjälä ville.syrj...@linux.intel.com
The sprite planes (in fact all display planes starting from gen4)
support 180 degree rotation. Add the relevant low level bits to the
sprite code to make use of that feature.
The upper layers are not yet plugged in.
v2: HSW handles the rotated
From: Sonika Jindal sonika.jin...@intel.com
Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.
v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.
v3: Checking if CRTC
From: Ville Syrjälä ville.syrj...@linux.intel.com
Propagate the error from intel_update_plane() up through
intel_plane_restore() to the caller. This will be used for
rollback purposes when setting properties fails.
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
From: Sonika Jindal sonika.jin...@intel.com
Reset rotation property to 0 wherever applicable
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
drivers/gpu/drm/drm_fb_helper.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c
From: Sonika Jindal sonika.jin...@intel.com
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
include/drm/drm_crtc.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index ce6df4a..5545dd3 100644
--- a/include/drm/drm_crtc.h
+++
From: Ville Syrjälä ville.syrj...@linux.intel.com
Sprite planes support 180 degree rotation. The lower layers are now in
place, so hook in the standard rotation property to expose the feature
to the users.
v2: Moving rotation_property to mode_config
Cc: dri-de...@lists.freedesktop.org
On Tue, Jul 15, 2014 at 02:10:28PM +0530, sonika.jin...@intel.com wrote:
From: Sonika Jindal sonika.jin...@intel.com
Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.
v2: Calculating linear/tiled offsets based on pipe source width and
height.
On 7/15/2014 2:41 PM, Daniel Vetter wrote:
On Tue, Jul 15, 2014 at 02:10:28PM +0530, sonika.jin...@intel.com wrote:
From: Sonika Jindal sonika.jin...@intel.com
Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.
v2: Calculating linear/tiled offsets
On Tue, Jul 15, 2014 at 03:08:37PM +0530, Jindal, Sonika wrote:
On 7/15/2014 2:41 PM, Daniel Vetter wrote:
On Tue, Jul 15, 2014 at 02:10:28PM +0530, sonika.jin...@intel.com wrote:
From: Sonika Jindal sonika.jin...@intel.com
Ok, I will add
Also Chris mentioned that on some platforms this won't
Adding mailing lists, since I don't know.
-Daniel
On Mon, Jul 14, 2014 at 9:16 PM, Vladislav Guberinic
neosis...@gmail.com wrote:
Hi Daniel,
I've seen you contributing to i915 driver and writting docs about it,
so I thought you might be able to help me.
I'm trying to use VGA output of my
On Tue, Jul 15, 2014 at 02:10:23PM +0530, sonika.jin...@intel.com wrote:
From: Sonika Jindal sonika.jin...@intel.com
This patchset provides support for 0/180 degree hardare rotaion for primary
and
sprite planes. The rotation property is now made global and is part of
drm_mode_config. It is
On 7/15/2014 4:22 PM, Damien Lespiau wrote:
On Tue, Jul 15, 2014 at 02:10:23PM +0530, sonika.jin...@intel.com wrote:
From: Sonika Jindal sonika.jin...@intel.com
This patchset provides support for 0/180 degree hardare rotaion for primary and
sprite planes. The rotation property is now made
On Tue, Jul 15, 2014 at 04:25:57PM +0530, Jindal, Sonika wrote:
Since this was a new patch set without the previous patches I
thought it is not needed. Sure I will keep this in mind for the next
time.
Ah yes, fair enough, my bad.
--
Damien
___
From: Sonika Jindal sonika.jin...@intel.com
Incorporating comments from Daniel regarding movement of creation of
rotation_property to drm_mode_create_standard_plane_properties and other minor
things.
Sonika Jindal (3):
drm: Add rotation_property to mode_config and creating it
drm/i915: Add
From: Ville Syrjälä ville.syrj...@linux.intel.com
Sprite planes support 180 degree rotation. The lower layers are now in
place, so hook in the standard rotation property to expose the feature
to the users.
v2: Moving rotation_property to mode_config
v3: Moving creation of property out of
From: Sonika Jindal sonika.jin...@intel.com
Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.
v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.
v3: Checking if CRTC
From: Sonika Jindal sonika.jin...@intel.com
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
drivers/gpu/drm/drm_crtc.c |3 ++-
include/drm/drm_crtc.h |1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
On Tue, Jul 15, 2014 at 05:00:20PM +0530, sonika.jin...@intel.com wrote:
From: Sonika Jindal sonika.jin...@intel.com
Incorporating comments from Daniel regarding movement of creation of
rotation_property to drm_mode_create_standard_plane_properties and other minor
things.
Sonika Jindal
On 7/15/2014 5:32 PM, Daniel Vetter wrote:
On Tue, Jul 15, 2014 at 05:00:20PM +0530, sonika.jin...@intel.com wrote:
From: Sonika Jindal sonika.jin...@intel.com
Incorporating comments from Daniel regarding movement of creation of
rotation_property to drm_mode_create_standard_plane_properties
From: Sonika Jindal sonika.jin...@intel.com
Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.
v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.
v3: Checking if CRTC
From: Ville Syrjälä ville.syrj...@linux.intel.com
Sprite planes support 180 degree rotation. The lower layers are now in
place, so hook in the standard rotation property to expose the feature
to the users.
v2: Moving rotation_property to mode_config
v3: Moving creation of property out of
From: Sonika Jindal sonika.jin...@intel.com
v2: Adding creation of rotation_property here.
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
drivers/gpu/drm/drm_crtc.c |3 ++-
include/drm/drm_crtc.h |1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git
On 7/14/2014 9:20 PM, Daniel Vetter wrote:
On Mon, Jul 14, 2014 at 4:36 PM, Kumar, Shobhit shobhit.ku...@intel.com wrote:
/* XXX: read flags, set to adjusted_mode */
+ pipe_config-quirks = 1;
Nack. First you need to use one of the symbolic quirk definitions
(there's a bunch
Disable FF DOP clock gating.
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index
These workarounds are mainly for D/E/F steppings.
I didn't squash them, because we can eventually get rid of some of them.
Michel Thierry (8):
drm/i915: Add WaDisableFenceDestinationToSLM:bdw
drm/i915: Add WaProgramL3SqcReg1Default:bdw
drm/i915: Add WaDisableFfDopClockGating:bdw
drm/i915:
Coherent L3 cache lines are not getting flushed during context switch
which is causing issues.
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 4
2 files changed, 7 insertions(+)
diff --git
L3SQCREG4 LQSC RO PERF DIS must be programmed by software to 1h
(Disable) to work around a Gsync Issue in HDC.
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 2 ++
2 files changed, 3 insertions(+)
diff --git
Instruction Shootdown in ROW_CHICKEN must be disabled.
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
Workaround requires programing L3 tag clock timing register.
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_pm.c | 9 +
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
For performance, program the default initial value of L3SqcReg1 on BDW
to 0x784000:
L3SQ High Priority Credit Initialization = 2 (1b).
L3SQ General Priority Credit Initialization = 30 (0b).
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 4
Set desired default value for HDCCHICKEN register for BDW platform.
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
HDC_CHICKEN0 bit 14 (Fence Destination To SLM Disable) must be
programmed by software to 1h (Disable) to work around a LSLM unit issue.
WaDisableFenceDestinationToSLM is only needed for BDW E,F step.
Signed-off-by: Michel Thierry michel.thie...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1
Check in vlv_crtc_clock_get if DPLL is enabled before calling dpio read.
It will not be enabled for DSI and avoid dpio read WARN dumps.
Absence of -get_config was causing other WARN dumps as well. Update
dpll_hw_state as well correctly
v2: Address review comments by Daniel
- Check if DPLL is
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index b226724..8f36750 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
On Tue, Jul 15, 2014 at 03:05:33PM +0100, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Queued for -next, thanks for the patch.
-Daniel
---
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Thu, Apr 24, 2014 at 02:47:48PM -0700, Ben Widawsky wrote:
On Wed, Feb 12, 2014 at 07:18:40PM +, Chris Wilson wrote:
For stolen pages, since it is verboten to access them directly on many
architectures, we have to read them through the GTT aperture. If they
are not accessible through
On Jul-15-2014 12:18 PM, Daniel Vetter wrote:
[...]
I've pulled all 4 patches. Please double-check that I've picked up the
right ones since the series is a bit spread out.
Thanks, Daniel
Hi Daniel,
I checked the 4 patches in -next-queued. They are the correct version.
Thanks,
Vandana
Daniel Vetter mailto:dan...@ffwll.ch
Tuesday, July 15, 2014 12:46 AM
On Mon, Jul 14, 2014 at 12:10:47PM -0700, Todd Previte wrote:
The Displayport Link Layer Compliance Testing Specification 1.2 rev 1.1
specifies that
repeated AUX transactions after a failure (NACK, DEFER or no response) must
Daniel Vetter mailto:dan...@ffwll.ch
Tuesday, July 15, 2014 12:47 AM
On Mon, Jul 14, 2014 at 12:10:46PM -0700, Todd Previte wrote:
Cleans up a couple of unused variables and an extraneous debug log
message that was unintentionally left behind.
Signed-off-by: Todd Previtetprev...@gmail.com
This is a rebase from Ben's patches originally sent on July 1st, working in
latest drm-nightly. Below is Ben's original cover-letter.
==
Here be all the patches to make full PPGTT relatively stable on Broadwell. Most
of the work was actually to the generic PPGTT code, and not BDW
From: Ben Widawsky benjamin.widaw...@intel.com
There are two important reasons for this patch. It should make the
existing code a lot more readable. It also makes the next patch much
easier to understand in my opinion. There are 2 main variables that
effect this function, leaving 4 permutations:
From: Ben Widawsky benjamin.widaw...@intel.com
The bound list is global (all objects which back the VMAs are stored
here). Recently the BUG() in the offset lookup was demoted to a WARN,
but the fault actually lies in the caller, here.
This bug has existed since the initial introduction of PPGTT
From: Ben Widawsky benjamin.widaw...@intel.com
As what was correctly debugged here:
commit acc240d41ea1ab9c488a79219fb313b5b46265ae
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Thu Dec 5 15:42:34 2013 +0100
drm/i915: Fix use-after-free in do_switch
It then becomes apparent that the
From: Ben Widawsky benjamin.widaw...@intel.com
The simple explanation is, the docs say to do this for GEN8. Perhaps we
want to do this for GEN7 too, I am not certain.
PDPs are saved and restored with context. Contexts (without execlists)
only exist on the render ring. The docs say that PDPs are
From: Ben Widawsky benjamin.widaw...@intel.com
This is just a cosmetic change to try to put do_switch_rcs on a diet. As
it stands, the function was quite complex, and error prone.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_context.c | 32
From: Ben Widawsky benjamin.widaw...@intel.com
Rename some variables, and clean up the code a bit to make things
clearer in our error capture.
There isn't an intentional functional change here.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gpu_error.c | 55
From: Ben Widawsky benjamin.widaw...@intel.com
To follow up on the last patch, we can now capture the VMAs instead of
the BOs. The hope if we get more accurate error capture while debugging
PPGTT.
Note that this does not impact the previous argument about whether to
capture all VMAs, or just the
From: Ben Widawsky benjamin.widaw...@intel.com
Some of the original PPGTT patches in this area where unmerged, and this
left a lot of confusion in our error capture with regard to which vm/obj
we want to capture. There have been at least a couple of patches from
Chris, and myself to try to fix
From: Ben Widawsky benjamin.widaw...@intel.com
The comment [which was mine] is wrong. The context object can never be
bound in a PPGTT because it is only capable of living in the Global GTT.
So, remove the comment, and reorder the unref. What's nice about the
latter is it keeps the context object
From: Ben Widawsky benjamin.widaw...@intel.com
Broadwell is perfectly capable of full PPGTT. I've been using it for
some time, and seen no especially ill effects.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1
From: Ben Widawsky benjamin.widaw...@intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_evict.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index
From: Ben Widawsky benjamin.widaw...@intel.com
There are no users of this yet, but the idea is presented and split out
to find bugs.
Also, while here, return -ERESTARTSYS to the caller, in case they want
to do something with it.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
From: Ben Widawsky benjamin.widaw...@intel.com
If a VM still have objects which are bound (exactly: have a node
reserved in the drm_mm), and we are in the middle of a reset, we have no
hope of the standard methods fixing the situation (ring idle won't
work). We must therefore let the reset
From: Ben Widawsky benjamin.widaw...@intel.com
The last patch made PPGTT free cases correct. It left a major problem
though where in many cases it was possible to have to idle the GPU in
order to destroy a VM. This is really unfortunate as it is stalling the
active GPU process for the dying GPU
Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com
On Fri, Jul 4, 2014 at 7:50 AM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
So don't write it, otherwise we will trigger unclaimed register
errors.
Testcase: igt/pm_rpm/rte
Signed-off-by: Paulo Zanoni
Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com
On Thu, Jul 10, 2014 at 12:31 PM, Paulo Zanoni przan...@gmail.com wrote:
2014-07-08 11:58 GMT-03:00 Daniel Vetter dan...@ffwll.ch:
On Tue, Jul 08, 2014 at 11:15:03AM -0300, Paulo Zanoni wrote:
2014-07-07 18:23 GMT-03:00 Daniel Vetter
Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com
On Fri, Jul 4, 2014 at 7:50 AM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Move it from hsw_power_well_post_enable() (intel_pm.c) to i915_irq.c
so we can reuse the nice IRQ macros we have there. The
On Mon, Jul 7, 2014 at 2:34 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Jul 04, 2014 at 11:50:32AM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
The current code only runs when we do an I915_WRITE operation. It
checks if the unclaimed register flag is set
Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com
On Fri, Jul 4, 2014 at 7:50 AM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
By the time I wrote this patch, it allowed me to catch some problems.
But due to patch reordering - in order to prevent fake
On Tue, Jul 15, 2014 at 04:15:08PM +0200, Daniel Vetter wrote:
On Thu, Apr 24, 2014 at 02:47:48PM -0700, Ben Widawsky wrote:
On Wed, Feb 12, 2014 at 07:18:40PM +, Chris Wilson wrote:
For stolen pages, since it is verboten to access them directly on many
architectures, we have to read
From: Deepak S deepa...@linux.intel.com
Higher RC6 residency is observed using timeout mode
instead of EI mode. It's Recommended to use TO Method for RC6.
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed, 2 insertions(+), 2
69 matches
Mail list logo
