On Sat, 2015-11-28 at 11:05 +0100, Daniel Vetter wrote:
> Similar to
>
> commit 37ca8d4ccd9860df0747aa2ea281a3c9c4bf8826
> Author: Ville Syrjälä
> Date: Fri Oct 30 19:20:27 2015 +0200
>
> drm/i915: Enable PCH FIFO underruns later on ILK/SNB/IVB
>
> we can only enable fifo underrun reporti
Forcing connector state is a basic piece of our test infrastructure
that we use in all the kms_ tests. It allows us to run tests even if
no outputs are connected.
They're also really fast, so perfect candidates for inclusion into the
BAT set.
Signed-off-by: Daniel Vetter
---
tests/.gitignore
Two things:
- Somehow the kernel's mode list changed with our EDID. No idea
whether that's the right thing here since I'm not really an EDID
expert. But then again the testcase wants to check that the
injection works, not validate the kernel's parser.
- We need to disable the forcing _before
Speeds up testcases except for those where we want to exercise the
probing itself. The only exceptions left where we do a full probe are
- pm_rpm: We use it to make sure the kernel doesn't get things wrong
with power domains, so we really want to exercise the full probe
paths. And there the on
On Sat, 2015-11-28 at 11:05 +0100, Daniel Vetter wrote:
> Similar to
>
> commit 37ca8d4ccd9860df0747aa2ea281a3c9c4bf8826
> Author: Ville Syrjälä
> Date: Fri Oct 30 19:20:27 2015 +0200
>
> drm/i915: Enable PCH FIFO underruns later on ILK/SNB/IVB
>
> we can only enable fifo underrun reporti
The only missing piece is the function to convert frequency to PWM
register value. The PWM is based on 19.2 MHz clock, except for BXT A
step, which is based on CDCLK, and which we ignore.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_panel.c | 9 +
1 file changed, 9 insertion
If the backlight modulation frequency can't be extracted from the
registers or from VBT, use 200 Hz as the default. This may enable
backlight on some machines that previously failed.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_panel.c | 16 +---
1 file changed, 9 insert
From: Imre Deak
Per bspec, "Backlight PWM may stop in the asserted state, causing
backlight to stay fully on. WA: Before disabling PWM, set CLKGATE_DIS_0
0x46530 bit 13 PWM1 Gating Dis (for PWM1) or bit 14 PWM2 Gating Dis (for
PWM2). The bits can remain set without harm." (There's no workaround
n
On Tue, Dec 01, 2015 at 10:15:01AM +0200, Mika Kahola wrote:
> On Sat, 2015-11-28 at 11:05 +0100, Daniel Vetter wrote:
> > Similar to
> >
> > commit 37ca8d4ccd9860df0747aa2ea281a3c9c4bf8826
> > Author: Ville Syrjälä
> > Date: Fri Oct 30 19:20:27 2015 +0200
> >
> > drm/i915: Enable PCH FIFO
On Mon, Nov 30, 2015 at 10:11:12AM +, Chris Wilson wrote:
> On Thu, Nov 26, 2015 at 12:34:34PM +0100, Daniel Vetter wrote:
> > So there's 3 competing proposals for what wait_ioctl should do wrt
> > -EIO:
> >
> > - return -EIO when the gpu is wedged. Not terribly useful for
> > userspace sinc
On Sun, Nov 29, 2015 at 08:48:03AM +, Chris Wilson wrote:
> If we do not have lowlevel support for reseting the GPU, or if the user
> has explicitly disabled reseting the device, the failure is expected.
> Since it is an expected failure, we should be using a lower priority
> message than *ERRO
On Sun, Nov 29, 2015 at 08:48:02AM +, Chris Wilson wrote:
> Instead of querying the reset counter before every access to the ring,
> query it the first time we touch the ring, and do a final compare when
> submitting the request. For correctness, we need to then sanitize how
> the reset_counter
Using `#include "drm.h"` instead of `#include ` allow drm
headers to be moved in another directory without changes, like for the
libdrm imports.
Signed-off-by: Gabriel Laskar
CC: Emil Velikov
CC: Mikko Rapeli
---
include/uapi/drm/i915_drm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
On Tue, Dec 01, 2015 at 09:31:31AM +0100, Daniel Vetter wrote:
> On Sun, Nov 29, 2015 at 08:48:02AM +, Chris Wilson wrote:
> > Instead of querying the reset counter before every access to the ring,
> > query it the first time we touch the ring, and do a final compare when
> > submitting the req
On Mon, Nov 30, 2015 at 04:23:45PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Somehow we accumulated a duplicated .get_display_clock_speed()
> assignment for PNV in
> commit 34edce2fea69 ("drm/i915: Add cdclk extraction for g33, g965gm and g4x")
>
> No real harm on hav
On Mon, Nov 30, 2015 at 05:18:43PM +, Chris Wilson wrote:
> On Mon, Nov 30, 2015 at 06:53:07PM +0200, Mika Kuoppala wrote:
> > We decay hangcheck score, instead of setting it to zero,
> > when seqno moves forward. This was added as mechanism to
> > detect batches full of invalid waits.
>
> And
On Tue, 24 Nov 2015, Daniel Vetter wrote:
> On Sat, Nov 21, 2015 at 02:01:55AM +0800, kbuild test robot wrote:
>> Hi Chris,
>>
>> [auto build test WARNING on drm-intel/for-linux-next]
>> [cannot apply to v4.4-rc1 next-20151120]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/Chris-Wil
On Thu, 26 Nov 2015, Chris Wilson wrote:
> On Thu, Nov 26, 2015 at 03:49:00PM +0100, Daniel Vetter wrote:
>> On Thu, Nov 26, 2015 at 01:31:42PM +, Chris Wilson wrote:
>> > We have relied upon the sole caller (wait_ioctl) validating the timeout
>> > argument. However, when waiting for multiple
On Mon, 23 Nov 2015, Maarten Lankhorst
wrote:
> Op 13-11-15 om 14:28 schreef Ander Conselvan De Oliveira:
>> On Thu, 2015-11-12 at 14:58 +0100, Maarten Lankhorst wrote:
>>> Op 12-11-15 om 14:37 schreef Ander Conselvan De Oliveira:
On Wed, 2015-11-11 at 15:36 +0100, Maarten Lankhorst wrote:
>
On Tue, Dec 01, 2015 at 09:28:08AM +0100, Daniel Vetter wrote:
> On Mon, Nov 30, 2015 at 10:11:12AM +, Chris Wilson wrote:
> > On Thu, Nov 26, 2015 at 12:34:34PM +0100, Daniel Vetter wrote:
> > > So there's 3 competing proposals for what wait_ioctl should do wrt
> > > -EIO:
> > >
> > > - retur
On Tue, Dec 01, 2015 at 09:04:23AM +, Chris Wilson wrote:
> On Tue, Dec 01, 2015 at 09:28:08AM +0100, Daniel Vetter wrote:
> > On Mon, Nov 30, 2015 at 10:11:12AM +, Chris Wilson wrote:
> > > On Thu, Nov 26, 2015 at 12:34:34PM +0100, Daniel Vetter wrote:
> > > > So there's 3 competing propos
On Tue, Dec 01, 2015 at 08:47:44AM +, Chris Wilson wrote:
> On Tue, Dec 01, 2015 at 09:31:31AM +0100, Daniel Vetter wrote:
> > On Sun, Nov 29, 2015 at 08:48:02AM +, Chris Wilson wrote:
> > > Instead of querying the reset counter before every access to the ring,
> > > query it the first time
On Tue, Dec 01, 2015 at 10:13:10AM +0100, Daniel Vetter wrote:
> On Tue, Dec 01, 2015 at 09:04:23AM +, Chris Wilson wrote:
> > On Tue, Dec 01, 2015 at 09:28:08AM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 30, 2015 at 10:11:12AM +, Chris Wilson wrote:
> > > > On Thu, Nov 26, 2015 at 12:34
On 1 December 2015 at 08:08, Daniel Vetter wrote:
> Two things:
> - Somehow the kernel's mode list changed with our EDID. No idea
> whether that's the right thing here since I'm not really an EDID
> expert. But then again the testcase wants to check that the
> injection works, not validate t
Disable DP fast link training if DP link configuration
changes. If one of the DP link parameters i.e. link
bandwidth, lane count, rate selection, port clock or bpp
changes the link training does no longer apply the
previously computed voltage swing and pre-emphasis values.
Instead, the link trainin
On Tue, Dec 01, 2015 at 10:11:14AM +, Thomas Wood wrote:
> On 1 December 2015 at 08:08, Daniel Vetter wrote:
> > Two things:
> > - Somehow the kernel's mode list changed with our EDID. No idea
> > whether that's the right thing here since I'm not really an EDID
> > expert. But then again t
Somehow the kernel's mode list changed with our EDID. No idea
whether that's the right thing here since I'm not really an EDID
expert. But then again the testcase wants to check that the
injection works, not validate the kernel's parser.
v2: Only check the preferred mode for more future-proofing (
Forcing connector state is a basic piece of our test infrastructure
that we use in all the kms_ tests. It allows us to run tests even if
no outputs are connected.
They're also really fast, so perfect candidates for inclusion into the
BAT set.
Signed-off-by: Daniel Vetter
---
tests/.gitignore
Speeds up testcases except for those where we want to exercise the
probing itself. The only exceptions left where we do a full probe are
- pm_rpm: We use it to make sure the kernel doesn't get things wrong
with power domains, so we really want to exercise the full probe
paths. And there the on
On 1 December 2015 at 10:24, Daniel Vetter wrote:
> Forcing connector state is a basic piece of our test infrastructure
> that we use in all the kms_ tests. It allows us to run tests even if
> no outputs are connected.
>
> They're also really fast, so perfect candidates for inclusion into the
> BA
Hi,
Just one comment deep down.
On 30/11/15 18:22, Vinay Belgaumkar wrote:
These tests exercise the userptr ioctl to create shared buffers
between CPU and GPU. They contain error and normal usage scenarios.
They also contain a couple of stress tests which copy buffers between
CPU and GPU. Thes
As the request is only valid during the same global reset epoch, we can
record the current reset_counter when constructing the request and reuse
it when waiting upon that request in future. This removes a very hairy
atomic check serialised by the struct_mutex at the time of waiting and
allows us to
Reporting -EIO from i915_wait_request() has proven very troublematic
over the years, with numerous hard-to-reproduce bugs cropping up in the
corner case of where a reset occurs and the code wasn't expecting such
an error.
If the we reset the GPU or have detected a hang and wish to reset the
GPU, t
This is just a little bit of syntatic sugar to hide the atomic_reads()
throughout the code to retrieve the current reset_counter. It also
provides the other utility functions to check the reset state on the
already read reset_counter, so that we can read it once and do multiple
tests rather than ri
On Tue, 01 Dec 2015, Daniel Vetter wrote:
> Somehow the kernel's mode list changed with our EDID.
I do not undestand what you're trying to say here.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@li
One particularly stressful scenario consists of many independent tasks
all competing for GPU time and waiting upon the results (e.g. realtime
transcoding of many, many streams). One bottleneck in particular is that
each client waits on its own results, but every client is woken up after
every batch
On 23/10/15 18:02, Tomas Elf wrote:
When clearing an execlist queue, instead of traversing it and unreferencing all
requests while holding the spinlock (which might lead to thread sleeping with
IRQs are turned off - bad news!), just move all requests to the retire request
list while holding spin
On 11/30/2015 1:45 PM, Daniel Vetter wrote:
On Mon, Nov 30, 2015 at 11:54:14AM +0530, Goel, Akash wrote:
On 11/25/2015 3:30 PM, Daniel Vetter wrote:
On Wed, Nov 25, 2015 at 02:57:47PM +0530, Goel, Akash wrote:
On 11/25/2015 2:51 PM, Daniel Vetter wrote:
On Tue, Nov 24, 2015 at 10:39:38P
Chris Wilson writes:
> On Mon, Nov 30, 2015 at 06:53:07PM +0200, Mika Kuoppala wrote:
>> We decay hangcheck score, instead of setting it to zero,
>> when seqno moves forward. This was added as mechanism to
>> detect batches full of invalid waits.
>
> And slow DoS. So no.
Point was to decay faste
On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Convert the MHz number coming from intel_rawclk() into Hz in
> i9xx_hz_to_pwm() on PNV. Otherwise we'll get something totally
> bogus as a result.
>
> Fixes: aa17cdb4f836 ("drm/i915: initialize backlight max from V
If head seems stuck and engine in question is rcs,
inspect subunit state transitions before deciding that
this really is a hang instead of limited progress.
References: https://bugs.freedesktop.org/show_bug.cgi?id=93029
Cc: Chris Wilson
Cc: Dave Gordon
Cc: Daniel Vetter
Signed-off-by: Mika Kuop
On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> CTG uses hrawclk for backlight, so calculate the max based on that
> instead of cdclk.
If you say so.
Acked-by: Jani Nikula
> Fixes: aa17cdb4f836 ("drm/i915: initialize backlight max from VBT")
> Signed-off-by:
On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We have HAS_PCH_LPT_LP() already, so add HAS_PCH_LPT_H() and use it
> where appropriate.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h| 1 +
> drivers/g
On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Somehow we accumulated a duplicated .get_display_clock_speed()
> assignment for PNV in
> commit 34edce2fea69 ("drm/i915: Add cdclk extraction for g33, g965gm and g4x")
>
> No real harm on having two, we just never
On Tue, 01 Dec 2015, Jani Nikula wrote:
> On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote:
>> From: Ville Syrjälä
>>
>> CTG uses hrawclk for backlight, so calculate the max based on that
>> instead of cdclk.
>
> If you say so.
>
> Acked-by: Jani Nikula
Okay, found it, promote that to
On Tue, Dec 01, 2015 at 02:21:37PM +0200, Jani Nikula wrote:
> On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > CTG uses hrawclk for backlight, so calculate the max based on that
> > instead of cdclk.
>
> If you say so.
Not me. Bspec says so.
>
> Acked-
On Tue, Dec 01, 2015 at 02:17:25PM +0200, Mika Kuoppala wrote:
> If head seems stuck and engine in question is rcs,
> inspect subunit state transitions before deciding that
> this really is a hang instead of limited progress.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=93029
> Cc:
On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Currently we round the AUX clock divider down on g4x, to closest
> on HSW/BDW port A, and up everywhere else. We are supposed to get
> as close to 2MHz as we can, so round to closest seems like the
> best option.
>
On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> No need to read out cdclk from the hardware, we have it already
> cached in dev_priv.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_panel.c | 4 ++--
> 1 file ch
On Mon, Nov 30, 2015 at 12:41:05PM +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> When the object is moved out of CPU read domain, the cachelines
> are not invalidated immediately. The invalidation is deferred till
> next time the object is brought back into CPU read domain.
> But the
On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> g4x is the first platform with DP support, so let's name the relevant
> functions as g4x_ instead i9xx_ to avoid confusion.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i9
In various places, one or more pages of a GEM object are mapped into CPU
address space and updated. In each such case, the object should be
marked dirty, to ensure that the modifications are not discarded if the
object is evicted under memory pressure.
This is similar to commit
commit 51bc
On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Generalize rawclk handling by storing it in dev_priv.
>
> Presumably our hrawclk readout works at least for CTG and ELK
> since we've been using it for DP AUX on those platforms. There
> are no real docs anymore af
On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> With the hrawclk frequency cached in dev_priv, we can simply use
> g4x_get_aux_clock_divider() for VLV/CHV.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dp.c |
On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Now that the mess with AUX clock divder rounding is sorted out and
> we have both cdclk and rawclk cached in dev_priv, we can clean up
> the .get_aux_clock_divider() functions a bit.
>
> The main thing here is just
On 01/12/2015 12:17, Mika Kuoppala wrote:
If head seems stuck and engine in question is rcs,
inspect subunit state transitions before deciding that
this really is a hang instead of limited progress.
References: https://bugs.freedesktop.org/show_bug.cgi?id=93029
Cc: Chris Wilson
Cc: Dave Gordon
Mika Kuoppala writes:
> If head seems stuck and engine in question is rcs,
> inspect subunit state transitions before deciding that
> this really is a hang instead of limited progress.
>
One thing to add into this description is that
now as we always have one extra hangcheck step even
in true st
On Tue, Dec 01, 2015 at 12:42:02PM +, Dave Gordon wrote:
> In various places, one or more pages of a GEM object are mapped into CPU
> address space and updated. In each such case, the object should be
> marked dirty, to ensure that the modifications are not discarded if the
> object is evicted
From: Ville Syrjälä
Unfortunatey there appear to quite a few HSW/BDW machines (eg.
NUCs, Brix Pro) in the wild with LPT/WPT-H but non-working FDI.
FDI training fails every single time on these machines. Dunno,
maybe they just didn't bother wiring it up or something?
Unfortunately all the fuse bi
From: Ville Syrjälä
While not techically needed on the last case in the switch statement,
the 'break' makes it look better IMO.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/driv
From: Ville Syrjälä
On HSW/BDW DDI A and E share 2 lanes, so when DDI A requires the
shared lanes DDI E can't be used. The lanes are not suppsoed to
be dynamically switched between the two uses, so there's no point
in registering the CRT connector when DDI E has no lanes.
Signed-off-by: Ville Sy
From: Ville Syrjälä
I was trying to get to the bottom of the FDI fails on Brix Pro, and
thus eneded up going through the entire PCH modeset stuff for HSW.
While I did find a bunch of stuff missing/wrong, sadly I wasn't able
to make FDI training succeed on that machine. So in the end I simply
had
From: Ville Syrjälä
When we want to use SPLL for FDI we want SSC, which means we have to
disable clock bending for the PCH SSC reference (bend and spread are
mtutually exclusive). So let's turn off bending when we want spread.
In case the BIOS enabled clock bending for some reason we'll just turn
From: Ville Syrjälä
LPT-H has a strap bit for fused off CRT block. Check it to see if
we should register the CRT connector or not. Supposedly this also
forces the ADAP enable bit to 0, so the detection we added in
commit 6c03a6bd0dd8 ("drm/i915: Don't register CRT connector when it's fused
off")
From: Ville Syrjälä
Extract the LPT-H VGA dotclock disable to a separate function in
anticipation of further use.
While at it move the sb_lock locking inwards when enabling the VGA
dotclock, as it's only needed to protect the sideband accesses.
Also toss out the PIXCLK_GATE_GATE nop define and
From: Ville Syrjälä
Bspec modeset sequence tells us to disable the PCH transcoder and
FDI after the CRT port on LPT-H, so let's do that.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers
From: Ville Syrjälä
Currently we disable some parts of FDI setup after a failed link
training. But despite that we continue with the modeset as if everything
is fine. This results in tons of noise from the state checker, and
it means we're not following the proper modeset sequence for the rest of
From: Ville Syrjälä
Bspec says we should round to closest when computong the LPT-H VGA
dotclock, so let's do that.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/d
From: Ville Syrjälä
Currently we leave the LPT-H VGA dotclock running after turning
the pipe/fdi/port/etc. Propoerly disable the VGA dotclock as
specified in the modeset sequence.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 insertion(+)
diff
On Tue, Dec 01, 2015 at 02:34:41PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 30, 2015 at 12:41:05PM +0530, akash.g...@intel.com wrote:
> > @@ -3982,7 +3983,21 @@ i915_gem_object_set_to_cpu_domain(struct
> > drm_i915_gem_object *obj, bool write)
> >
> > /* Flush the CPU cache if it's still in
On 01/12/15 13:04, Chris Wilson wrote:
On Tue, Dec 01, 2015 at 12:42:02PM +, Dave Gordon wrote:
In various places, one or more pages of a GEM object are mapped into CPU
address space and updated. In each such case, the object should be
marked dirty, to ensure that the modifications are not d
On Tue, Dec 01, 2015 at 02:47:41PM +0200, Jani Nikula wrote:
> On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Generalize rawclk handling by storing it in dev_priv.
> >
> > Presumably our hrawclk readout works at least for CTG and ELK
> > since we've been
On Tue, Dec 01, 2015 at 01:09:33PM +, Chris Wilson wrote:
> On Tue, Dec 01, 2015 at 02:34:41PM +0200, Ville Syrjälä wrote:
> > On Mon, Nov 30, 2015 at 12:41:05PM +0530, akash.g...@intel.com wrote:
> > > @@ -3982,7 +3983,21 @@ i915_gem_object_set_to_cpu_domain(struct
> > > drm_i915_gem_object *
On Tue, Dec 01, 2015 at 01:12:43PM +0200, Jani Nikula wrote:
> On Tue, 01 Dec 2015, Daniel Vetter wrote:
> > Somehow the kernel's mode list changed with our EDID.
>
> I do not undestand what you're trying to say here.
The EDID we injected stayed the same, but the kernel started listing more
mode
On Tue, Dec 01, 2015 at 10:33:22AM +, Thomas Wood wrote:
> On 1 December 2015 at 10:24, Daniel Vetter wrote:
> > Forcing connector state is a basic piece of our test infrastructure
> > that we use in all the kms_ tests. It allows us to run tests even if
> > no outputs are connected.
> >
> > Th
On Tue, Dec 01, 2015 at 03:08:34PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Unfortunatey there appear to quite a few HSW/BDW machines (eg.
> NUCs, Brix Pro) in the wild with LPT/WPT-H but non-working FDI.
> FDI training fails every single time on these machines. Dunno
On Tue, Dec 01, 2015 at 03:28:28PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 01, 2015 at 01:09:33PM +, Chris Wilson wrote:
> > On Tue, Dec 01, 2015 at 02:34:41PM +0200, Ville Syrjälä wrote:
> > > On Mon, Nov 30, 2015 at 12:41:05PM +0530, akash.g...@intel.com wrote:
> > > > @@ -3982,7 +3983,21 @
On ma, 2015-11-30 at 16:23 -0800, Bob Paauwe wrote:
> Since commit
>
> commit aed242ff7ebb697e4dff912bd4dc7ec7192f7581
> Author: Chris Wilson
> Date: Wed Mar 18 09:48:21 2015 +
>
> drm/i915: Relax RPS contraints to allows setting minfreq on
> idle
>
> it is now possible that t
On ma, 2015-11-30 at 16:23 -0800, Bob Paauwe wrote:
> Now that the frequency can drop below the user specified minimum when
> the gpu is idle, add some checking to verify that it really does drop
> down to the RPn frequency in specific cases.
>
> To do this, modify the main test flow to take two '
On Tue, Dec 01, 2015 at 01:41:49PM +, Chris Wilson wrote:
> On Tue, Dec 01, 2015 at 03:08:34PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Unfortunatey there appear to quite a few HSW/BDW machines (eg.
> > NUCs, Brix Pro) in the wild with LPT/WPT-H but non-work
On Tue, Dec 01, 2015 at 01:49:10PM +, Chris Wilson wrote:
> On Tue, Dec 01, 2015 at 03:28:28PM +0200, Ville Syrjälä wrote:
> > On Tue, Dec 01, 2015 at 01:09:33PM +, Chris Wilson wrote:
> > > On Tue, Dec 01, 2015 at 02:34:41PM +0200, Ville Syrjälä wrote:
> > > > On Mon, Nov 30, 2015 at 12:41
On Tue, Dec 01, 2015 at 03:57:37PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 01, 2015 at 01:41:49PM +, Chris Wilson wrote:
> > On Tue, Dec 01, 2015 at 03:08:34PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Unfortunatey there appear to quite a few HSW
On Mon, Nov 30, 2015 at 09:26:42AM +0100, Daniel Vetter wrote:
> On Thu, Nov 26, 2015 at 06:27:07PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > The .get_config() hooks should not reference anything in crtc->config,
> > everything should be based on the passed in pi
On Thu, Nov 26, 2015 at 09:40:26AM +0100, Daniel Vetter wrote:
> On Wed, Nov 25, 2015 at 04:35:30PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > ironlake_crtc_compute_clock() gets called during atomic compute phase,
> > so we must check the future pipe type instead
On Thu, Nov 26, 2015 at 01:42:10PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 26, 2015 at 09:41:36AM +0100, Daniel Vetter wrote:
> > On Wed, Nov 25, 2015 at 04:35:31PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > DPLL_SDVO_HIGH_SPEED must be set for SDVO/H
On Tue, Dec 01, 2015 at 02:06:26PM +, Chris Wilson wrote:
> On Tue, Dec 01, 2015 at 03:57:37PM +0200, Ville Syrjälä wrote:
> > On Tue, Dec 01, 2015 at 01:41:49PM +, Chris Wilson wrote:
> > > On Tue, Dec 01, 2015 at 03:08:34PM +0200, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From:
Daniel,
LGTM, except one comment below:
On 12/01/2015 08:45 AM, Daniel Vetter wrote:
> Tests that master state isn't leaked to new masters by checking
> that auth magics for the old master don't work any more.
>
> Based upon a simple test program provided by Thomas.
>
> v2: Use correct test stanz
Shorter, easier to follow code with no functional changes. In all cases,
the return value ultimately comes from gmbus_wait_hw_status() anyway.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_i2c.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/
Choose between i2c bit banging and gmbus in a new higher level function,
and let the i2c core retry the first time we fall back to bit banging.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_i2c.c | 39 +--
1 file changed, 25 insertions(+), 14 delet
Use the first retired request on a new context to unpin
the old context. This ensures that the hw context remains
bound until it has been written back to by the GPU.
Now that the context is pinned until later in the request/context
lifecycle, it no longer needs to be pinned from context_queue to
re
On Tue, Dec 01, 2015 at 04:29:25PM +0200, Jani Nikula wrote:
> Shorter, easier to follow code with no functional changes. In all cases,
> the return value ultimately comes from gmbus_wait_hw_status() anyway.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_i2c.c | 12 ---
On Tue, Dec 01, 2015 at 04:29:26PM +0200, Jani Nikula wrote:
> Choose between i2c bit banging and gmbus in a new higher level function,
> and let the i2c core retry the first time we fall back to bit banging.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_i2c.c | 39 ++
On 12/1/2015 7:30 PM, Ville Syrjälä wrote:
On Tue, Dec 01, 2015 at 01:49:10PM +, Chris Wilson wrote:
On Tue, Dec 01, 2015 at 03:28:28PM +0200, Ville Syrjälä wrote:
On Tue, Dec 01, 2015 at 01:09:33PM +, Chris Wilson wrote:
On Tue, Dec 01, 2015 at 02:34:41PM +0200, Ville Syrjälä wrote:
A forced EDID read takes 22.5ms best-case, and that's per 128byte
block. HDMI screens tend to have 2-3 of those. Mutliply that by a few
outputs and then it's clear that userspace really never ever should
re-probe connector state on its own and trust the kernel to tell it
when anything changed. The
Some sources of significant amounts of latency aren't simple sleeps
but instead busy-loops or a series of hundreds of small sleeps simply
because the hardware can't do better. Unfortunately latencytop doesn't
register these and so they slip under the radar. Hence expose a
simplified interface to re
On Tue, 01 Dec 2015, Ville Syrjälä wrote:
> On Tue, Dec 01, 2015 at 04:29:26PM +0200, Jani Nikula wrote:
>> Choose between i2c bit banging and gmbus in a new higher level function,
>> and let the i2c core retry the first time we fall back to bit banging.
>>
>> Signed-off-by: Jani Nikula
>> ---
>
On Tue, 01 Dec 2015, Ville Syrjälä wrote:
> On Tue, Dec 01, 2015 at 02:47:41PM +0200, Jani Nikula wrote:
>> On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote:
>> > From: Ville Syrjälä
>> >
>> > Generalize rawclk handling by storing it in dev_priv.
>> >
>> > Presumably our hrawclk readout w
On 30/11/15 10:06, Tvrtko Ursulin wrote:
On 29/11/15 08:48, Chris Wilson wrote:
Limit busywaiting only to the request currently being processed by the
GPU. If the request is not currently being processed by the GPU, there
is a very low likelihood of it being completed within the 2 microsecond
s
On Tue, Dec 01, 2015 at 04:29:27PM +0100, Daniel Vetter wrote:
> Some sources of significant amounts of latency aren't simple sleeps
> but instead busy-loops or a series of hundreds of small sleeps simply
> because the hardware can't do better. Unfortunately latencytop doesn't
> register these and
On Tue, Dec 01, 2015 at 05:38:30PM +0200, Jani Nikula wrote:
> On Tue, 01 Dec 2015, Ville Syrjälä wrote:
> > On Tue, Dec 01, 2015 at 04:29:26PM +0200, Jani Nikula wrote:
> >> Choose between i2c bit banging and gmbus in a new higher level function,
> >> and let the i2c core retry the first time we
1 - 100 of 171 matches
Mail list logo
