> As discussed on irc this contains a (not yet fully tuned and also not yet
> in granting mode) cmd parser for gen7. Performance is still a bit rough,
> but not quite as bad as originally feared (Ken later on discovered that he
> also changed something in his glamour setup which made things worse).
On Thu, 01 May 2014 00:03:15 +0300
Imre Deak wrote:
> On Wed, 2014-04-30 at 13:41 -0700, Ben Widawsky wrote:
> > On Wed, Apr 30, 2014 at 01:34:36PM -0700, Kristen Carlson Accardi wrote:
> > > On Tue, 29 Apr 2014 22:31:49 -0700
> > > Ben Widawsky wrote:
> > >
> > > > On Wed, Apr 09, 2014 at 11:4
On Wed, 2014-04-30 at 13:41 -0700, Ben Widawsky wrote:
> On Wed, Apr 30, 2014 at 01:34:36PM -0700, Kristen Carlson Accardi wrote:
> > On Tue, 29 Apr 2014 22:31:49 -0700
> > Ben Widawsky wrote:
> >
> > > On Wed, Apr 09, 2014 at 11:44:06AM -0700, Tom O'Rourke wrote:
> > > > Higher RC6 residency is
On Wed, Apr 30, 2014 at 01:34:36PM -0700, Kristen Carlson Accardi wrote:
> On Tue, 29 Apr 2014 22:31:49 -0700
> Ben Widawsky wrote:
>
> > On Wed, Apr 09, 2014 at 11:44:06AM -0700, Tom O'Rourke wrote:
> > > Higher RC6 residency is observed using timeout mode
> > > instead of EI mode. This applies
On Tue, 29 Apr 2014 22:31:49 -0700
Ben Widawsky wrote:
> On Wed, Apr 09, 2014 at 11:44:06AM -0700, Tom O'Rourke wrote:
> > Higher RC6 residency is observed using timeout mode
> > instead of EI mode. This applies to Broadwell only.
> > The difference is particularly noticeable with video
> > play
On Wed, Apr 30, 2014 at 08:03:27PM +0100, Chris Wilson wrote:
> On Wed, Apr 30, 2014 at 11:44:47AM -0700, Ben Widawsky wrote:
> > On Wed, Apr 30, 2014 at 08:13:25AM +0100, Chris Wilson wrote:
> > > On Tue, Apr 29, 2014 at 02:52:40PM -0700, Ben Widawsky wrote:
> > > > This appears to not actually be
On Wed, Apr 30, 2014 at 11:44:47AM -0700, Ben Widawsky wrote:
> On Wed, Apr 30, 2014 at 08:13:25AM +0100, Chris Wilson wrote:
> > On Tue, Apr 29, 2014 at 02:52:40PM -0700, Ben Widawsky wrote:
> > > This appears to not actually be needed on the current code. Just putting
> > > it on the ML so we can
On Wed, 2014-04-30 at 21:05 +0300, Ville Syrjälä wrote:
> On Tue, Apr 15, 2014 at 04:39:45PM +0300, Imre Deak wrote:
> > Atm, none of the RPM callbacks can fail, but the next patch adding
> > RPM support for VLV changes this, so prepare for it.
> >
> > In case one of these callbacks return error R
On Wed, Apr 30, 2014 at 08:13:25AM +0100, Chris Wilson wrote:
> On Tue, Apr 29, 2014 at 02:52:40PM -0700, Ben Widawsky wrote:
> > This appears to not actually be needed on the current code. Just putting
> > it on the ML so we can point bug reports at it later.
> >
> > As pointed out by Ville, the
On Tue, Apr 15, 2014 at 04:39:45PM +0300, Imre Deak wrote:
> Atm, none of the RPM callbacks can fail, but the next patch adding
> RPM support for VLV changes this, so prepare for it.
>
> In case one of these callbacks return error RPM will get permanently
> disabled until the error is explicitly c
On Wed, Apr 30, 2014 at 6:38 PM, Imre Deak wrote:
> On Fri, 2014-04-25 at 10:45 +0200, Daniel Vetter wrote:
>> Ok, review assignements. Please complain if you don't have the
>> bandwidth so that I can find someone else.
>>
>> On Thu, Apr 24, 2014 at 11:54 PM, Daniel Vetter
>> wrote:
>> >
>> > Da
On Tue, Apr 22, 2014 at 08:28:33PM +0300, Imre Deak wrote:
> Add runtime PM support for VLV, but leave it disabled. The next patch
> enables it.
>
> The suspend/resume sequence used is based on [1] and [2]. In practice we
> depend on the GT RC6 mechanism to save the HW context depending on the
> r
On Wed, Apr 30, 2014 at 5:36 PM, Shobhit Kumar wrote:
>>>drm/i915: Shovel hw setup code out of i9xx_crtc_mode_set
>>>drm/i915: Move lowfreq_avail around a bit in ilk/hsw_crtc_mode_set
>>>drm/i915: Shovel hw setup code out of ilk_crtc_mode_set
>>>drm/i915: Shovel hw setup code out o
On Wed, Apr 30, 2014 at 09:19:32PM +0530, Deepak S wrote:
>
> On Monday 28 April 2014 08:42 PM, Daniel Vetter wrote:
> >On Mon, Apr 28, 2014 at 4:47 PM, wrote:
> >>From: Deepak S
> >>
> >>We are adding a module paramter to control rps boost. By default, we
> >>enable the boost for better perfor
For some of our tests, we want to make sure that bogus plane programming
attempts fail with the expected error code. Add
igt_drm_plane_try_commit() that will just return the error code on
failure rather than failing the current subtest. This lets us test the
return value against the expected erro
Recent changes in igt_kms to support universal planes have removed the
plane list order guarantees that kms_plane depended upon. Ensure that
we loop over the entire plane list properly and then selectively skip
non-overlay planes.
While we're at it, update a couple igt_output_get_plane() calls to
Add a simple test to exercise universal plane support.
v2:
- Test that pageflips error out gracefully when the primary plane
is disabled before the ioctl, or between ioctl and pageflip
execution.
- Test that nothing blows up if we try to disable the primary plane
immediately after a pag
Intel hardware allows the primary plane to be disabled independently of
the CRTC. Provide custom primary plane handling to allow this.
v6:
- Pass rectangles to primary helper check function and get plane
visibility back.
- Wait for pending pageflips on primary plane update/disable.
- Allow
This iteration of the patch series fixes up some conflicts between primary
plane disabling and other KMS operations (i-g-t tests will be sent shortly).
It also refactors the plane update parameter checking into a new DRM core
primary plane helper function. Unlike the previous iteration of the patc
Add support for universal planes. This involves revamping the existing
plane handling a bit to allow primary & cursor planes to come from the
DRM plane list, rather than always being manually added. Also,
eliminate the hard-coded position of primary & cursor in the plane list
since the DRM could
The DRM core setplane code should check that the plane is usable on the
specified CRTC before calling into the driver.
Prior to this patch, a plane's possible_crtcs field was purely
informational for userspace and was never actually verified at the
kernel level (aside from the primary plane helper
In a future patch, we'll allow the primary plane to be disabled by
userspace via the universal plane API. If a modeset is requested while
the primary plane is disabled, crtc->primary->fb will be NULL which
generally triggers a full modeset (except in fastboot situations). If
we detect that the cr
Pull the parameter checking from drm_primary_helper_update() out into
its own function; drivers that provide their own setplane()
implementations rather than using the helper may still want to share
this parameter checking logic.
A few of the checks here were also updated based on suggestions by
V
On Fri, 2014-04-25 at 10:45 +0200, Daniel Vetter wrote:
> Ok, review assignements. Please complain if you don't have the
> bandwidth so that I can find someone else.
>
> On Thu, Apr 24, 2014 at 11:54 PM, Daniel Vetter
> wrote:
> >
> > Daniel Vetter (66):
> > drm/i915: Make encoder->mode_set ca
Actually just whitespace change to make sure the new built rules for
tests/*.txt pick up the changes properly everywhere.
Signed-off-by: Daniel Vetter
---
tests/Makefile.sources | 1 -
1 file changed, 1 deletion(-)
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index a8a091de6ccf.
Oops, pretty bad ...
Signed-off-by: Daniel Vetter
---
tests/Makefile.am | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 8ce0858d0de4..71ecdf2063fd 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -17,12 +17,12 @@ list-m
On Wed, Apr 30, 2014 at 05:43:01PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The BIOS can enable a pipe but leave the primary plane disabled. This
> coflicts with out current idea of primary_enabled. Read the actual
> hardware plane state and set primary_enabled approp
On Monday 28 April 2014 08:42 PM, Daniel Vetter wrote:
On Mon, Apr 28, 2014 at 4:47 PM, wrote:
From: Deepak S
We are adding a module paramter to control rps boost. By default, we
enable the boost for better performace. Based on the need (perf/power)
we can either enable/disable.
v2: Addres
drm/i915: Shovel hw setup code out of i9xx_crtc_mode_set
drm/i915: Move lowfreq_avail around a bit in ilk/hsw_crtc_mode_set
drm/i915: Shovel hw setup code out of ilk_crtc_mode_set
drm/i915: Shovel hw setup code out of hsw_crtc_mode_set
drm/i915: Extract i9xx_set_pll_dividers
drm/
From: Ville Syrjälä
The BIOS can enable a pipe but leave the primary plane disabled. This
coflicts with out current idea of primary_enabled. Read the actual
hardware plane state and set primary_enabled appropriately.
We currently assume that primary_enabled is always true when we're about
to dis
On Mon, Apr 14, 2014 at 08:24:44PM +0300, Imre Deak wrote:
> Needed by the VLV S0ix context save/restore helpers.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_reg.h | 43
> -
> 1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --
On Wed, 2014-04-09 at 13:28 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add chv_crtc_clock_get() to read out the DPLL settings.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 34 +-
> 1 file changed, 33
On Wed, 2014-04-09 at 13:28 +0300, ville.syrj...@linux.intel.com wrote:
> From: Chon Ming Lee
>
> With additional of pipe C, current 1 bit registers for pipe select
> for HDMI and DP are no longer able to gather for 3 pipes. As a result,
> new bits location in the same registers are added.
>
> F
On Tue, Apr 29, 2014 at 02:52:31PM -0700, Ben Widawsky wrote:
> With the ring mask we now have an easy way to know the number of rings
> in the system, and therefore can accurately predict the number of dwords
> to emit for semaphore signalling. This was not possible (easily)
> previously.
>
> The
On Wed, Apr 30, 2014 at 02:00:16PM +0300, Jani Nikula wrote:
> On Wed, 30 Apr 2014, Daniel Vetter wrote:
> > On Wed, Apr 30, 2014 at 08:30:00AM +0100, Chris Wilson wrote:
> >> In commit 691e6415c891b8b2b082a120b896b443531c4d45
> >> Author: Chris Wilson
> >> Date: Wed Apr 9 09:07:36 2014 +0100
>
On Wed, Apr 30, 2014 at 12:43:18PM +0100, Chris Wilson wrote:
> On Wed, Apr 30, 2014 at 02:40:10PM +0300, Ville Syrjälä wrote:
> > On Wed, Apr 30, 2014 at 12:28:25PM +0100, Chris Wilson wrote:
> > > On Mon, Apr 28, 2014 at 03:53:25PM +0300, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From:
On Wed, 2014-04-09 at 13:28 +0300, ville.syrj...@linux.intel.com wrote:
> From: Chon Ming Lee
>
> Added programming phy layer for CHV based on "Application note for 1273
> CHV Display phy".
>
> v2: Rebase the code and do some cleanup.
> v3: Rework based on Ville review.
> -Fix the macro wher
On Wed, Apr 30, 2014 at 02:40:10PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 30, 2014 at 12:28:25PM +0100, Chris Wilson wrote:
> > On Mon, Apr 28, 2014 at 03:53:25PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > We won't be calling intel_enable_primary_pla
On Wed, Apr 30, 2014 at 12:28:25PM +0100, Chris Wilson wrote:
> On Mon, Apr 28, 2014 at 03:53:25PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We won't be calling intel_enable_primary_plane() or
> > intel_disable_primary_plane() with the primary plane in the
> > wr
On Tue, Apr 29, 2014 at 02:52:27PM -0700, Ben Widawsky wrote:
> Okay, trying this again after the somewhat painful VCS2 rebase. I think I got
> to all of Ville's comments, but I could have missed a few. I apologize if so.
>
> Daniel, even if you don't merge the whole series, the first few would re
On Mon, Apr 28, 2014 at 03:53:25PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We won't be calling intel_enable_primary_plane() or
> intel_disable_primary_plane() with the primary plane in the
> wrong state. So remove the useless DISPLAY_PLANE_ENABLE checks.
Oh, really?
On Tue, Apr 29, 2014 at 02:52:35PM -0700, Ben Widawsky wrote:
> From: Ben Widawsky
>
> This is needed to implement ipehr_is_semaphore_wait
>
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_irq.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git
On Wed, 30 Apr 2014, Daniel Vetter wrote:
> On Wed, Apr 30, 2014 at 08:30:00AM +0100, Chris Wilson wrote:
>> In commit 691e6415c891b8b2b082a120b896b443531c4d45
>> Author: Chris Wilson
>> Date: Wed Apr 9 09:07:36 2014 +0100
>>
>> drm/i915: Always use kref tracking for all contexts.
>>
>> w
On Tue, Apr 29, 2014 at 02:52:36PM -0700, Ben Widawsky wrote:
> As Ville points out, it's possible/probable we don't actually need this.
> Potentially, this validates the letter of the spec, and not the spirit.
>
> Ville:
> > I discussed this on irc w/ Ben, and I was suggesting we don't need to
>
On Fri, Apr 25, 2014 at 01:19:05PM +0300, Imre Deak wrote:
> During the initial power well enabling on the driver init/resume path
> we can avoid initialzing part of the HW/SW state that will be
> initialized anyway by the subsequent init/resume code. For some steps
> like HPD initialization this r
On Wed, Apr 30, 2014 at 08:30:00AM +0100, Chris Wilson wrote:
> In commit 691e6415c891b8b2b082a120b896b443531c4d45
> Author: Chris Wilson
> Date: Wed Apr 9 09:07:36 2014 +0100
>
> drm/i915: Always use kref tracking for all contexts.
>
> we populated fake contexts on all platforms. These we
On Wed, Apr 30, 2014 at 8:56 AM, Chris Wilson wrote:
> On Tue, Apr 29, 2014 at 04:38:21PM +0200, Daniel Vetter wrote:
>> int intel_gpu_reset(struct drm_device *dev)
>> {
>> + struct drm_i915_private *dev_priv = dev->dev_private;
>> + struct intel_ring_buffer *ring;
>> + int i;
>> +
>
In commit 691e6415c891b8b2b082a120b896b443531c4d45
Author: Chris Wilson
Date: Wed Apr 9 09:07:36 2014 +0100
drm/i915: Always use kref tracking for all contexts.
we populated fake contexts on all platforms. These were identical to the
full hardware context tracking structs, except for the c
On Tue, Apr 29, 2014 at 02:52:40PM -0700, Ben Widawsky wrote:
> This appears to not actually be needed on the current code. Just putting
> it on the ML so we can point bug reports at it later.
>
> As pointed out by Ville, the current code is "broken" since we do
> FORCE_RESTORE, and RESTORE_INHIBI
49 matches
Mail list logo
