Hopefully the culmination of the DDC:0xa0 saga along with another bug
that was also found lurking the VGA regression reports.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Toggle the Software Clear Interrupt bit which resets the controller to
clear any prior BUS_ERROR condition before we begin to use the
controller in earnest.
Suggested-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_i2c.c |
This is a moral revert of 6ec3d0c0e9c0c605696e91048eebaca7b0c36695.
Following the fix to reset the GMBUS controller after a NAK, we finally
utilize the 0xa0 probe for a CRT connection. And discover that it the
code is broken. Shock.
There are a number of issues, but following a key insight from
We were using uninitialised watermarks values for disabled pipes which
were combined into a single WM register and so corrupting the values for
the enabled pipe and upsetting the display hardware.
Reported-by: Riccardo Magliocchetti riccardo.magliocche...@gmail.com
Bugzilla:
On Tue, 5 Apr 2011 13:21:08 +0300, Tomas Winkler tom...@gmail.com wrote:
On Fri, Apr 1, 2011 at 2:51 PM, Pekka Enberg penb...@kernel.org wrote:
Unfortunately I get a blank screen with after boot:
Nacked-by: Pekka Enberg penb...@kernel.org
But until you can tell me where it explodes on your
On Tue, 5 Apr 2011 17:11:56 +0300, Pekka Enberg penb...@kernel.org wrote:
[9.310010] IRQ [8168cd0c] panic+0x91/0x19e
[9.310010] [816909ea] oops_end+0xea/0xf0
[9.310010] [8106afbb] no_context+0xfb/0x260
[9.310010] [8106b245]
If the outputs are active and continuing to access the GATT when we
teardown the PTEs, then there is a potential for us to hang the GPU.
The hang tends to be a PGTBL_ER with either an invalid host access or
an invalid display plane fetch.
v2: Reorder IRQ initialisation to defer until after GEM is
On Tue, Apr 5, 2011 at 3:30 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Tue, 5 Apr 2011 13:21:08 +0300, Tomas Winkler tom...@gmail.com wrote:
On Fri, Apr 1, 2011 at 2:51 PM, Pekka Enberg penb...@kernel.org wrote:
Unfortunately I get a blank screen with after boot:
Nacked-by: Pekka
On Tue, 5 Apr 2011 07:42:14 -0700, Linus Torvalds
torva...@linux-foundation.org wrote:
NO.
And you seemed to have missed that patch has sat around waiting for Pekka
to give me some information on the failure on his machine.
I have been poking as many people as I could to get it reviewed and
On Tue, 5 Apr 2011 18:11:37 +0300, Pekka Enberg penb...@kernel.org wrote:
Hi Chris,
On Tue, Apr 5, 2011 at 5:34 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
If the outputs are active and continuing to access the GATT when we
teardown the PTEs, then there is a potential for us to hang
On Tue, Apr 05, 2011 at 09:18:37AM -0700, Ben Widawsky wrote:
Outside of being able to do that directly, I would add a call to
intel_i2c_reset() from intel_teardown_gmbus().
Hmm, forget that, I think this is silly. How about just a comment in the
code stating that intel_i2c_reset() should
Here is the beginning of the port of intel-gpu-tools. It buys us enough
to not be completely broken with the 3 apps I find most important. We
badly need some kind of global arg parsing for our tools, as well as
port the rest of the tools to use INREG/OUTREG, instead of relying on
mmio, but I will
Redid the arg parsing as well as the register dumps to easily support
switching between ioctl, and non-ioctl usage.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
tools/intel_reg_read.c | 41 +
1 files changed, 29 insertions(+), 12 deletions(-)
diff
we really need a global arg parser... :(
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
tools/intel_reg_write.c | 44
1 files changed, 32 insertions(+), 12 deletions(-)
diff --git a/tools/intel_reg_write.c b/tools/intel_reg_write.c
index
On Tue, 5 Apr 2011 10:24:15 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Rather than proceed on and return false by default, return the result
from detecting a connection but to a digital panel and include some
debug output as to why.
This comment does not match the patch anymore;
On Tue, 5 Apr 2011 10:24:18 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Toggle the Software Clear Interrupt bit which resets the controller to
clear any prior BUS_ERROR condition before we begin to use the
controller in earnest.
We do this in two places now, do we want to share the
On Tue, 05 Apr 2011 13:56:37 -0700, Keith Packard kei...@keithp.com wrote:
On Tue, 5 Apr 2011 10:24:14 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
crtc = intel_get_crtc_for_plane(dev, plane);
- if (crtc-fb == NULL || !crtc-enabled)
+ if (crtc-fb == NULL ||
This looks like it fixes two bugs:
1) What if there is an error recorded before we start and so we
immediately service an IIR/EIR upon intalling the IRQ. Did we generate
that error during initialisation or was that SEP? Now we do stuff before
we even install the IRQ so there is a possibility that
On Tue, 05 Apr 2011 22:12:19 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Indeed, I started by setting them to zero in the caller. Decided that
there was some precedent to use the guard_size as the minimum value for
unused planes (and so perhaps the unused planes on the unused pipes)
On Tue, 5 Apr 2011 23:00:46 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
This looks like it fixes two bugs:
1) What if there is an error recorded before we start and so we
immediately service an IIR/EIR upon intalling the IRQ. Did we generate
that error during initialisation or was
20 matches
Mail list logo
