On 11/21/2013 04:56 AM, Igor Gnatenko wrote:
> Any news here? If no - I think we need re-send patch as new..
Since the v2 patch can't apply cleanly on top of pm's -next tree, I
think it's worth a re-send, so here it comes.
---
Subject: [PATCH] ACPI / video: Add systems that should favor native ba
> On Wed, Nov 20, 2013 at 11:45:03PM +, Gohad, Tushar wrote:
> > > > On Wed, Nov 20, 2013 at 09:48:26PM +, Gohad, Tushar wrote:
> > > > > Folks,
> > > > >
> > > > > When filling in an HDMI AVI infoframe, how does one correctly
> > > > > determine the "default" picture aspect ratio (and VIC)
On 2013.11.20 16:59:22 +, Damien Lespiau wrote:
> Right, so the fix is (was) to zero the fields checked by the kernel
> explicitely, not change the VG() macro, which is just used in testing
> (and it should this way).
>
That's fine. Thanks.
--
Open Source Technology Center, Intel ltd.
$gpg
On Wed, Nov 20, 2013 at 11:45:03PM +, Gohad, Tushar wrote:
> > > On Wed, Nov 20, 2013 at 09:48:26PM +, Gohad, Tushar wrote:
> > > > Folks,
> > > >
> > > > When filling in an HDMI AVI infoframe, how does
> > > > one correctly determine the "default" picture aspect ratio (and VIC)
> > > > for
actually just ignore my last msg... alternate between gmail and mutt
confused me...
On Wed, Nov 6, 2013 at 1:02 PM, 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
ops, I just noticed that by mistake I replied the v1-series
but I actually looked to v2 seires... Sorry about that
On Wed, Nov 20, 2013 at 3:17 PM, Chris Wilson wrote:
> On Wed, Nov 20, 2013 at 02:55:57PM -0800, Rodrigo Vivi wrote:
>> On Wed, Nov 06, 2013 at 11:02:21PM +0200, ville.syrj...@li
> > On Wed, Nov 20, 2013 at 09:48:26PM +, Gohad, Tushar wrote:
> > > Folks,
> > >
> > > When filling in an HDMI AVI infoframe, how does
> > > one correctly determine the "default" picture aspect ratio (and VIC)
> > > for CEA modes that support multiple (4:3 and 16:9) aspect ratios.
> > > 720x57
On Wed, Nov 20, 2013 at 02:55:57PM -0800, Rodrigo Vivi wrote:
> On Wed, Nov 06, 2013 at 11:02:21PM +0200, ville.syrj...@linux.intel.com wrote:
> > static void
> > +i915_gem_execbuffer_mark_fbc_dirty(struct intel_ring_buffer *ring,
> > + struct list_head *vmas)
> > +{
>
Reviewed-by: Rodrigo Vivi
On Wed, Nov 06, 2013 at 11:02:24PM +0200, ville.syrj...@linux.intel.com wrote:
> 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
Reviewed-by: Rodrigo Vivi
On Wed, Nov 06, 2013 at 11:02:25PM +0200, ville.syrj...@linux.intel.com wrote:
> 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.
On Wed, Nov 06, 2013 at 11:02:22PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> No longer needed since the LRIs do the work.
Shouldn't this be part of previous patch?
>
> v2: Rebased due to hunk getting dropped from an ealier patch
>
> Signed-off-by: Ville Syrjälä
>
On Wed, Nov 06, 2013 at 11:02:23PM +0200, ville.syrj...@linux.intel.com wrote:
> 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.
Shouldn't this be part of patch 6
>
> While at it, kill the IVB_FBC_RT
On Wed, Nov 06, 2013 at 11:02:21PM +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.
You improved things a lot here, but I'm just not convinced th
Reviewed-by: Rodrigo Vivi
On Wed, Nov 06, 2013 at 11:02:20PM +0200, ville.syrj...@linux.intel.com wrote:
> 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
On Wed, Nov 06, 2013 at 11:02:19PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Don't issue the FBC nuke/cache clean command when invalidate_domains!=0.
Double negative almost confused me, but all right here.
Reviewed-by: Rodrigo Vivi
> That would indicate that we're
On Wed, Nov 06, 2013 at 11:02:16PM +0200, ville.syrj...@linux.intel.com wrote:
> 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.
Why don't you create a new m
On Wed, Nov 20, 2013 at 10:11:55PM +, Damien Lespiau wrote:
> On Wed, Nov 20, 2013 at 09:48:26PM +, Gohad, Tushar wrote:
> > Folks,
> >
> > A newbie question - When filling in an HDMI AVI infoframe, how does
> > one correctly determine the "default" picture aspect ratio (and VIC)
> > for C
On Wed, Nov 20, 2013 at 09:48:26PM +, Gohad, Tushar wrote:
> Folks,
>
> A newbie question - When filling in an HDMI AVI infoframe, how does
> one correctly determine the "default" picture aspect ratio (and VIC)
> for CEA modes that support multiple (4:3 and 16:9) aspect ratios.
> 720x576p for
Folks,
A newbie question - When filling in an HDMI AVI infoframe, how does one
correctly determine the "default" picture aspect ratio (and VIC) for CEA modes
that support multiple (4:3 and 16:9) aspect ratios. 720x576p for example,
corresponds to VIC 17 or 18:
/* 17 - 720x576@50Hz */
On Fri, 2013-11-15 at 14:07 +0800, Aaron Lu wrote:
> Some system's ACPI video backlight control interface is broken and the
> native backlight control interface should be used by default. This patch
> sets the use_native_backlight parameter to true for those systems so
> that video backlight contro
Hi Stephen,
On Wed, 20 November 2013 Stephen Clark wrote:
> Hi Bruno,
>
> I have tested the latest kernel and X, mesa etc, but am still using
> wine-1.3.24.
> I am working on upgrading that. If I still have the error I will file
> a bug report at bugs.freedesktop.org. I already have a login beca
The kernel sometimes reports bogus MSC values, especially when
suspending and resuming the machine. Deal with this by tracking an
offset to ensure that the MSC seen by applications increases
monotonically, and at a reasonable pace.
Also, provide a full 64 bits of MSC value by noticing wrapping and
Signed-off-by: Keith Packard
---
configure.ac | 14
src/uxa/Makefile.am| 7 ++
src/uxa/intel.h| 17 +
src/uxa/intel_dri3.c | 184 +
src/uxa/intel_driver.c | 13
src/uxa/intel_sync.c | 109
Signed-off-by: Keith Packard
---
configure.ac| 15 ++
src/uxa/Makefile.am | 6 +
src/uxa/intel.h | 15 ++
src/uxa/intel_driver.c | 4 +
src/uxa/intel_present.c | 406
5 files changed, 446 insertions(+)
create mode 10
This refactors the drm interrupt handling logic quite a bit, both to
allow for either DRI2 or Present handlers, but also to eliminate
passing pointers through the kernel. Passing pointers left the kernel
holding the only reference to some internal X server data structures.
After a server reset, th
Here's a series of patches which provide DRI3 and Present support in
the Intel 2D driver. The first two patches pave the way by
synthesizing 64-bit vblank counters and extending the DRM event
handling to allow for both DRI2 and DRI3 events. Then there's a patch
to add DRI2 and miSyncShm support fol
On Wed, Nov 20, 2013 at 04:58:17PM +0200, Mika Kuoppala wrote:
> Getting global reset count needs to be tested with root and
> non root access.
>
> Signed-off-by: Mika Kuoppala
All merged to igt, thanks for the patches.
-Daniel
> ---
> tests/gem_reset_stats.c | 70
> +
Hi Bruno,
I have tested the latest kernel and X, mesa etc, but am still using wine-1.3.24.
I am working on upgrading that. If I still
have the error I will file a bug report at bugs.freedesktop.org. I already have
a login because of the same problem
happening with Myst 5, but it was never resol
Hi Stephen,
On Tue, 19 November 2013 Stephen Clark wrote:
> Thanks for the response. I have subscribed to the intel-gfx list. I didn't
> post
> the error_state file since it huge.
It's best to submit a but report on bugs.freedesktop.org and attach the
error_state there (compressed if needed) -
On Mon, Nov 18, 2013 at 05:13:19PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 14, 2013 at 07:09:48PM +0200, Ville Syrjälä wrote:
> > On Thu, Nov 14, 2013 at 02:54:10PM +0200, Mika Kuoppala wrote:
> > > ville.syrj...@linux.intel.com writes:
> > >
> > > > From: Ville Syrjälä
> > > >
> > > > On VLV G
On Wed, Nov 20, 2013 at 11:53:54PM +0800, Zhenyu Wang wrote:
> > VG_CLEAR() is really just for valgrind. If you need to set some specific
> > variable/field to 0 then you need to set it to 0 and not rely on
> > VG_CLEAR() to do it for you.
> >
>
> ok, in valgrind case it does memory clear for ioc
On Wed, Nov 20, 2013 at 08:38:38AM -0800, Ian Romanick wrote:
> From: Ian Romanick
>
> The ioctl expects that certain fields will be zeroed, so we should allow
> the helper function to actually work in non-Valgrind builds.
>
> Signed-off-by: Ian Romanick
> Reported-by: Zhenyu Wang
> Cc: Damien
On Wed, Nov 20, 2013 at 3:03 AM, Chris Wilson wrote:
> On Tue, Nov 19, 2013 at 09:37:16AM -0800, Rodrigo Vivi wrote:
>> On Tue, Nov 19, 2013 at 5:52 AM, Chris Wilson
>> wrote:
>> > On Mon, Nov 18, 2013 at 06:32:34PM -0800, Rodrigo Vivi wrote:
>> >> From: Daniel Vetter
>> >>
>> >> This is useful
On Wed, 20 Nov 2013 06:00:24 +
"S, Deepak" wrote:
> Hi Jesse,
>
> Thanks for the review. Below is my response.
>
> > - why not use the callback to __vlv_force_wake_* from
> gen6_gt_force_wake_*? i.e. why is VLV special here?
> [Deepak] Gen6 has a single power well whereas the VLV
On Wed, Nov 20, 2013 at 08:38:38AM -0800, Ian Romanick wrote:
> From: Ian Romanick
>
> The ioctl expects that certain fields will be zeroed, so we should allow
> the helper function to actually work in non-Valgrind builds.
>
> Signed-off-by: Ian Romanick
> Reported-by: Zhenyu Wang
> Cc: Damien
From: Ian Romanick
The ioctl expects that certain fields will be zeroed, so we should allow
the helper function to actually work in non-Valgrind builds.
Signed-off-by: Ian Romanick
Reported-by: Zhenyu Wang
Cc: Damien Lespiau
Cc: Daniel Vetter
---
intel/intel_bufmgr_gem.c | 2 +-
1 file chan
Thanks Jesse, I wil split the patches and send it for review.
Thanks
Deepak
-Original Message-
From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
Sent: Wednesday, November 20, 2013 9:35 PM
To: S, Deepak
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/vlv:
On Wed, Nov 20, 2013 at 7:00 AM, S, Deepak wrote:
>>- have you done measurements on this? given how infrequently we
> ought to be waking the wells when they're idle, and how long we
> generally keep them awake, is this a real power win?
> [Deepak] By Individually controlling the wells we
On 2013.11.20 11:36:20 +, Damien Lespiau wrote:
> On Wed, Nov 20, 2013 at 05:22:48PM +0800, Zhenyu Wang wrote:
> > If valgrind is not available, current VG_CLEAR() would just ignore
> > memory clear operation which might make invalid ioctl argument. So
> > make sure VG_CLEAR() will always clear
Hi Dave,
Just a small pile of fixes for bugs and a few regressions. I'm still
trying to track down a driver load hang on my g33 (which infuriatingly
doesn't happen when loading the module manually after boot), somehow
bisecting loves to go astray on this one :( And there's a (harmless)
locking WAR
For BDW+, there BATCH_BUFFER_START is 3 * 32bits in length and
length needs to be encoded into the opcode.
Suggested-by: Damien Lespiau
Signed-off-by: Mika Kuoppala
---
tests/gem_reset_stats.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/tests/gem_reset_sta
Getting global reset count needs to be tested with root and
non root access.
Signed-off-by: Mika Kuoppala
---
tests/gem_reset_stats.c | 70 +--
1 file changed, 61 insertions(+), 9 deletions(-)
diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_s
To make driver report a simulated hang in dmesg.
Suggested-by: Daniel Vetter
Signed-off-by: Mika Kuoppala
---
tests/gem_reset_stats.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_stats.c
index a7497f3..9e52b60 100644
--- a/t
On Wed, Nov 20, 2013 at 04:47:14PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 20, 2013 at 03:02:10PM +0100, Daniel Vetter wrote:
> > This regression has been introduced in
> >
> > commit 4fe8590a921d0b2e36e542dbfa89a8c5993f5a3f
> > Author: Ville Syrjälä
> > Date: Wed Sep 4 18:25:22 2013 +0300
>
On Wed, Nov 20, 2013 at 03:02:10PM +0100, Daniel Vetter wrote:
> This regression has been introduced in
>
> commit 4fe8590a921d0b2e36e542dbfa89a8c5993f5a3f
> Author: Ville Syrjälä
> Date: Wed Sep 4 18:25:22 2013 +0300
>
> drm/i915: Use adjusted_mode appropriately when computing watermarks
This regression has been introduced in
commit 4fe8590a921d0b2e36e542dbfa89a8c5993f5a3f
Author: Ville Syrjälä
Date: Wed Sep 4 18:25:22 2013 +0300
drm/i915: Use adjusted_mode appropriately when computing watermarks
I guess we should renable the enabled local variable into something a
notch
On Wed, Nov 13, 2013 at 10:20:45AM -0800, Jesse Barnes wrote:
> Read out the current plane configuration at init time into a new
> plane_config structure. This allows us to track any existing
> framebuffers attached to the plane and potentially re-use them in our
> fbdev code for a smooth handoff.
On Wed, Nov 20, 2013 at 12:47 PM, Mika Kuoppala
wrote:
> FAIL WaDisableEarlyCull:ivb
> OK WaDisableBackToBackFlipFix:ivb
> FAIL WaDisablePSDDualDispatchEnable:ivb
> FAIL WaDisableRHWOptimizationForRenderHang:ivb
> FAIL WaApplyL3ControlAndL3ChickenMode:ivb
> OK WaForceL3
Daniel Vetter writes:
Hi Daniel,
> On Mon, Nov 18, 2013 at 04:34:44PM +0200, Mika Kuoppala wrote:
>> Large parts of hw initialization is behind per gen
>> clock gating functions. Including workarounds.
>>
>> Call intel_modeset_init_hw after reset so that we
>> set these up correctly.
>>
>> Sig
On Wed, Nov 20, 2013 at 05:22:48PM +0800, Zhenyu Wang wrote:
> If valgrind is not available, current VG_CLEAR() would just ignore
> memory clear operation which might make invalid ioctl argument. So
> make sure VG_CLEAR() will always clear memory.
> ---
> intel/intel_bufmgr_gem.c | 2 +-
> 1 file
On Tue, Nov 19, 2013 at 09:37:16AM -0800, Rodrigo Vivi wrote:
> On Tue, Nov 19, 2013 at 5:52 AM, Chris Wilson
> wrote:
> > On Mon, Nov 18, 2013 at 06:32:34PM -0800, Rodrigo Vivi wrote:
> >> From: Daniel Vetter
> >>
> >> This is useful when we only have aliasing ppgtt and want to figure out
> >>
Am 20.11.2013 10:27, schrieb Daniel Vetter:
What I've meant to say is that I want to split up the watermark code
more anyway, so that there's no need to fill in the 0 all over the
place where we don't care one bit. I.e. all the gen4+ platforms.
Ok - well, I guess I cannot judge whether that's n
On Wed, Nov 20, 2013 at 10:18 AM, Thomas Richter wrote:
>> I think we ned to split out the gen2/3 single/dual pipe watermark code a
>>
>> bit better from everything else. A bugfix for i830M shouldn't really
>> affect snb ;-)
>
>
> Actually, the fun part is that it does not because all the lower li
If valgrind is not available, current VG_CLEAR() would just ignore
memory clear operation which might make invalid ioctl argument. So
make sure VG_CLEAR() will always clear memory.
---
intel/intel_bufmgr_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/intel/intel_bufmgr_g
Am 19.11.2013 17:41, schrieb Daniel Vetter:
On Tue, Nov 19, 2013 at 05:15:09PM +0100, Thomas Richter wrote:
Hi Daniel, dear intel experts,
please find a patch attached that finally addresses the display
flicker on i830 chipsets. This
patch adds a lower watermark setting in intel_watermark_param
55 matches
Mail list logo
