On Mon, Apr 28, 2014 at 07:20:17PM -0700, Ben Widawsky wrote:
> On Mon, Apr 28, 2014 at 01:53:52PM -0700, Daisy Sun wrote:
> > RP frequency request is affected by 2 modules: normal turbo
> > algorithm and RPS boost algorithm. By adding RPS boost algorithm
> > to the mix, the final frequency becomes
Previously, our code only had a 32b offset value for where the
batchbuffer starts. With full PPGTT, and 64b canonical GPU address
space, that is an insufficient value. The code to expand is pretty
straight forward, and only one platform needs to do anything with the
extra bits.
Signed-off-by: Ben
v2: 0 pad the new 8B fields or else intel_error_decode has a hard time.
Note, regardless we need an igt update.
v3: Make reloc_offset 64b also.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_gpu_error.c | 18 ++
2 files
On Mon, Apr 28, 2014 at 01:53:52PM -0700, Daisy Sun wrote:
> RP frequency request is affected by 2 modules: normal turbo
> algorithm and RPS boost algorithm. By adding RPS boost algorithm
> to the mix, the final frequency becomes relatively unpredictable.
> Add a switch to enable/disable RPS boost
See the relevant kernel patch for the details. I guess this breaks
support for older error state, I am not actually sure. Without
versioning our error state though, I cannot think of a better way.
Suggestions are welcome.
Signed-off-by: Ben Widawsky
---
tools/intel_error_decode.c | 14 +++---
v2: 0 pad the new 8B fields or else intel_error_decode has a hard time.
Note, regardless we need an igt update.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_gpu_error.c | 16 +---
2 files changed, 11 insertions(+), 9 delet
On Sat, Jan 25, 2014 at 08:10:06PM +0100, Daniel Vetter wrote:
> On Fri, Jan 24, 2014 at 12:13:44PM -0800, Ben Widawsky wrote:
> > ping
>
> Merged the first patch to topic/ppgtt, but punted on the 2nd - I think
> with Mika's improvement to the guilty batch detection we should be able to
> fix this
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_gpu_error.c | 16 +---
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 539f16db..cdde849 1
All the rest of the code to enable this is in my branch. Without my
branch, hitting > 32b offsets is impossible. The code has always
"supported" 64b, but it's never actually been run of tested. This change
doesn't actually fix anything. [1] I am not sure why X won't work yet. I
do not get hangs or
2014-04-28 5:23 GMT-03:00 Ville Syrjälä :
> On Fri, Apr 25, 2014 at 05:55:38PM -0300, Paulo Zanoni wrote:
>> 2014-04-09 7:28 GMT-03:00 :
>> > From: Rafael Barbalho
>> >
>> > Cherryview also needs this WA.
>>
>> At least on the chv_rebase tree, this WA is implemented for BDW but it
>> is not docum
2014-04-28 8:31 GMT-03:00 :
> From: Ville Syrjälä
>
> We implement the following workarounds:
> * WaDisableAsyncFlipPerfMode:chv
> * WaProgramMiArbOnOffAroundMiSetContext:chv
>
> v2: Drop WaDisableSemaphoreAndSyncFlipWait note
Reviewed-by: Paulo Zanoni
>
> Signed-off-by: Ville Syrjälä
> ---
>
2014-04-28 9:58 GMT-03:00 :
> From: Ville Syrjälä
>
> Becasue of the upcoming vblank interrupt driven watermark update
BecaUSe.
Reviewed-by: Paulo Zanoni
> mechanism we will have use for vblank interrupts during plane
> enabling/disabling. So don't call drm_vblank_off() until planes
> are off
2014-04-28 9:53 GMT-03:00 :
> 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.
>
> v2: Convert the checks to WARNs instead (Daniel,Paulo)
Rev
2014-04-28 9:44 GMT-03:00 :
> From: Ville Syrjälä
>
> On ILK when we disable a particular watermark level, we must
> maintain the actual watermark values for that level for some time
> (until the next vblank possibly). Otherwise we risk underruns.
>
> In order to achieve that result we must merge
2014-04-28 9:44 GMT-03:00 :
> From: Ville Syrjälä
>
> When we calculate the watermarks for a pipe make sure we leave any
> level fully zeroed out if it would exceed any of the maximum values
> that fit in the registers.
>
> This will be important later when we start to use also disabled
> waterma
RP frequency request is affected by 2 modules: normal turbo
algorithm and RPS boost algorithm. By adding RPS boost algorithm
to the mix, the final frequency becomes relatively unpredictable.
Add a switch to enable/disable RPS boost functionality. When
disabled, RP frequency will follow the normal t
On Mon, 2014-04-28 at 21:23 +0200, Daniel Vetter wrote:
> On Mon, Apr 28, 2014 at 8:14 PM, Paulo Zanoni wrote:
> > This can probably be reproduced on non-BDW machines too, with RC6 disabled.
>
> If I understand Imre's patch correctly the bug is that we didn't have
> rc6 on bdw, but the sanitize f
On Mon, Apr 28, 2014 at 8:14 PM, Paulo Zanoni wrote:
> This can probably be reproduced on non-BDW machines too, with RC6 disabled.
If I understand Imre's patch correctly the bug is that we didn't have
rc6 on bdw, but the sanitize function didn't make this clear leading
to bugs. If my understandin
On Mon, 2014-04-28 at 15:35 -0300, Paulo Zanoni wrote:
> 2014-04-28 15:22 GMT-03:00 Imre Deak :
> > On Mon, 2014-04-28 at 14:57 -0300, Paulo Zanoni wrote:
> >> 2014-04-25 5:08 GMT-03:00 Daniel Vetter :
> >> > On Fri, Apr 25, 2014 at 10:29:57AM +0300, Imre Deak wrote:
> >> >> The PC8 state won't be
On Mon, 2014-04-28 at 15:35 -0300, Paulo Zanoni wrote:
> 2014-04-28 15:22 GMT-03:00 Imre Deak :
> > On Mon, 2014-04-28 at 14:57 -0300, Paulo Zanoni wrote:
> >> 2014-04-25 5:08 GMT-03:00 Daniel Vetter :
> >> > On Fri, Apr 25, 2014 at 10:29:57AM +0300, Imre Deak wrote:
> >> >> The PC8 state won't be
2014-04-28 15:22 GMT-03:00 Imre Deak :
> On Mon, 2014-04-28 at 14:57 -0300, Paulo Zanoni wrote:
>> 2014-04-25 5:08 GMT-03:00 Daniel Vetter :
>> > On Fri, Apr 25, 2014 at 10:29:57AM +0300, Imre Deak wrote:
>> >> The PC8 state won't be entered unless runtime PM is enabled, so support
>> >> for PC8 re
On Mon, 2014-04-28 at 14:57 -0300, Paulo Zanoni wrote:
> 2014-04-25 5:08 GMT-03:00 Daniel Vetter :
> > On Fri, Apr 25, 2014 at 10:29:57AM +0300, Imre Deak wrote:
> >> The PC8 state won't be entered unless runtime PM is enabled, so support
> >> for PC8 residency counters alone is not enough to run t
2014-04-23 4:05 GMT-03:00 Daniel Vetter :
> On Tue, Apr 22, 2014 at 06:25:12PM -0300, Paulo Zanoni wrote:
>> 2014-04-11 6:02 GMT-03:00 Daniel Vetter :
>> > On Thu, Apr 10, 2014 at 10:52:26AM -0700, Ben Widawsky wrote:
>> >> On Thu, Apr 10, 2014 at 10:50:43AM -0700, Ben Widawsky wrote:
>> >> > On Th
2014-04-25 5:08 GMT-03:00 Daniel Vetter :
> On Fri, Apr 25, 2014 at 10:29:57AM +0300, Imre Deak wrote:
>> The PC8 state won't be entered unless runtime PM is enabled, so support
>> for PC8 residency counters alone is not enough to run this test.
This is true only for the very latest kernels. We ha
On 04/26/2014 06:10 AM, Chris Wilson wrote:
>>> > > Thanks for the pointer to
>>> > > register_oom_notifier(), I can use that to make sure that we do purge
>>> > > everything from the GPU, and do a sanity check at the same time, before
>>> > > we start killing processes.
>> >
>> > Actually, that o
Reviewed-by: Brad Volkin
On Fri, Apr 18, 2014 at 02:04:29PM -0700, Rodrigo Vivi wrote:
> From: Ben Widawsky
>
> It seems we need this at least for the current platforms we have, but
> probably not later. In any event, it should cause too much harm as we do
> the same thing on several other plat
Reviewed-by: Brad Volkin
On Fri, Apr 18, 2014 at 02:04:28PM -0700, Rodrigo Vivi wrote:
> From: Ben Widawsky
>
> The same register exists for querying and programming eDRAM AKA eLLC. So
> we can simply use it. For now, use all the same defaults as we had
> for Haswell, since like Haswell, I have
On Fri, Apr 18, 2014 at 02:04:27PM -0700, Rodrigo Vivi wrote:
> From: Ben Widawsky
>
> I don't have any insight on what parts can do what. The docs do seem to
> suggest WT caching works in at least the same manner as it doesn't on
> Haswell.
As Ben previously mentioned, s/doesn't/does. Other tha
On Mon, Apr 28, 2014 at 6:07 PM, Volkin, Bradley D
wrote:
> On Mon, Apr 28, 2014 at 08:53:30AM -0700, Daniel Vetter wrote:
>> On Mon, Apr 28, 2014 at 08:22:08AM -0700, bradley.d.vol...@intel.com wrote:
>> > From: Brad Volkin
>> >
>> > For clients that submit large batch buffers the command parser
On Mon, Apr 28, 2014 at 08:53:30AM -0700, Daniel Vetter wrote:
> On Mon, Apr 28, 2014 at 08:22:08AM -0700, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > For clients that submit large batch buffers the command parser has
> > a substantial impact on performance. On my HSW ULT syst
On Mon, Apr 28, 2014 at 08:42:56AM -0700, Daniel Vetter wrote:
> On Mon, Apr 28, 2014 at 08:22:08AM -0700, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > For clients that submit large batch buffers the command parser has
> > a substantial impact on performance. On my HSW ULT syst
On Mon, Apr 28, 2014 at 08:22:08AM -0700, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> For clients that submit large batch buffers the command parser has
> a substantial impact on performance. On my HSW ULT system performance
> drops as much as ~20% on some tests. Most of the time is
On Mon, Apr 28, 2014 at 08:22:08AM -0700, Volkin, Bradley D wrote:
> From: Brad Volkin
>
> For clients that submit large batch buffers the command parser has
> a substantial impact on performance. On my HSW ULT system performance
> drops as much as ~20% on some tests. Most of the time is spent in
On Mon, Apr 28, 2014 at 08:22:08AM -0700, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> For clients that submit large batch buffers the command parser has
> a substantial impact on performance. On my HSW ULT system performance
> drops as much as ~20% on some tests. Most of the time is
From: Brad Volkin
For clients that submit large batch buffers the command parser has
a substantial impact on performance. On my HSW ULT system performance
drops as much as ~20% on some tests. Most of the time is spent in the
command lookup code. Converting that from the current naive search to
a
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: Addressed rps default comment (Jani)
>
> v3: Use bool
Thanks for the review. I will address the comments
On Monday 28 April 2014 07:59 PM, Imre Deak wrote:
On Mon, 2014-04-21 at 13:34 +0530, deepa...@linux.intel.com wrote:
From: Deepak S
v2: Configure PCBR if BIOS fails allocate pcbr (deepak)
v3: Fix PCBR condition check during CHV RC6 Enable
Thanks for the review. I will address the comments
On Saturday 26 April 2014 03:12 AM, Ben Widawsky wrote:
On Mon, Apr 21, 2014 at 01:34:07PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S
v2: Configure PCBR if BIOS fails allocate pcbr (deepak)
v3: Fix PCBR condition check during CHV
On Monday 28 April 2014 08:15 PM, Daniel Vetter wrote:
On Mon, Apr 28, 2014 at 05:29:46PM +0300, Imre Deak wrote:
+static void cherryview_setup_pctx(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ unsigned long pctx_paddr;
+ struct i915_gtt
From: "Siluvery, Arun"
This patch adds support to have gem objects of variable size.
The size of the gem object obj->size is always constant and this fact
is tightly coupled in the driver; this implementation allows to vary
its effective size using an interface similar to fallocate().
A new ioct
On Mon, Apr 28, 2014 at 08:17:04PM +0530, deepa...@linux.intel.com 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: Addressed rps defau
On Wed, 2014-04-09 at 13:28 +0300, ville.syrj...@linux.intel.com wrote:
> From: Chon Ming Lee
>
> During cold boot, the display controller needs to deassert the common
> lane reset. Only do it once during intel_init_dpio for both PHYx2 and
> PHYx1.
>
> Besides, assert the common lane reset when
With the vebox 2 patches the number of internal rings don't match the
number of exposed rings. So add another subtest with an invalid ring
which should be invalid both internally and externally. The bug this
will catch is using the ring structure before validation, which the
old "invalide-ring" won
From: Deepak S
With RC6 enabled, BYT has an HW issue in determining the right
Gfx busyness.
WA for Turbo + RC6: Use SW based Gfx busy-ness detection to decide
on increasing/decreasing the freq. This logic will monitor C0
counters of render/media power-wells over EI period and takes
necessary acti
ville.syrj...@linux.intel.com writes:
> From: Ville Syrjälä
>
> The spec only tells us to set individual bits here and there. So we use
> RMW for most things. Do the same for the swing calc init.
>
> Eventually we should optimize things to just blast the final value in
> with group access wheneve
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: Addressed rps default comment (Jani)
v3: Use bool to represent the boot parameter (Ville).
Signed-off-by:
On Mon, Apr 28, 2014 at 05:29:46PM +0300, Imre Deak wrote:
> > +static void cherryview_setup_pctx(struct drm_device *dev)
> > +{
> > + struct drm_i915_private *dev_priv = dev->dev_private;
> > + unsigned long pctx_paddr;
> > + struct i915_gtt *gtt = &dev_priv->gtt;
> > + u32 pcbr;
> > + i
> > > tmp = I915_READ(GEN8_GT_IIR(0));
> > > if (tmp) {
> > > ret = IRQ_HANDLED;
> > > +
> > > rcs = tmp >> GEN8_RCS_IRQ_SHIFT;
> > > - bcs = tmp >> GEN8_BCS_IRQ_SHIFT;
> > > + ri
On Wed, 2014-04-09 at 13:28 +0300, ville.syrj...@linux.intel.com wrote:
> From: Chon Ming Lee
>
> Cherryview has 3 pipes. Some of the pll dpio offset calculation is
> based on pipe number. Need to use vlv_pipe_to_channel to calculate the
> correct phy channel to use for the pipe.
>
> Signed-of
On Mon, 2014-04-21 at 13:34 +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> v2: Configure PCBR if BIOS fails allocate pcbr (deepak)
>
> v3: Fix PCBR condition check during CHV RC6 Enable flag set
>
> Signed-off-by: Deepak S
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> driver
On Mon, Apr 28, 2014 at 01:10:07PM +0300, Jani Nikula wrote:
> This reverts the bisected regressing
>
> commit bc0bb9fd1c7810407ab810d204bbaecb255fddde
> Author: Jani Nikula
> Date: Thu Nov 14 12:14:29 2013 +0200
>
> drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE
>
> restoring QUIRK_NO_PCH_PWM_
On Mon, Apr 28, 2014 at 11:19:29AM +0800, Aaron Lu wrote:
> When we set backlight on behalf of ACPI opregion, we will convert the
> backlight value in the 0-255 range defined in opregion to the actual
> hardware level. Commit 22505b82a2 (drm/i915: avoid brightness overflow
> when doing scale) is me
On Mon, Apr 28, 2014 at 12:03:59PM +0300, Imre Deak wrote:
> On BDW we don't enable RC6 at the moment, but this isn't reflected in
> the (sanitized) i915.enable_rc6 option. So make enable_rc6 report
> correctly that RC6 is disabled, which will also effectively disable RPM
> on BDW (since RPM depend
On Fri, Apr 25, 2014 at 10:12:07PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> assert_plane_enabled() is now triggering during FDI link train because
> we no longer enable planes that early.
>
> This problem got introduced in:
> commit a5c4d7bc187bd13bc11ac06bb4ea3a0d4
On Mon, Apr 28, 2014 at 03:03:23PM +0200, Jan Moskyto Matejka wrote:
> This reverts commit 60f2b4af1258c05e6b037af866be81abc24438f7.
>
> The same warning has been fixed in e5081a538a565284fec5f30a937d98e460d5e780
> and
> these two commits got merged in 74e99a84de2d0980320612db8015ba606af42114 whi
Hi Dave,
drm-intel-next-2014-04-16:
- vlv infoframe fixes from Jesse
- dsi/mipi fixes from Shobhit
- gen8 pageflip fixes for LRI/SRM from Damien
- cmd parser fixes from Brad Volkin
- some prep patches for CHV, DRRS, ...
- and tons of little things all over
drm-intel-next-2014-04-04:
- cmd parser f
This reverts commit 60f2b4af1258c05e6b037af866be81abc24438f7.
The same warning has been fixed in e5081a538a565284fec5f30a937d98e460d5e780 and
these two commits got merged in 74e99a84de2d0980320612db8015ba606af42114 which
caused another warning. Simply, the reverted commit casted the pointer
differ
From: Ville Syrjälä
Becasue of the upcoming vblank interrupt driven watermark update
mechanism we will have use for vblank interrupts during plane
enabling/disabling. So don't call drm_vblank_off() until planes
are off, and call drm_vblank_on() just before we start to enable
the planes.
v2: Pimp
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.
v2: Convert the checks to WARNs instead (Daniel,Paulo)
Signed-off-by: Ville Syrjälä
---
drivers/g
From: Ville Syrjälä
On ILK when we disable a particular watermark level, we must
maintain the actual watermark values for that level for some time
(until the next vblank possibly). Otherwise we risk underruns.
In order to achieve that result we must merge the LP1+ watermarks a
bit differently si
From: Ville Syrjälä
When we calculate the watermarks for a pipe make sure we leave any
level fully zeroed out if it would exceed any of the maximum values
that fit in the registers.
This will be important later when we start to use also disabled
watermark levels during LP1+ merging.
Signed-off-
From: Ville Syrjälä
We implement the following workarounds:
* WaDisableAsyncFlipPerfMode:chv
* WaProgramMiArbOnOffAroundMiSetContext:chv
v2: Drop WaDisableSemaphoreAndSyncFlipWait note
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/intel_
On Fri, Apr 25, 2014 at 05:43:55PM -0300, Paulo Zanoni wrote:
> 2014-04-09 7:28 GMT-03:00 :
> > From: Ville Syrjälä
> >
> > We implement the following workarounds:
> > * WaDisableAsyncFlipPerfMode:chv
> > * WaDisableSemaphoreAndSyncFlipWait:chv (at least partially)
>
> In the rebased version (on
From: Ville Syrjälä
The bits we've been setting so far only progagate the reset singal to
the data lanes. To actaully force the reset signal we need to set another
override bit.
v2: Fix mispalced ';' (Mika)
Reviewed-by: Mika Kuoppala
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915
From: Ville Syrjälä
On CHV pipe C can driver only port D, and pipes A and B can drivbe only
ports B and C. Configure the crtc_mask appropriately to reflect that.
v2: Moar braces (Jani)
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 9 -
drivers/gpu/drm/i915/intel
From: Rafael Barbalho
Add support for the third pipe in cherrview
v2: Don't use spaces for indentation (Jani)
Wrap long lines
Reviewed-by: Imre Deak
Signed-off-by: Rafael Barbalho
[vsyrjala: slightly massaged the patch]
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c |
Jani Nikula writes:
> This reverts the bisected regressing
> commit bc0bb9fd1c7810407ab810d204bbaecb255fddde
> Author: Jani Nikula
> Date: Thu Nov 14 12:14:29 2013 +0200
> drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE
> restoring QUIRK_NO_PCH_PWM_ENABLE for a couple of Dell XPS models which
This reverts the bisected regressing
commit bc0bb9fd1c7810407ab810d204bbaecb255fddde
Author: Jani Nikula
Date: Thu Nov 14 12:14:29 2013 +0200
drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE
restoring QUIRK_NO_PCH_PWM_ENABLE for a couple of Dell XPS models which
broke in 3.14.
There is no such r
Stable team -
I'd like to hear your opinions on this one. It reverts a commit that
regressed in 3.14, but the revert does not exist upstream. Instead we've
root caused the issue and provided a real fix for upstream, but we're
hesitant to backport that to stable. Functionally the effect of the
reve
From: "Siluvery, Arun"
This ioctl allows vary the effective size of the gem object.
User can mark certain range in object space as scratch thus
effectively modifying the size used.
v2: modify subtest names and function names as per tooling convention.
Signed-off-by: Siluvery, Arun
---
tests/M
On BDW we don't enable RC6 at the moment, but this isn't reflected in
the (sanitized) i915.enable_rc6 option. So make enable_rc6 report
correctly that RC6 is disabled, which will also effectively disable RPM
on BDW (since RPM depends on RC6).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=
On Fri, Apr 25, 2014 at 05:55:38PM -0300, Paulo Zanoni wrote:
> 2014-04-09 7:28 GMT-03:00 :
> > From: Rafael Barbalho
> >
> > Cherryview also needs this WA.
>
> At least on the chv_rebase tree, this WA is implemented for BDW but it
> is not documented as pre-prod only, and its name is not there.
72 matches
Mail list logo
