On Tue, 2013-12-10 at 09:04 -0800, Kenneth Graunke wrote:
> On 12/10/2013 03:40 AM, Damien Lespiau wrote:
> > On Mon, Dec 09, 2013 at 11:29:35PM -0800, Kenneth Graunke wrote:
> >> We don't want depth/stencil fast clears or HiZ resolves; we want normal
> >> drawing. Without this, the pixel pipelin
[snip]
On Tue, Nov 26, 2013 at 11:35:38AM -0800, Daniel Vetter wrote:
> > 2) Coherency. I've found two types of coherency issues when reading the
> > batch
> >buffer from the CPU during execbuffer2. Looking for help with both
> > issues.
> > i. First, the i-g-t test gem_cpu_reloc blits t
On Tue, Dec 10, 2013 at 11:47:17AM -0800, Ben Widawsky wrote:
> On Tue, Dec 10, 2013 at 03:24:52PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Not all registers need forcewake even if they're not shadowed.
> > Add the missing NEEDS_FORCE_WAKE() check to gen8_writeX
On Fri, Dec 06, 2013 at 05:32:43PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The eDP spec defines some points where after you do action A, you have
> to wait some time before action B. The thing is that in our driver
> action B does not happen exactly after action A, but we still use
>
On Fri, 6 Dec 2013 17:32:44 -0200
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Our driver has two different ways of waiting for panel power
> sequencing delays. One of these ways is through
> ironlake_wait_panel_status, which implicitly uses the values written
> to our registers. The other way
On Mon, Dec 02, 2013 at 11:37:30AM -0200, Rodrigo Vivi wrote:
> On Thu, Nov 21, 2013 at 1:47 PM, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > The code to enable/disable PC8 already takes care of saving and
> > restoring all the registers we need to save/restore, so do a put()
> > call when
On Thu, Nov 21, 2013 at 01:47:28PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The code to enable/disable PC8 already takes care of saving and
> restoring all the registers we need to save/restore, so do a put()
> call when we enable PC8 and a get() call when we disable it.
>
> Ideally,
On Thu, Nov 21, 2013 at 01:47:26PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> So we'll get a fault when someone tries to access the mmap, then we'll
> wake up from D3.
>
> This fixes the gem-mmap-gtt subtest from pm_pc8 from intel-gpu-tools.
>
> Signed-off-by: Paulo Zanoni
> ---
> dr
On Thu, Nov 21, 2013 at 01:47:25PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The plan is to merge PC8 and D3 into a single feature, and when we're
> in D3 we won't get any hotplug interrupt anyway, so leaving them
> enable doesn't make sense, and it also brings us a problem. The
> probl
On Thu, Nov 21, 2013 at 01:47:24PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The current code was checking if all bits of "val" were enabled and
> DE_PCH_EVENT_IVB was disabled. The new code doesn't care about the
> state of DE_PCH_EVENT_IVB: it just checks if everything else is 1.
>
>
On Fri, Nov 29, 2013 at 11:03:38AM -0200, Rodrigo Vivi wrote:
> On Wed, Nov 27, 2013 at 06:20:34PM -0200, Paulo Zanoni wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 2715600..70c4cef 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b
On Wed, Nov 27, 2013 at 05:59:22PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> In the current code, at haswell_modeset_global_resources, first we
> decide if we want to enable/disable the power well, then we decide if
> we want to enable/disable PC8. On the case where we're enabling PC8
>
Hello,
The dmesg for the boot is this:
http://pastebin.com/aXJQiprL
The dmesg when the flashing started to occur:
http://pastebin.com/GkRcpK80
I kept the config a simple as possible. No bumblebee, just LVDS1 and DP1
without adaptors.
my Xorg.0.log is this:
http://pastebin.com/2vK37TNr
Than
On Tue, Dec 10, 2013 at 03:24:52PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Not all registers need forcewake even if they're not shadowed.
> Add the missing NEEDS_FORCE_WAKE() check to gen8_writeX() to
> avoid needless forcewake usage when writing eg. display
> regist
From: Ville Syrjälä
Every ring seems to have a BB_ADDR registers, so include them all in the
error state.
v2: Also include the _UDW on BDW
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 12 ++--
drivers/gpu/drm/i
On Tue, Dec 10, 2013 at 08:47:45PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Every ring seems to have a BB_ADDR registers, so include them all in the
> error state.
>
> Signed-off-by: Ville Syrjälä
Both are:
Reviewed-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/
On Tue, Dec 10, 2013 at 10:52:54AM -0800, Jesse Barnes wrote:
> On Tue, 10 Dec 2013 14:06:45 +0200
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > The CRI clock is related to the display PHY, so the setup belongs
> > in intel_init_dpio().
> >
> > Signed-off-by: Ville Sy
On Tue, 10 Dec 2013 14:06:45 +0200
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The CRI clock is related to the display PHY, so the setup belongs
> in intel_init_dpio().
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 11 ---
> 1 file
From: Ville Syrjälä
Every ring seems to have a BB_ADDR registers, so include them all in the
error state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 10 --
drivers/gpu/drm/i915/i915_reg.h | 2 +-
3 file
From: Ville Syrjälä
The BB_ADDR register is documented to be 32bits at least since SNB.
Prior to that the high 32bits were listed as MBZ, so using a 64bit read
doesn't seem worth anything. Also the simulator doesn't like the 64bit
read. So just switch to using a 32bit read instead.
Signed-off-by
On Tue, Dec 10, 2013 at 06:22:36PM +, Mateo Lozano, Oscar wrote:
> > > This test hasn't been terribly effective at provoking the bug it tries
> > > to hit, so I think we can just unconditionally use the lower limit.
> > > That also helps with the really long runtime of this case a bit.
> > > -D
> > This test hasn't been terribly effective at provoking the bug it tries
> > to hit, so I think we can just unconditionally use the lower limit.
> > That also helps with the really long runtime of this case a bit.
> > -Daniel
Understood. I´ll simplify the patch and send it again then.
> FWIW,
On Tue, Dec 10, 2013 at 01:32:13PM +0100, Daniel Vetter wrote:
> On Tue, Dec 10, 2013 at 09:36:22AM +, oscar.ma...@intel.com wrote:
> > From: Oscar Mateo
> >
> > With Full PPGTT, each new fd creates a new context and thus a new
> > PPGTT, so we have to reduce the number of simultaneous fds or
On 12/10/2013 03:40 AM, Damien Lespiau wrote:
> On Mon, Dec 09, 2013 at 11:29:35PM -0800, Kenneth Graunke wrote:
>> We don't want depth/stencil fast clears or HiZ resolves; we want normal
>> drawing. Without this, the pixel pipeline doesn't work.
>>
>> Signed-off-by: Kenneth Graunke
>> Cc: Ben Wi
Hi,
I have recently observed a NULL pointer dereference in i915 driver on my
Eee PC running ROSA Linux with kernel 3.10.21.
The crash occurs during shutdown but quite rarely, not each time.
The system log is lost but here is what I extracted from the info
displayed on the screen.
NULL poin
On 12/10/2013 04:23 PM, Daniel Vetter wrote:
On Tue, Dec 10, 2013 at 12:27:55PM +0400, Eugene Shatokhin wrote:
Hi,
I have recently observed a NULL pointer dereference in i915 driver
on my Eee PC running ROSA Linux with kernel 3.10.21.
The crash occurs during shutdown but quite rarely, not each
We faced some issue for not following the sequence.
I will add proper commit message and send it for review.
-Deepak
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, December 9, 2013 10:49 PM
To: S, Deepak
Cc: Daniel Vette
From: Jesse Barnes
commit acbec814a27f233b5ddb88a1bcaa2ac20daf64e0 upstream.
Calculation is a little different than other platforms.
v2: update to use port_clock instead
rebase on top of Ville's changes
v3: update to new port_clock semantics - don't divide by
pixel_multiplier (Ville)
R
Hi stable team,
Here's a backport of the following upstream commits for 3.12:
commit 662c6ecbcdca1fe8a5402f6c83d98d242917a043
Author: Chris Wilson
Date: Wed Sep 25 14:24:01 2013 -0700
drm/i915/vlv: fix up broken precision in vlv_crtc_clock_get
commit acbec814a27f233b5ddb88a1bcaa2ac20daf6
From: Chris Wilson
commit 662c6ecbcdca1fe8a5402f6c83d98d242917a043 upstream.
With some divider values we end up with the wrong result. So remove the
intermediates (like Ville suggested in the first place) to get the right
answer.
Signed-off-by: Chris Wilson
Signed-off-by: Jesse Barnes
Signed
From: Jesse Barnes
commit f60711666bcab6df2c6c91d851e07ed54088453c upstream.
The global integrated clock source bit resides in DPLL B on VLV, but we
were treating it as a per-pipe resource. It needs to be set whenever
any PLL is active, so pull setting the bit out of vlv_update_pll and
into vlv
Commit 094f9a54e355 ("drm/i915: Fix __wait_seqno to use true infinite
timeouts") added support for __wait_seqno to detect missing interrupts and
go around them by polling. As there is also timeout detection in
__wait_seqno, the polling and timeout detection were done with the same
timer.
When ther
On Tue, Dec 10, 2013 at 10:50:48AM +0200, Mika Kuoppala wrote:
> Use own copy of gem_quiescent_gpu() so that test still works
> if it gets changed. Further improve the test by posting a batch
> to rings in reverse order.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Mika Kuoppala
Applied, th
On Tue, Dec 10, 2013 at 03:19:08PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We don't modify the packed infoframe data, so we should keep the
> const qualifier in place. Just pass the buffer as 'const void *'
> instead of 'const uint8_t *' and we can drop the cast enti
On Tue, Dec 10, 2013 at 12:44:12PM +, Chris Wilson wrote:
> On Tue, Dec 10, 2013 at 01:24:01PM +0100, Daniel Vetter wrote:
> > The update is horribly racy since it doesn't protect at all against
> > concurrent closing of the master fd. And it can't really since that
> > requires us to grab a mu
From: Ville Syrjälä
Not all registers need forcewake even if they're not shadowed.
Add the missing NEEDS_FORCE_WAKE() check to gen8_writeX() to
avoid needless forcewake usage when writing eg. display
registers.
Signed-off-by: Ville Syrjälä
---
I didn't test this at all, so be warned.
drivers/
From: Ville Syrjälä
We don't modify the packed infoframe data, so we should keep the
const qualifier in place. Just pass the buffer as 'const void *'
instead of 'const uint8_t *' and we can drop the cast entirely.
v2: Do intel_sdvo_write_infoframe() as well
Reviewed-by: Damien Lespiau
Signed-o
On Tue, Dec 10, 2013 at 01:33:01PM +0100, Bruno Prémont wrote:
> Hi Ville,
>
> On Tue, 10 December 2013 Ville Syrjälä wrote:
> > On Tue, Dec 10, 2013 at 12:52:27PM +0100, Bruno Prémont wrote:
> > > On Mon, 09 December 2013 Ville Syrjälä wrote:
> > > > There appear to be some gen2 machines that don
On Tue, Dec 10, 2013 at 01:24:01PM +0100, Daniel Vetter wrote:
> The update is horribly racy since it doesn't protect at all against
> concurrent closing of the master fd. And it can't really since that
> requires us to grab a mutex.
>
> Instead of jumping through hoops and offloading this to a wo
Hi Ville,
On Tue, 10 December 2013 Ville Syrjälä wrote:
> On Tue, Dec 10, 2013 at 12:52:27PM +0100, Bruno Prémont wrote:
> > On Mon, 09 December 2013 Ville Syrjälä wrote:
> > > There appear to be some gen2 machines that don't really like the current
> > > PLL
> > > limits we have. We also have so
On Tue, Dec 10, 2013 at 09:36:22AM +, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> With Full PPGTT, each new fd creates a new context and thus a new
> PPGTT, so we have to reduce the number of simultaneous fds or face
> OOM problems. For every new PPGTT, its PDEs are stored in the GGT
On Tue, Dec 10, 2013 at 12:36:34PM +0200, Jani Nikula wrote:
> On Tue, 10 Dec 2013, Vandana Kannan wrote:
> > If one mode of a internal panel has more than one refresh rate, then a
> > reduced
> > clock is found for the LFP (LVDS/eDP). This enables switching between low
> > and high frequency dyn
On Tue, Dec 10, 2013 at 02:06:30PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We don't modify the packed infoframe data, so we should keep the
> const qualifier in place. Just pass the buffer as 'const void *'
> instead of 'const uint8_t *' and we can drop the cast enti
On Tue, Dec 10, 2013 at 12:27:55PM +0400, Eugene Shatokhin wrote:
> Hi,
>
> I have recently observed a NULL pointer dereference in i915 driver
> on my Eee PC running ROSA Linux with kernel 3.10.21.
>
> The crash occurs during shutdown but quite rarely, not each time.
>
> The system log is lost b
The update is horribly racy since it doesn't protect at all against
concurrent closing of the master fd. And it can't really since that
requires us to grab a mutex.
Instead of jumping through hoops and offloading this to a worker
thread just block this bit of code for the modesetting driver.
Repo
On Tue, Dec 10, 2013 at 12:52:27PM +0100, Bruno Prémont wrote:
> Hi Ville,
>
> On Mon, 09 December 2013 ville.syrj...@linux.intel.com wrote:
> > There appear to be some gen2 machines that don't really like the current PLL
> > limits we have. We also have some accuracy problems with the PLL
> > ca
On Tue, Dec 10, 2013 at 10:35:13AM +0200, Mika Kuoppala wrote:
> Commit 094f9a54e355 ("drm/i915: Fix __wait_seqno to use true infinite
> timeouts") added support for __wait_seqno to detect missing interrupts and
> go around them by polling. As there is also timeout detection in
> __wait_seqno, the
From: Ville Syrjälä
The CRI clock is related to the display PHY, so the setup belongs
in intel_init_dpio().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
From: Ville Syrjälä
We don't modify the packed infoframe data, so we should keep the
const qualifier in place. Just pass the buffer as 'const void *'
instead of 'const uint8_t *' and we can drop the cast entirely.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_drv.h | 2 +-
driv
Hi Ville,
On Mon, 09 December 2013 ville.syrj...@linux.intel.com wrote:
> There appear to be some gen2 machines that don't really like the current PLL
> limits we have. We also have some accuracy problems with the PLL calculations.
> This series aims to eliminate those problems, and at least my 85
On Mon, Dec 09, 2013 at 11:29:35PM -0800, Kenneth Graunke wrote:
> We don't want depth/stencil fast clears or HiZ resolves; we want normal
> drawing. Without this, the pixel pipeline doesn't work.
>
> Signed-off-by: Kenneth Graunke
> Cc: Ben Widawsky
> Cc: Damien Lespiau
Both patches reviewed
On Mon, 09 Dec 2013, zaverel wrote:
> is it normal that if I rule the brightness with xrandr, only the value
> of gamma change and not the brightness ?
>
> display actually becomes much clearer but this is due to gamma or
> brightness ?
> That is the question.
Quoting xrandr(1) man page:
On Mon, 09 Dec 2013, Raul Dias wrote:
> Hello,
>
> I have a Dell L502x which have a optimus Graphic Pack:
>
> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
> Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA
> controller])
> Subsystem: Del
On Tue, 10 Dec 2013, Vandana Kannan wrote:
> If one mode of a internal panel has more than one refresh rate, then a reduced
> clock is found for the LFP (LVDS/eDP). This enables switching between low
> and high frequency dynamically. Moving downclock calculation to intel_panel
> so that it is comm
On Sat, Dec 7, 2013 at 8:36 PM, Ben Widawsky wrote:
>> Yeah, this is definitely very useful. But I'd just print it by default
>> so that we don't need to ask for this information. Of course we need
>> to be careful to not print it when listing subtest. Also:
>> - We don't have any init stuff for s
Hi Ville,
On VLV, we do get the interrupts when we should not. That is when we already
in max_delay we get the up threshold interrupts
Thanks
Deepak
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Monday, December 9, 2013 3:42 PM
To: S, Deepak
Cc: i
From: Oscar Mateo
These tests cover some tricky corner cases found during
the True-and-only Full PPGTT feature development.
v2: Add pthread requirement to Makefile.
v3: Added new "pinned" testcase.
v4: Require Full PPGTT.
Signed-off-by: Oscar Mateo
---
tests/.gitignore |1 +
tests/M
From: Oscar Mateo
With Full PPGTT, each new fd creates a new context and thus a new
PPGTT, so we have to reduce the number of simultaneous fds or face
OOM problems. For every new PPGTT, its PDEs are stored in the GGTT
which imposes a limit of 1024 new contexts. We want to leave at
least 1/4 of th
From: Oscar Mateo
Signed-off-by: Oscar Mateo
---
lib/drmtest.c | 14 ++
lib/drmtest.h |1 +
2 files changed, 15 insertions(+)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index f2624a1..c2483ee 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -87,6 +87,20 @@ is_intel(int fd)
Use own copy of gem_quiescent_gpu() so that test still works
if it gets changed. Further improve the test by posting a batch
to rings in reverse order.
Suggested-by: Daniel Vetter
Signed-off-by: Mika Kuoppala
---
tests/gem_reset_stats.c | 84 +++
1
Commit 094f9a54e355 ("drm/i915: Fix __wait_seqno to use true infinite
timeouts") added support for __wait_seqno to detect missing interrupts and
go around them by polling. As there is also timeout detection in
__wait_seqno, the polling and timeout detection were done with the same
timer.
When ther
If one mode of a internal panel has more than one refresh rate, then a reduced
clock is found for the LFP (LVDS/eDP). This enables switching between low
and high frequency dynamically. Moving downclock calculation to intel_panel
so that it is common for LVDS and eDP.
Signed-off-by: Vandana Kannan
62 matches
Mail list logo
