Chris Wilson dug out a hw erratum saying that there's noise on the
interrupt line on i945G chips. We also have a bug report from a i945GM
chip with an sdvo hotplug interrupt storm (and no apparent cause).
Play it safe and disable sdvo hotplug on all i945 variants.
Bugzilla:
On Thu, May 03, 2012 at 03:51:58PM +0200, Daniel Vetter wrote:
Our handling of the crtc timing computation has been nicely
cargo-culted with calls to drm_mode_set_crtcinfo sprinkled all over
the place. But with
commit f9bef081c3c3f77bec54454872e98d3ec635756f
Author: Daniel Vetter
On Tue, Apr 24, 2012 at 08:24:20PM +0100, Chris Wilson wrote:
On Tue, 24 Apr 2012 18:27:57 +0200, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
The drm_mode-dtd conversion used the crtc timings, whereas the
dtd-drm_mod did not set these. Use the standard mode information, not
the crtc
On Fri, Apr 27, 2012 at 03:17:40PM +0200, Daniel Vetter wrote:
... by writing (anything) to i915_error_state.
This way we can simulate a bunch of gpu hangs and run the error_state
capture code every time (without the need to reload the module).
To make that happen we need to abandon the
On Wed, May 02, 2012 at 12:54:46PM -0700, Kenneth Graunke wrote:
On 05/02/2012 12:33 PM, Daniel Vetter wrote:
While trying to fix up gen4 gpu reset in
commit f49f0586191fe16140410db0a46d43bdc690d6af
Author: Kenneth Graunkekenn...@whitecape.org
Date: Sat Sep 11 01:19:14 2010 -0700
I think the subject should be 'Break intel_infoframe_flags into _enable and
_frequency', no?
Good catch. I can swear I fixed this before...
And by looking at what this does, perhaps the 2nd function could be named
intel_infoframe_freq_vsync or intel_infoframe_vsync instead?
Well, bit 18 is
On 04/27/2012 10:17 AM, Daniel Vetter wrote:
Only half of them even cared, and it's always the same one.
Signed-Off-by: Daniel Vetterdaniel.vet...@ffwll.ch
Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
___
Intel-gfx mailing list
On 04/27/2012 10:17 AM, Daniel Vetter wrote:
- reset the stop_rings infrastructure while resetting the hw to
avoid angering the hangcheck right away (and potentially declaring
the gpu permanently wedged).
- ignore reset failures when hanging due to the hangman - we don't
have reset
On 04/27/2012 10:17 AM, Daniel Vetter wrote:
- need_display is always true, scrap it.
- don't reacquire the mutex to do nothing after having restored the
gem state.
Signed-Off-by: Daniel Vetterdaniel.vet...@ffwll.ch
Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
On 04/27/2012 10:17 AM, Daniel Vetter wrote:
Slightly cleans up the code and could be useful for e.g. Ben
Widawsky's hw context patches.
v2: New colours!
Cc: Ben Widawskyb...@bwidawsk.net
Signed-Off-by: Daniel Vetterdaniel.vet...@ffwll.ch
Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
On 04/27/2012 10:17 AM, Daniel Vetter wrote:
- reduce the irq disabled section, even for a debugfs file this was
way too long.
- always disable irqs when taking the lock.
v2: Thou shalt not mistake locking for reference counting, so:
- reference count the error_state to protect from
On 05/02/2012 04:33 PM, Daniel Vetter wrote:
While trying to fix up gen4 gpu reset in
commit f49f0586191fe16140410db0a46d43bdc690d6af
Author: Kenneth Graunkekenn...@whitecape.org
Date: Sat Sep 11 01:19:14 2010 -0700
drm/i915: Actually set the reset bit in i965_reset
a little confusion
On 05/04/2012 08:56 AM, Daniel Vetter wrote:
+static int i915_error_state_release(struct inode *inode, struct file *file)
+{
+ struct seq_file *m = file-private_data;
+ struct i915_error_state_file_priv *error_priv = m-private;
+
+ if (error_priv-error)
+
I'm seeing about a 5% FPS improvement across various benchmarks on my
IVB i3. Rumor has it that the higher end parts show even more benefit.
This derives from a patch originally given to me by Bernard. The docs
are confusing about the definition names (ie. medium really seems like
max), but it
Anyone have any further thoughts on this?
--
Matthew Garrett | mj...@srcf.ucam.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thu, 26 Apr 2012 16:03:00 -0700
Ben Widawsky b...@bwidawsk.net wrote:
This extra bit of interrupt enabling code doesn't belong in the wait
seqno function. If anything we should pull it out to a helper so the
throttle code can also use it. The history is a bit vague, but I am
going to
On Fri, May 04, 2012 at 07:56:08 +0200, tino.keitel+x...@tikei.de wrote:
On Thu, May 03, 2012 at 16:32:47 -0400, Chun-Yu Shei wrote:
On 05/03/2012 03:51 PM, tino.keitel+x...@tikei.de wrote:
On Thu, May 03, 2012 at 21:46:37 +0200, Daniel Vetter wrote:
On Thu, May 03, 2012 at 09:34:28PM
On Fri, May 04, 2012 at 02:15:33PM -0300, Eugeni Dodonov wrote:
On 05/04/2012 08:56 AM, Daniel Vetter wrote:
+static int i915_error_state_release(struct inode *inode, struct file *file)
+{
+ struct seq_file *m = file-private_data;
+ struct i915_error_state_file_priv *error_priv =
2012/5/2 Paulo Zanoni przan...@gmail.com:
Hi
This is an initial set of patches related to InfoFrames I developed.
Resending patches after comments/reviews on e-mail and IRC:
- Improved commit messages, better explaining why each patch is needed
- Patch 3 (implement ironlake_wait_for_vlank)
From: Paulo Zanoni paulo.r.zan...@intel.com
Gen3+ is 13 bits (12:0), and on gen2 only 12 (11:0). For both the high
bits are marked reserved, read-only so continue to mask them. Bit 31
is not reserved and has a meaning.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Chris
From: Paulo Zanoni paulo.r.zan...@intel.com
intel_wait_for_vblank uses PIPESTAT, which does not exist on Ironlake
and newer, so now we use PIPEFRAME.
There's also a check to see if the pipe is stopped.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
From: Paulo Zanoni paulo.r.zan...@intel.com
This is not documented anywhere, but it seems necessary to make the
InfoFrames work, especially when all you have is an HDMI monitor.
Some bugs get fixed just by running ./intel_infoframes -d. This
patch fixes this problem on my machine.
From: Paulo Zanoni paulo.r.zan...@intel.com
Don't use intermediate variables, change the value of 'val' as we go
through the function. The new style looks more similar to the rest of
our code. IMHO, it's also easier to read and change.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
From: Paulo Zanoni paulo.r.zan...@intel.com
Make sure we're doing the right thing, just like we do on gen5+.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_hdmi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Paulo Zanoni paulo.r.zan...@intel.com
Should prevent bugs when changing the port.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_hdmi.c |1 +
2 files
From: Paulo Zanoni paulo.r.zan...@intel.com
This will allow us to disable an infoframe without changing its
frequency.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/intel_hdmi.c | 32
From: Paulo Zanoni paulo.r.zan...@intel.com
That's what the VIDEO_DIP_CTL documentation says we need to do. Except
when it's the AVI InfoFrame and we're ironlake_write_infoframe.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
From: Paulo Zanoni paulo.r.zan...@intel.com
Better safe than sorry. Currently we never change the frequency and
use the same for every infoframe type, so the only way to reproduce a
bug would be with the BIOS doing something.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by:
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index
From: Paulo Zanoni paulo.r.zan...@intel.com
The registers are on the PCH, so use the PCH name instead of the CPU
name. Also, the way this function is implemented is really only for
CPT and PPT. For now, both functions have the same implementations:
the next patch will fix ibx_write_infoframe.
From: Paulo Zanoni paulo.r.zan...@intel.com
IBX does not need the workaround used in cpt_write_infoframe that
requires the AVI frame to be enabled while being updated.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_hdmi.c |8 +---
1 file changed, 1
From: Paulo Zanoni paulo.r.zan...@intel.com
Just like Gen 4, IBX has a Port Select field on the DIP register,
but the ports are different.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_hdmi.c | 16
On Fri, May 04, 2012 at 05:18:25PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
IBX does not need the workaround used in cpt_write_infoframe that
requires the AVI frame to be enabled while being updated.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Minor
On Fri, 4 May 2012 18:58:59 -0700
Ben Widawsky b...@bwidawsk.net wrote:
I'm seeing about a 5% FPS improvement across various benchmarks on my
IVB i3. Rumor has it that the higher end parts show even more benefit.
This derives from a patch originally given to me by Bernard. The docs
are
On Fri, May 04, 2012 at 01:40:27PM -0700, Jesse Barnes wrote:
On Fri, 4 May 2012 18:58:59 -0700
Ben Widawsky b...@bwidawsk.net wrote:
I'm seeing about a 5% FPS improvement across various benchmarks on my
IVB i3. Rumor has it that the higher end parts show even more benefit.
This
On Fri, May 04, 2012 at 05:15:37PM -0300, Paulo Zanoni wrote:
2012/5/2 Paulo Zanoni przan...@gmail.com:
Hi
This is an initial set of patches related to InfoFrames I developed.
Resending patches after comments/reviews on e-mail and IRC:
- Improved commit messages, better explaining why
36 matches
Mail list logo
