| Message ID | 1381227943-4409-1-git-send-email-daniel.vetter@ffwll.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Oct 08, 2013 at 12:25:41PM +0200, Daniel Vetter wrote: > At least on my i830M here it reliably results in hard system hangs > nowadays. This is much worse than falling back to software rendering, > so I think we should simply rip this out. > > After all we don't have any gpu reset for gen3 either, and there are a > lot more of those still around. > > Cc: Chris Wilson <chris@chris-wilson.co.uk> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> -Chris
On Tue, Oct 08, 2013 at 11:29:41AM +0100, Chris Wilson wrote: > On Tue, Oct 08, 2013 at 12:25:41PM +0200, Daniel Vetter wrote: > > At least on my i830M here it reliably results in hard system hangs > > nowadays. This is much worse than falling back to software rendering, > > so I think we should simply rip this out. > > > > After all we don't have any gpu reset for gen3 either, and there are a > > lot more of those still around. > > > > Cc: Chris Wilson <chris@chris-wilson.co.uk> > > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> > Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Merged, thanks for sanity checking and the quick testrun on your i845g. -Daniel
Hi Daniel, dear kernel developers,
just tried the 3.12.rc3+ from the intel-drm git. This version *worked*
again, pretty much the same way the 3.10.10 "worked".
Side effects are, however, quite the same when you connect an external
monitor:
If connected while the gdm login screen is on, the external monitor
works fine with the internal TFT (mirroring is turned on). Resolutions
1024x768 and 800x600 are fine, switching to 640x480 locks up the
internal DVO, the external monitor keeps working. Note that the DVO
does *not* lock up if the external monitor is not connect (probably a
frequency issue, need to check).
Booting with the external monitor connected creates a "locked up"
display on the internal TFT, and a flickering display on the external
screen as if the watermark levels are not set correctly. The external
screen shows a horizontal offset of approximately half the screen
width (scrolled to the right), but jumps back to its correct position
irregularly. Note that this type of flickering is different from the flicker
created by panning on the 835GM (already reported this problem), which
shows a regular 30Hz flicker.
Once the gdm comes up, the internal TFT keeps dead, and the external
shows only a black screen but with a working mouse pointer.
Logging in blindly restores a working screen on both monitors.
So thanks for the update, seems to have worked, but is still not working
perfectly. External monitors are not supported correctly,
and panning is still a problem, even with a "linear" framebuffer.
Greetings,
Thomas
On Tue, Oct 08, 2013 at 10:56:41PM +0200, Thomas Richter wrote: > Hi Daniel, dear kernel developers, > > just tried the 3.12.rc3+ from the intel-drm git. This version > *worked* again, pretty much the same way the 3.10.10 "worked". > > Side effects are, however, quite the same when you connect an > external monitor: > > If connected while the gdm login screen is on, the external monitor > works fine with the internal TFT (mirroring is turned on). > Resolutions > 1024x768 and 800x600 are fine, switching to 640x480 locks up the > internal DVO, the external monitor keeps working. Note that the DVO > does *not* lock up if the external monitor is not connect (probably > a frequency issue, need to check). > > Booting with the external monitor connected creates a "locked up" > display on the internal TFT, and a flickering display on the > external > screen as if the watermark levels are not set correctly. The > external screen shows a horizontal offset of approximately half the > screen > width (scrolled to the right), but jumps back to its correct > position irregularly. Note that this type of flickering is different > from the flicker > created by panning on the 835GM (already reported this problem), > which shows a regular 30Hz flicker. > > Once the gdm comes up, the internal TFT keeps dead, and the external > shows only a black screen but with a working mouse pointer. > Logging in blindly restores a working screen on both monitors. > > So thanks for the update, seems to have worked, but is still not > working perfectly. External monitors are not supported correctly, > and panning is still a problem, even with a "linear" framebuffer. My drm-intel git branch doesn't yet have the two patches that are meant to replace your ns2501 hack ... So I'm not too sure what exactly you've tested that made things magically better? For me the key to get rid of the black screen was the two sna patches, not the kernel stuff here. -Daniel
On 09.10.2013 00:00, Daniel Vetter wrote: > > My drm-intel git branch doesn't yet have the two patches that are meant to > replace your ns2501 hack ... So I'm not too sure what exactly you've > tested that made things magically better? Is there a difference between the 3.12rc4 from kernel.org and the 3.12.rc3+ from your git repository that might explain the difference? These are the two kernels I tested, with the results as presented. Kernel.org is apparently one release cycle (and one bug) ahead. Greetings, Thomas
On Wed, Oct 9, 2013 at 7:02 AM, Thomas Richter <thor@math.tu-berlin.de> wrote: > On 09.10.2013 00:00, Daniel Vetter wrote: >> >> >> My drm-intel git branch doesn't yet have the two patches that are meant to >> replace your ns2501 hack ... So I'm not too sure what exactly you've >> tested that made things magically better? > > > Is there a difference between the 3.12rc4 from kernel.org and the 3.12.rc3+ > from your git repository that might explain the difference? These are the > two kernels I tested, with the results as presented. Kernel.org is > apparently one release cycle (and one bug) ahead. drm-intel-nightly already contains tons of changes for 3.13. But nothing really comes to mind that might help out on your i830M. At least here on mine I didn't see any difference ... -Daniel
diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index 288a3a6..bfc1a65 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -490,36 +490,6 @@ int i915_reg_read_ioctl(struct drm_device *dev, return 0; } -static int i8xx_do_reset(struct drm_device *dev) -{ - struct drm_i915_private *dev_priv = dev->dev_private; - - if (IS_I85X(dev)) - return -ENODEV; - - I915_WRITE(D_STATE, I915_READ(D_STATE) | DSTATE_GFX_RESET_I830); - POSTING_READ(D_STATE); - - if (IS_I830(dev) || IS_845G(dev)) { - I915_WRITE(DEBUG_RESET_I830, - DEBUG_RESET_DISPLAY | - DEBUG_RESET_RENDER | - DEBUG_RESET_FULL); - POSTING_READ(DEBUG_RESET_I830); - msleep(1); - - I915_WRITE(DEBUG_RESET_I830, 0); - POSTING_READ(DEBUG_RESET_I830); - } - - msleep(1); - - I915_WRITE(D_STATE, I915_READ(D_STATE) & ~DSTATE_GFX_RESET_I830); - POSTING_READ(D_STATE); - - return 0; -} - static int i965_reset_complete(struct drm_device *dev) { u8 gdrst; @@ -621,7 +591,6 @@ int intel_gpu_reset(struct drm_device *dev) case 6: return gen6_do_reset(dev); case 5: return ironlake_do_reset(dev); case 4: return i965_do_reset(dev); - case 2: return i8xx_do_reset(dev); default: return -ENODEV; } }
At least on my i830M here it reliably results in hard system hangs nowadays. This is much worse than falling back to software rendering, so I think we should simply rip this out. After all we don't have any gpu reset for gen3 either, and there are a lot more of those still around. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> --- drivers/gpu/drm/i915/intel_uncore.c | 31 ------------------------------- 1 file changed, 31 deletions(-)