For DDR data rate reporting by Punit in PUNIT_GPU_FREQ_STS, the actual
data encoding is 00b=800, 01b=1066, 10b=1333, 11b=1333.
Some premium VLV sku will get the DDR_DATA_RATE set as 11. As a result,
the turbo frequency reporting will be incorrect without this workaround.
Signed-off-by: Chon Ming
The max frequency reporting is not correct. But there is already an existing
valleyview_rps_max_freq and valleyview_rps_min_freq to get the
frequency. Use that for i915_cur_delayinfo.
Signed-off-by: Chon Ming Lee
---
drivers/gpu/drm/i915/i915_debugfs.c |4 ++--
1 files changed, 2 insertion
This test assumes that using gem_pin will pin in the same address space
used by execbuf. Since pin is for the global GTT only, use the existing
flag to notify i915.ko that the exec object is special.
Cc: Chris Wilson
Signed-off-by: Ben Widawsky
---
tests/gem_pin.c | 4 +++-
1 file changed, 3 in
On 11/05/2013 08:05 PM, Chen Gang wrote:
> On 11/05/2013 07:11 PM, David Howells wrote:
>> Chen Gang wrote:
>>
Userspace sometimes depends on the name in the guard macro:-/
>>>
>>> "the guard macro" is only for prevent itself from being included by
>>> multiple times (an id used by itself --
Some VLV PHY/PLL DPIO registers have group/lane/channel access. Current
DPIO register definition doesn't have a structure way to break them
down. As a result it is not easy to match the PHY/PLL registers with the
configdb document. Rename those registers based on the configdb for easy
cross refer
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_panel.c between commit 5bdebb183c97
("drm/sysfs: sort out minor and connector device object lifetimes") from
the drm tree and commit 752aa88a1e78 ("drm/i915: make backlight functions
take a connecto
On 11/06 14:02, Ville Syrjälä wrote:
> > -#define _DPIO_IREF_CTL_A 0x8040
> > -#define _DPIO_IREF_CTL_B 0x8060
> > -#define DPIO_IREF_CTL(pipe) _PIPE(pipe, _DPIO_IREF_CTL_A, _DPIO_IREF_CTL_B)
> > +#define _VLV_PLL_DW10_CH0 0x8040
> > +#define _VLV_PLL_DW10_CH1
Ben Widawsky writes:
> From: Damien Lespiau
>
> The command now takes a 48bits address and is thus 1 byte longer.
I think you mean "1 dword"
Other than that, patches 2-5 are
Reviewed-by: Eric Anholt
(patch 1, I don't know anything about the set of PCI IDs so I've skipped
it).
pgpQrR6AoDlr
From: Ville Syrjälä
No longer needed since the LRIs do the work.
v2: Rebased due to hunk getting dropped from an ealier patch
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel
From: Ville Syrjälä
At least since SNB (perhaps even earlier) even the desktop parts
should have FBC.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i91
From: Ville Syrjälä
All the other .enable_fbc() funcs use plane_name(). Make
gen7_enable_fbc() do the same.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i91
From: Ville Syrjälä
We use LRIs to enable/disable the render tracking as needed. So leave
ILK_FBC_RT_BASE alone when enabling FBC on SNB.
While at it, kill the IVB_FBC_RT_BASE completely since we don't use
render tracking on IVB+.
TODO: Make ILK use the LRI mechanism too?
v2: Drop the IVB_FBC_
From: Ville Syrjälä
Don't issue the FBC nuke/cache clean command when invalidate_domains!=0.
That would indicate that we're not being called for the post-batch
flush.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
From: Ville Syrjälä
As per the SNB and HSW PM guides, we should enable FBC render/blitter
tracking only during batches targetting the front buffer.
On SNB we must also update the FBC render tracking address whenever it
changes. And since the register in question is stored in the context,
we need
From: Ville Syrjälä
Make the FBC code a bit less racy by grabbing crtc->mutex
in intel_fbc_work_fn() when we go digging through the crtc
state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_p
From: Ville Syrjälä
The spec tells us that we need to emit an SRM after the LRI
to MSG_FBC_REND_STATE.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 6 --
2 files changed, 5 insertions(+), 2 deletions(-)
diff --gi
From: Ville Syrjälä
In order to do the FBC tracking properly for execbuffer, we need to
figure out if the object being rendered to is the current front buffer.
However in order to do that purely based on the crtc, we'd need to
grab crtc->mutex, but we can't since we're already holding struct_mute
From: Ville Syrjälä
We need some protection for the FBC state, and since struct_mutex
is it currently in most places, make sure all FBC update/disable
calles are protected by it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 10 insertion
One more attempt at making FBC suck a bit less.
The main thing as before is getting the LRI based render/blitter
tracking in place.
In this updates series I decided the way to avoid the kms locks in
execbuffer is to keep an extra reference to the fb.
I added a bunch of locking (struct_mutex and
>> Thank you, here's what I get:
>>
>> # addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79
>> 0x3037f
>
> Grant - I'm assuming that this was done on the emerged
> xf86-video-intel, not the git-compiled one?
Yes, that is correct. I emerged the git-compiled one t
2013/10/28 Imre Deak :
> On Tue, 2013-10-22 at 17:30 -0200, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> This patch adds the initial infrastructure to allow a Runtime PM
>> implementation that sets the device to its D3 state. The patch just
>> adds the necessary callbacks and the initial infras
2013/11/4 Ville Syrjälä :
> On Mon, Oct 28, 2013 at 03:27:39PM +0200, Imre Deak wrote:
>> On Tue, 2013-10-22 at 17:30 -0200, Paulo Zanoni wrote:
>> > From: Paulo Zanoni
>> >
>> > And leave it off by default. We have way too many driver entry points,
>> > we can't assume this will work without regr
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 06 Nov 2013 19:12:29 + bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=64521
>
> Bug ID: 64521
>Summary: BUG kmalloc-4
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Wednesday, November 06, 2013 6:52 PM
> To: Barbalho, Rafael
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] tests/gem_reloc_overflow: Add gen8+
> specif
On Tue, 2013-11-05 at 20:38 +, Mcgee, Jeff wrote:
> On Mon, 2013-11-04 at 09:44 +0100, Daniel Vetter wrote:
> > On Thu, Oct 31, 2013 at 8:52 PM, wrote:
> > > From: Jeff McGee
> > >
> > > A check of rps/rc6 state after i915_reset determined that the ring
> > > MAX_IDLE registers were returned
On 06.11.2013 11:34, Daniel Vetter wrote:
}
To clarify: Do you need this patch to make the single-pipe mode work
reliably? It's a bit unclear in your answer ...
Well, from what I can tell, I haven't seen the above warning since, but
it was neither easily reproducable. "Working reliable" is
On Wed, Nov 6, 2013 at 10:48 AM, Grant wrote:
> Thank you, here's what I get:
>
> # addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79
> 0x3037f
Grant - I'm assuming that this was done on the emerged
xf86-video-intel, not the git-compiled one?
> /var/tmp/p
Retrieve current framebuffer config info from the regs and create an fb
object for the buffer the BIOS or boot loader left us. This should
allow for smooth transitions to userspace apps once we finish the
initial configuration construction.
v2: check for non-native modes and adjust (Jesse)
fi
On 11/06/2013 09:15 AM, Ben Widawsky wrote:
> Nothing special here... I'm fine with not pushing any of the AUB stuff if
> anyone has issues.
>
> Ben Widawsky (2):
> intel/bdw: Add broadwell chipset IDs
> intel/bdw: Handle gen8 bufmgr_init
>
> Damien Lespiau (2):
> intel/bdw: Add gen8 to the
There was a TODO from last time that Daniel and I talked about:
- reconstruct fb state in our get_config callbacks instead
- reconstruct per-crtc fb state and allocate separate buffers if
needed
- make sure we only preserve the buffer if it's the preferred mode
Just wanted to get this re
On Wed, Nov 06, 2013 at 06:12:12PM +, rafael.barba...@intel.com wrote:
> From: Rafael Barbalho
>
> Broadwell introduces 64-bit relocation addresses which add extra
> corner cases. The test was refactored slightly with some tests that
> were in the source offset tests were moved to the more ge
Thank you, here's what I get:
# addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79
0x3037f
/var/tmp/portage/x11-drivers/xf86-video-intel-2.99.905-r1/work/xf86-video-intel-2.99.905/src/sna/sna_accel.c:6079
/var/tmp/portage/x11-drivers/xf86-video-intel
On Wed, Nov 6, 2013 at 10:17 AM, Grant wrote:
>>> Thank you, here's what I get:
>>>
>>> # addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79
>>> 0x3037f
>>> /var/tmp/portage/x11-drivers/xf86-video-intel-2.99.905-r1/work/xf86-video-intel-2.99.905/src/sna/sna_accel.c:6079
>>> /var
>> Thank you, here's what I get:
>>
>> # addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79
>> 0x3037f
>> /var/tmp/portage/x11-drivers/xf86-video-intel-2.99.905-r1/work/xf86-video-intel-2.99.905/src/sna/sna_accel.c:6079
>> /var/tmp/portage/x11-drivers/xf86-video-intel-2.99.905-r1
From: Rafael Barbalho
Broadwell introduces 64-bit relocation addresses which add extra
corner cases. The test was refactored slightly with some tests that
were in the source offset tests were moved to the more generic reloc
test area. The source offset tests are now gen aware and called twice to
On Wed, Nov 06, 2013 at 10:08:18AM -0800, Grant wrote:
> Thank you, here's what I get:
>
> # addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79 0x3037f
> /var/tmp/portage/x11-drivers/xf86-video-intel-2.99.905-r1/work/xf86-video-intel-2.99.905/src/sna/sna_accel.c:6079
> /var/tmp/p
>> > I'm getting the following segfault intermittently when using sna.
>> > I've tried xf86-video-intel-2.99.905 and the latest from git a week or
>> > so ago.
>>
>> Symbols, please.
>>
>> addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i
>> 0x2fe
On Wed, Nov 06, 2013 at 05:36:01PM +, Chris Wilson wrote:
> On Wed, Nov 06, 2013 at 07:23:25PM +0200, ville.syrj...@linux.intel.com wrote:
> > +bool intel_fb_obj_has_fbc(struct drm_i915_gem_object *obj)
> > +{
> > + struct drm_device *dev = obj->base.dev;
> > + struct drm_i915_private *dev_
On Wed, Nov 06, 2013 at 07:23:25PM +0200, ville.syrj...@linux.intel.com wrote:
> +bool intel_fb_obj_has_fbc(struct drm_i915_gem_object *obj)
> +{
> + struct drm_device *dev = obj->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_crtc *crtc;
> +
> +
From: Ville Syrjälä
As per the SNB and HSW PM guides, we should enable FBC render/blitter
tracking only during batches targetting the front buffer.
On SNB we must also update the FBC render tracking address whenever it
changes. And since the register in question is stored in the context,
we need
From: Ville Syrjälä
We use LRIs to enable/disable the render tracking as needed. So leave
ILK_FBC_RT_BASE alone when enabling FBC on SNB.
While at it, kill the IVB_FBC_RT_BASE completely since we don't use
render tracking on IVB+.
TODO: Make ILK use the LRI mechanism too?
v2: Drop the IVB_FBC_
From: Ville Syrjälä
No longer needed since the LRIs do the work.
v2: Rebased due to hunk getting dropped from an ealier patch
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel
From: Ben Widawsky
[bwidawsk: Added Damien's SOB]
Signed-off-by: Damien Lespiau
Reviewed-by: Kenneth Graunke
Signed-off-by: Ben Widawsky
---
intel/intel_bufmgr_gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 278f5c8..32a226
From: Kenneth Graunke
Since our aub file dumping's GTT handling is totally fake, we always put
everything in the low 4GB anyway and shouldn't ever need to set
AddressHigh to anything other than 0.
Signed-off-by: Kenneth Graunke
[ben: slight commit message change]
Signed-off-by: Ben Widawsky
--
From: Damien Lespiau
The command now takes a 48bits address and is thus 1 byte longer.
Signed-off-by: Damien Lespiau
Signed-off-by: Ben Widawsky
---
intel/intel_bufmgr_gem.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_b
From: Damien Lespiau
Signed-off-by: Damien Lespiau
Reviewed-by: Kenneth Graunke
Signed-off-by: Ben Widawsky
---
intel/intel_decode.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 1b80b75..c0a0caf 100644
--- a/intel/int
From: Ben Widawsky
v2: Rename s//IRIS/
Signed-off-by: Ben Widawsky
---
intel/intel_chipset.h | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index aeb439e..e5589be 100644
--- a/intel/intel_chipset.h
+++ b/
Nothing special here... I'm fine with not pushing any of the AUB stuff if
anyone has issues.
Ben Widawsky (2):
intel/bdw: Add broadwell chipset IDs
intel/bdw: Handle gen8 bufmgr_init
Damien Lespiau (2):
intel/bdw: Add gen8 to the decode init
intel/bdw: Update MI_BATCH_BUFFER_START for aub
On 10/31/2013 09:55 AM, Jani Nikula wrote:
ALthough usually there's only one connector that supports backlight,
this also finds the correct connector. Before, we only updated the
connector on pipe A, which might not be the one with backlight. (This
only made a difference on BYT.)
Signed-off-by:
On 10/31/2013 09:55 AM, Jani Nikula wrote:
Move from dev_priv to connector->panel.
We still don't allow multiple sysfs interfaces, though.
There should be no functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_dma.c |2 +-
drivers/gpu/drm/i915/i915_drv.h
On 10/31/2013 09:55 AM, Jani Nikula wrote:
The backlight code has grown rather hairy, not least because the
hardware registers and bits have repeatedly been shuffled around. And
this isn't expected to get any easier with new hardware. Make things
easier for our (read: my) poor brains, and split t
On 10/31/2013 09:55 AM, Jani Nikula wrote:
I've always felt the backlight device conditional build has been all
backwards. Make it feel right.
Gently move things towards connector based stuff while at it.
There should be no functional changes, except for a slight
reordering/interleaving of conn
On 10/31/2013 09:55 AM, Jani Nikula wrote:
From: Jesse Barnes
With the connector and pipe passed around, we can now set the backlight
on the right pipe on VLV/BYT.
v2: drop combination mode check for VLV (Jani)
add save/restore code for VLV backlight regs (Jani)
check for existing mo
On 10/31/2013 09:55 AM, Jani Nikula wrote:
From: Jesse Barnes
On VLV/BYT, backlight controls a per-pipe, so when adjusting the
backlight we need to pass the correct info. So make the externally
visible backlight functions take a connector argument, which can be used
internally to figure out th
On 10/31/2013 09:55 AM, Jani Nikula wrote:
Doing this has been long overdue anyway, but now we really need it in
preparation for per connector backlight handling.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_opregion.c | 20 +
On Tue, Nov 05, 2013 at 01:03:37PM -0800, Jesse Barnes wrote:
> I don't think we want to add this; even though it's a small amount of
> code it's totally unnecessary on real hw, and will probably just bit
> rot.
Wholeheartedly agreed. Stuff that isn't used bitrots and then confuses
because "this c
On Tue, Nov 05, 2013 at 01:01:47PM -0800, Jesse Barnes wrote:
> On Tue, 5 Nov 2013 22:42:29 +0200
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > We'll be looking at more than just mem_freq from dev_priv, so
> > just pass the whole thing.
> >
> > Signed-off-by: Ville S
On Tue, 5 Nov 2013 22:42:28 +0200
ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We're currently miscalculating the VLV graphics clock a little bit.
> This is caused by rounding the step to integer MHz, which does not
> match reality. Change the formula to match the GUnit HAS to
On Wed, Nov 06, 2013 at 12:42:20PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 06, 2013 at 08:33:08AM +0100, Daniel Vetter wrote:
> > On Tue, Nov 05, 2013 at 10:34:12PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > valleyview_modeset_global_pipes() may add p
On Wed, Nov 06, 2013 at 04:06:29PM +, Chris Wilson wrote:
> On Wed, Nov 06, 2013 at 05:39:02PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > As per the SNB and HSW PM guides, we should enable FBC render/blitter
> > tracking only during batches targetting the fron
This is another drm-intel-collector updated notice:
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
Here goes the update list in order for better reviewers assignment:
Patch drm/i915: Asynchronously perform the set-base for a simple modeset -
Reviewed
Patch drm
On Wed, Nov 06, 2013 at 05:39:02PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> As per the SNB and HSW PM guides, we should enable FBC render/blitter
> tracking only during batches targetting the front buffer.
>
> On SNB we must also update the FBC render tracking addres
From: Ville Syrjälä
Use the same wait_for_vblank code for CTG that we use for ILK+.
Also fix the name of the frame counter register while at it.
Signed-off-by: Ville Syrjälä
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_display.c | 8
1 file changed, 4 insertions(+), 4
From: Ville Syrjälä
When the hardware frame counter reads 0xff and we're already past
vblank start, we'd return 0x100 as the vblank counter value. Once
we'd cross into the next frame's active portion, the vblank counter
would wrap to 0. So we're reporting two different vblank counter valu
From: Chris Wilson
The RPS register writing routines use the current value of min/max to
set certain limits and interrupt gating. If we set those afterwards, we
risk setting up the hw incorrectly and losing power management events,
and worse, trigger some internal assertions.
Reorder the calling
From: Ben Widawsky
v2: Fixed the botched locking on init_hw failure in i915_reset (Ville)
Call cleanup_ringbuffer on failed context create in init_hw (Ville)
v3: Add dev argument ti clean_ringbuffer
Reviewed-by: Kenneth Graunke
Signed-off-by: Ben Widawsky
Signed-off-by: Rodrigo Vivi
---
dri
From: Chris Wilson
A simple modeset, where we only wish to switch over to a new framebuffer
such as the transition from fbcon to X, takes around 30-60ms. This is
due to three factors:
1. We need to make sure the fb->obj is in the display domain, which
incurs a cache flush to ensure no dirt is le
From: Ville Syrjälä
We use LRIs to enable/disable the render tracking as needed. So leave
ILK_FBC_RT_BASE alone when enabling FBC.
TODO: Make ILK use the LRI mechanism too?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
On Sat, Nov 02, 2013 at 09:07:54PM -0700, Ben Widawsky wrote:
> This implements a workaround for PSR dealing with some vblank issue.
>
> WaPsrDPAMaskVBlankInSRD && WaPsrDPRSUnmaskVBlankInSRD
>
> v2: forgot to git add bogus whitespace fix
>
> v3: Update with workaround names.
> Use for_each_pipe(
From: Ville Syrjälä
At least since SNB (perhaps even earlier) even the desktop parts
should have FBC.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i91
From: Ville Syrjälä
Don't issue the FBC nuke/cache clean command when invalidate_domains!=0.
That would indicate that we're not being called for the post-batch
flush.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
From: Ville Syrjälä
The spec tells us that we need to emit an SRM after the LRI
to MSG_FBC_REND_STATE.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 6 --
2 files changed, 5 insertions(+), 2 deletions(-)
diff --gi
From: Ville Syrjälä
No longer needed since the LRIs do the work.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 21 -
1 file changed, 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index bfec348..4b016d8 1
From: Ville Syrjälä
As per the SNB and HSW PM guides, we should enable FBC render/blitter
tracking only during batches targetting the front buffer.
On SNB we must also update the FBC render tracking address whenever it
changes. And since the register in question is stored in the context,
we need
Hi all,
Kernel 3.12 is already out and will be base of next quarterly release.
So it is time to get intel-gpu-tools released also.
Testsuit infrastructure is in a very good shape and it is so easy to
create any test case nowadays. More about it explained above on
Daniel's post.
NEWS:
- Some pol
1. sysfs half/full switch.
4. execbuf without I915_EXEC_USE_PREDICATE
5. execbuf with I915_EXEC_USE_PREDICATE
v2: include more tests and s/GT_FULL/USE_PREDICATE
v3: make it more reliable and fix few comments
v4: use number of slices on (1,2) instead of half and full strings.
v5: respect new naming
From: Ville Syrjälä
Currently if drm_sysfs_connector_add() fails, it can leave connector->kdev
populated with an ERR_PTR value, or pointing to an already freed device.
Use a temporary kdev pointer during drm_sysfs_connector_add(), and
only set connector->kdev if the function succeeds. This avoids
On Wed, Nov 6, 2013 at 6:22 AM, Grant wrote:
>>> >> > I'm getting the following segfault intermittently when using sna.
>>> >> > I've tried xf86-video-intel-2.99.905 and the latest from git a week or
>>> >> > so ago.
>>> >>
>>> >> Symbols, please.
>>> >>
>>> >> addr2line -e /usr/lib64/xorg/modules
On Wed, Nov 06, 2013 at 06:22:40AM -0800, Grant wrote:
> >> >> > I'm getting the following segfault intermittently when using sna.
> >> >> > I've tried xf86-video-intel-2.99.905 and the latest from git a week or
> >> >> > so ago.
> >> >>
> >> >> Symbols, please.
> >> >>
> >> >> addr2line -e /usr/li
This is another drm-intel-collector updated notice:
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
Here goes the update list in order for better reviewers assignment:
Patch drm/i915: Asynchronously perform the set-base for a simple modeset -
Reviewed
Patch drm
>> >> > I'm getting the following segfault intermittently when using sna.
>> >> > I've tried xf86-video-intel-2.99.905 and the latest from git a week or
>> >> > so ago.
>> >>
>> >> Symbols, please.
>> >>
>> >> addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i
>> >> 0x2fe790x3037f
>> >
>
On Sat, Nov 02, 2013 at 09:07:49PM -0700, Ben Widawsky wrote:
> The current formula we use for HSW is not what is in current docs.
> However, changing to the HSW formula on my HSW does not improve power
> usage, and decreases performance by about 5% in limited xonotic testing.
>
> For gen8, until
On Wed, Nov 06, 2013 at 04:47:09AM -0800, Grant wrote:
> >> > I'm getting the following segfault intermittently when using sna.
> >> > I've tried xf86-video-intel-2.99.905 and the latest from git a week or
> >> > so ago.
> >>
> >> Symbols, please.
> >>
> >> addr2line -e /usr/lib64/xorg/modules/driv
On Wed, Nov 06, 2013 at 10:38:42AM -0200, Rodrigo Vivi wrote:
> I was going to get this for -collector but got a big conflict.
It should be already in. Although as it turns out it's partially
crap. Apparently I hadn't tested the ISR vblank bit behaviour
properly on non-PCH platforms. It doesn't ac
>> > I'm getting the following segfault intermittently when using sna.
>> > I've tried xf86-video-intel-2.99.905 and the latest from git a week or
>> > so ago.
>>
>> Symbols, please.
>>
>> addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe790x3037f
>
> addr2line -e /usr/lib64/xorg/m
I was going to get this for -collector but got a big conflict.
On Fri, Oct 11, 2013 at 3:52 PM, wrote:
> From: Ville Syrjälä
>
> Gen2 doesn't have the pixelcount register that gen3 and gen4 have.
> Instead we must use the scanline counter like we do for ctg+.
>
> Signed-off-by: Ville Syrjälä
On Wed, Nov 06, 2013 at 02:37:36PM +0800, Chon Ming Lee wrote:
> Some VLV PHY/PLL DPIO registers have group/lane/channel access. Current
> DPIO register definition doesn't have a structure way to break them
> down. As a result it is not easy to match the PHY/PLL registers with the
> configdb docum
On Wed, Nov 06, 2013 at 02:36:35PM +0800, Chon Ming Lee wrote:
> vlv_dpio_read/write should be describe more in PHY centric instead of
> display controller centric.
> Create a enum dpio_channel for channel index and enum dpio_phy for PHY
> index. This should better to gather for upcoming platform.
On Wed, Nov 06, 2013 at 08:33:08AM +0100, Daniel Vetter wrote:
> On Tue, Nov 05, 2013 at 10:34:12PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > valleyview_modeset_global_pipes() may add pipes that are getting fully
> > disabled to prepare_pipes bitmask. The rest of
On Wed, Nov 06, 2013 at 10:37:33AM +, Chris Wilson wrote:
> On Wed, Nov 06, 2013 at 02:33:49AM -0800, Grant wrote:
> > I'm getting the following segfault intermittently when using sna.
> > I've tried xf86-video-intel-2.99.905 and the latest from git a week or
> > so ago.
>
> Symbols, please.
>
On Wed, Nov 06, 2013 at 02:33:49AM -0800, Grant wrote:
> I'm getting the following segfault intermittently when using sna.
> I've tried xf86-video-intel-2.99.905 and the latest from git a week or
> so ago.
Symbols, please.
addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe790x3037
On Sun, Nov 03, 2013 at 10:18:14PM +0100, Daniel Vetter wrote:
>
> On Sun, Nov 3, 2013 at 8:00 PM, Thomas Richter wrote:
> > On 03.11.2013 18:13, Daniel Vetter wrote:
> >>>
> >>> Have you tried my patch to reorder the dvo sequence a bit? That /should/
> >>> get all these things right:
> >>>
> >>>
I'm getting the following segfault intermittently when using sna.
I've tried xf86-video-intel-2.99.905 and the latest from git a week or
so ago.
[ 12021.732] (EE) Backtrace:
[ 12021.741] (EE) 0: /usr/bin/X (xorg_backtrace+0x36) [0x589746]
[ 12021.741] (EE) 1: /usr/bin/X (0x40+0x18d3d9) [0x58d3
On Wed, Nov 06, 2013 at 09:19:42AM +, Chris Wilson wrote:
> On Wed, Nov 06, 2013 at 08:35:46AM +0100, Daniel Vetter wrote:
> > On Tue, Nov 05, 2013 at 05:01:38PM -0800, Ben Widawsky wrote:
> > > Many tests call this ad naseum now (in an infinite loop, very often).
> > > It clutters the logs. Ac
On Wed, Nov 06, 2013 at 10:41:22AM +0200, Ville Syrjälä wrote:
> On Tue, Nov 05, 2013 at 01:02:58PM -0800, Jesse Barnes wrote:
> > On Tue, 5 Nov 2013 22:42:30 +0200
> > ville.syrj...@linux.intel.com wrote:
> >
> > > From: Ville Syrjälä
> > >
> > > Keep the HPLL frequencey in dev_priv on VLV ins
On Tue, Nov 05, 2013 at 05:17:26PM +0100, Daniel Vetter wrote:
> On Tue, Nov 05, 2013 at 05:41:21PM +0200, Imre Deak wrote:
> > On Sat, 2013-11-02 at 21:07 -0700, Ben Widawsky wrote:
> > > Implements WaVSRefCountFullforceMissDisable
> > > Implements WaDSRefCountFullforceMissDisable
> > >
> > > v2:
On Wed, Nov 06, 2013 at 08:35:46AM +0100, Daniel Vetter wrote:
> On Tue, Nov 05, 2013 at 05:01:38PM -0800, Ben Widawsky wrote:
> > Many tests call this ad naseum now (in an infinite loop, very often).
> > It clutters the logs. Actually, I'd rather drop it completely...
>
> Dropping it completely s
On Tue, Nov 05, 2013 at 01:02:58PM -0800, Jesse Barnes wrote:
> On Tue, 5 Nov 2013 22:42:30 +0200
> ville.syrj...@linux.intel.com wrote:
>
> > From: Ville Syrjälä
> >
> > Keep the HPLL frequencey in dev_priv on VLV instead of reading
> > it from CCK every time it's needed.
> >
> > Signed-off-b
On Sat, Nov 02, 2013 at 09:07:09PM -0700, Ben Widawsky wrote:
> The interrupt handling implementation remains the same as previous
> generations with the 4 types of registers, status, identity, mask, and
> enable. However the layout of where the bits go have changed entirely.
> To address these cha
> -Original Message-
> From: intel-gfx-boun...@lists.freedesktop.org [mailto:intel-gfx-
> boun...@lists.freedesktop.org] On Behalf Of Ben Widawsky
> Sent: Sunday, November 03, 2013 4:07 AM
> To: Intel GFX
> Cc: Daniel Vetter; Ben Widawsky; Widawsky, Benjamin
> Subject: [Intel-gfx] [PATCH 20
1 - 100 of 105 matches
Mail list logo
