* Re: [git pull] drm merge for 3.9-rc1 @ 2013-02-27 22:36 Sedat Dilek 2013-02-27 23:06 ` Sedat Dilek 0 siblings, 1 reply; 33+ messages in thread From: Sedat Dilek @ 2013-02-27 22:36 UTC (permalink / raw) To: Chris Wilson; +Cc: Dave Airlie, DRI, intel-gfx, LKML, linux-next Hi, I am seeing this also on Linux-Next. /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! This seems to be hard reproducible... Laptop-LCD... Sandybridge Mobile-GT2. Is there a way to force the error? Possible patch see [1]. - Sedat - [1] https://patchwork.kernel.org/patch/2192721/ ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-27 22:36 [git pull] drm merge for 3.9-rc1 Sedat Dilek @ 2013-02-27 23:06 ` Sedat Dilek 2013-02-28 11:18 ` Chris Wilson 0 siblings, 1 reply; 33+ messages in thread From: Sedat Dilek @ 2013-02-27 23:06 UTC (permalink / raw) To: Chris Wilson; +Cc: Dave Airlie, DRI, intel-gfx, LKML, linux-next [-- Attachment #1: Type: text/plain, Size: 924 bytes --] On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: > Hi, > > I am seeing this also on Linux-Next. > > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381] > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout > (has irq: 1)! > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588] > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout > (has irq: 1)! > > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280] > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout > (has irq: 1)! > > This seems to be hard reproducible... > Laptop-LCD... Sandybridge Mobile-GT2. > > Is there a way to force the error? > > Possible patch see [1]. > > - Sedat - > > [1] https://patchwork.kernel.org/patch/2192721/ Hmm, I tried to apply the test-patch against next-20130227 and it fails building the i915 kernel-module. - Sedat - [-- Attachment #2: rebuild-with-intel_dp_aux_wait_done-fix.txt --] [-- Type: text/plain, Size: 8615 bytes --] LD drivers/gpu/drm/i915/built-in.o CC [M] drivers/gpu/drm/i915/i915_drv.o CC [M] drivers/gpu/drm/i915/i915_dma.o CC [M] drivers/gpu/drm/i915/i915_irq.o CC [M] drivers/gpu/drm/i915/i915_debugfs.o CC [M] drivers/gpu/drm/i915/i915_suspend.o CC [M] drivers/gpu/drm/i915/i915_gem.o CC [M] drivers/gpu/drm/i915/i915_gem_context.o CC [M] drivers/gpu/drm/i915/i915_gem_debug.o CC [M] drivers/gpu/drm/i915/i915_gem_evict.o CC [M] drivers/gpu/drm/i915/i915_gem_execbuffer.o CC [M] drivers/gpu/drm/i915/i915_gem_gtt.o CC [M] drivers/gpu/drm/i915/i915_gem_stolen.o CC [M] drivers/gpu/drm/i915/i915_gem_tiling.o CC [M] drivers/gpu/drm/i915/i915_sysfs.o CC [M] drivers/gpu/drm/i915/i915_trace_points.o CC [M] drivers/gpu/drm/i915/i915_ums.o CC [M] drivers/gpu/drm/i915/intel_display.o CC [M] drivers/gpu/drm/i915/intel_crt.o CC [M] drivers/gpu/drm/i915/intel_lvds.o CC [M] drivers/gpu/drm/i915/intel_bios.o CC [M] drivers/gpu/drm/i915/intel_ddi.o CC [M] drivers/gpu/drm/i915/intel_dp.o drivers/gpu/drm/i915/intel_dp.c: In function 'intel_dp_aux_wait_done': drivers/gpu/drm/i915/intel_dp.c:352:1: error: invalid storage class for function 'intel_dp_aux_ch' drivers/gpu/drm/i915/intel_dp.c:351:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] drivers/gpu/drm/i915/intel_dp.c:492:1: error: invalid storage class for function 'intel_dp_aux_native_write' drivers/gpu/drm/i915/intel_dp.c:525:1: error: invalid storage class for function 'intel_dp_aux_native_write_1' drivers/gpu/drm/i915/intel_dp.c:533:1: error: invalid storage class for function 'intel_dp_aux_native_read' drivers/gpu/drm/i915/intel_dp.c:572:1: error: invalid storage class for function 'intel_dp_i2c_aux_ch' drivers/gpu/drm/i915/intel_dp.c:669:1: error: invalid storage class for function 'intel_dp_i2c_init' drivers/gpu/drm/i915/intel_dp.c:845:13: error: invalid storage class for function 'ironlake_set_pll_edp' drivers/gpu/drm/i915/intel_dp.c:872:1: error: invalid storage class for function 'intel_dp_mode_set' drivers/gpu/drm/i915/intel_dp.c:985:13: error: invalid storage class for function 'ironlake_wait_panel_status' drivers/gpu/drm/i915/intel_dp.c:1004:13: error: invalid storage class for function 'ironlake_wait_panel_on' drivers/gpu/drm/i915/intel_dp.c:1010:13: error: invalid storage class for function 'ironlake_wait_panel_off' drivers/gpu/drm/i915/intel_dp.c:1016:13: error: invalid storage class for function 'ironlake_wait_panel_power_cycle' drivers/gpu/drm/i915/intel_dp.c:1027:13: error: invalid storage class for function 'ironlake_get_pp_control' drivers/gpu/drm/i915/intel_dp.c:1075:13: error: invalid storage class for function 'ironlake_panel_vdd_off_sync' drivers/gpu/drm/i915/intel_dp.c:1097:13: error: invalid storage class for function 'ironlake_panel_vdd_work' drivers/gpu/drm/i915/intel_dp.c:1244:13: error: invalid storage class for function 'ironlake_edp_pll_on' drivers/gpu/drm/i915/intel_dp.c:1270:13: error: invalid storage class for function 'ironlake_edp_pll_off' drivers/gpu/drm/i915/intel_dp.c:1325:13: error: invalid storage class for function 'intel_dp_get_hw_state' drivers/gpu/drm/i915/intel_dp.c:1374:13: error: invalid storage class for function 'intel_disable_dp' drivers/gpu/drm/i915/intel_dp.c:1390:13: error: invalid storage class for function 'intel_post_disable_dp' drivers/gpu/drm/i915/intel_dp.c:1400:13: error: invalid storage class for function 'intel_enable_dp' drivers/gpu/drm/i915/intel_dp.c:1419:13: error: invalid storage class for function 'intel_pre_enable_dp' drivers/gpu/drm/i915/intel_dp.c:1432:1: error: invalid storage class for function 'intel_dp_aux_native_read_retry' drivers/gpu/drm/i915/intel_dp.c:1457:1: error: invalid storage class for function 'intel_dp_get_link_status' drivers/gpu/drm/i915/intel_dp.c:1483:1: error: invalid storage class for function 'intel_dp_voltage_max' drivers/gpu/drm/i915/intel_dp.c:1496:1: error: invalid storage class for function 'intel_dp_pre_emphasis_max' drivers/gpu/drm/i915/intel_dp.c:1538:1: error: invalid storage class for function 'intel_get_adjust_train' drivers/gpu/drm/i915/intel_dp.c:1569:1: error: invalid storage class for function 'intel_gen4_signal_levels' drivers/gpu/drm/i915/intel_dp.c:1608:1: error: invalid storage class for function 'intel_gen6_edp_signal_levels' drivers/gpu/drm/i915/intel_dp.c:1636:1: error: invalid storage class for function 'intel_gen7_edp_signal_levels' drivers/gpu/drm/i915/intel_dp.c:1667:1: error: invalid storage class for function 'intel_hsw_signal_levels' drivers/gpu/drm/i915/intel_dp.c:1701:1: error: invalid storage class for function 'intel_dp_set_signal_levels' drivers/gpu/drm/i915/intel_dp.c:1728:1: error: invalid storage class for function 'intel_dp_set_link_train' drivers/gpu/drm/i915/intel_dp.c:1986:1: error: invalid storage class for function 'intel_dp_link_down' drivers/gpu/drm/i915/intel_dp.c:2065:1: error: invalid storage class for function 'intel_dp_get_dpcd' drivers/gpu/drm/i915/intel_dp.c:2096:1: error: invalid storage class for function 'intel_dp_probe_oui' drivers/gpu/drm/i915/intel_dp.c:2117:1: error: invalid storage class for function 'intel_dp_get_sink_irq' drivers/gpu/drm/i915/intel_dp.c:2131:1: error: invalid storage class for function 'intel_dp_handle_test_request' drivers/gpu/drm/i915/intel_dp.c:2195:1: error: invalid storage class for function 'intel_dp_detect_dpcd' drivers/gpu/drm/i915/intel_dp.c:2234:1: error: invalid storage class for function 'ironlake_dp_detect' drivers/gpu/drm/i915/intel_dp.c:2256:1: error: invalid storage class for function 'g4x_dp_detect' drivers/gpu/drm/i915/intel_dp.c:2284:1: error: invalid storage class for function 'intel_dp_get_edid' drivers/gpu/drm/i915/intel_dp.c:2310:1: error: invalid storage class for function 'intel_dp_get_edid_modes' drivers/gpu/drm/i915/intel_dp.c:2328:1: error: invalid storage class for function 'intel_dp_detect' drivers/gpu/drm/i915/intel_dp.c:2364:12: error: invalid storage class for function 'intel_dp_get_modes' drivers/gpu/drm/i915/intel_dp.c:2392:1: error: invalid storage class for function 'intel_dp_detect_audio' drivers/gpu/drm/i915/intel_dp.c:2408:1: error: invalid storage class for function 'intel_dp_set_property' drivers/gpu/drm/i915/intel_dp.c:2488:1: error: invalid storage class for function 'intel_dp_destroy' drivers/gpu/drm/i915/intel_dp.c:2522:2: error: initializer element is not constant drivers/gpu/drm/i915/intel_dp.c:2522:2: error: (near initialization for 'intel_dp_helper_funcs.mode_fixup') drivers/gpu/drm/i915/intel_dp.c:2523:2: error: initializer element is not constant drivers/gpu/drm/i915/intel_dp.c:2523:2: error: (near initialization for 'intel_dp_helper_funcs.mode_set') drivers/gpu/drm/i915/intel_dp.c:2528:2: error: initializer element is not constant drivers/gpu/drm/i915/intel_dp.c:2528:2: error: (near initialization for 'intel_dp_connector_funcs.detect') drivers/gpu/drm/i915/intel_dp.c:2530:2: error: initializer element is not constant drivers/gpu/drm/i915/intel_dp.c:2530:2: error: (near initialization for 'intel_dp_connector_funcs.set_property') drivers/gpu/drm/i915/intel_dp.c:2531:2: error: initializer element is not constant drivers/gpu/drm/i915/intel_dp.c:2531:2: error: (near initialization for 'intel_dp_connector_funcs.destroy') drivers/gpu/drm/i915/intel_dp.c:2535:2: error: initializer element is not constant drivers/gpu/drm/i915/intel_dp.c:2535:2: error: (near initialization for 'intel_dp_connector_helper_funcs.get_modes') drivers/gpu/drm/i915/intel_dp.c:2541:2: error: initializer element is not constant drivers/gpu/drm/i915/intel_dp.c:2541:2: error: (near initialization for 'intel_dp_enc_funcs.destroy') drivers/gpu/drm/i915/intel_dp.c:2545:1: error: invalid storage class for function 'intel_dp_hot_plug' drivers/gpu/drm/i915/intel_dp.c:2592:1: error: invalid storage class for function 'intel_dp_add_properties' drivers/gpu/drm/i915/intel_dp.c:2611:1: error: invalid storage class for function 'intel_dp_init_panel_power_sequencer' drivers/gpu/drm/i915/intel_dp.c:2696:1: error: invalid storage class for function 'intel_dp_init_panel_power_sequencer_registers' drivers/gpu/drm/i915/intel_dp.c:2957:1: error: expected declaration or statement at end of input drivers/gpu/drm/i915/intel_dp.c:2957:1: error: expected declaration or statement at end of input drivers/gpu/drm/i915/intel_dp.c: At top level: drivers/gpu/drm/i915/intel_dp.c:110:13: warning: 'intel_dp_link_down' used but never defined [enabled by default] make[1]: *** [drivers/gpu/drm/i915/intel_dp.o] Error 1 make: *** [_module_drivers/gpu/drm/i915] Error 2 [-- Attachment #3: 0001-drm-i915-Add-some-debugging-to-intel_dp_aux_wait_don.patch --] [-- Type: application/octet-stream, Size: 1048 bytes --] From 539d97d259f42ce9a453497c48322c7a24a67089 Mon Sep 17 00:00:00 2001 From: Sedat Dilek <sedat.dilek@gmail.com> Date: Wed, 27 Feb 2013 23:48:45 +0100 Subject: [PATCH] drm/i915: Add some debugging to intel_dp_aux_wait_done() Patch from [1]. [1] https://patchwork.kernel.org/patch/2192721/ --- drivers/gpu/drm/i915/intel_dp.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 01c4ec4..a31c6e1 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -338,9 +338,11 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq) msecs_to_jiffies(10)); else done = wait_for_atomic(C, 10) == 0; - if (!done) - DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n", - has_aux_irq); + if (!done) { + status = I915_READ_NOTRACE(ch_ctl); + DRM_ERROR("dp aux hw did not signal timeout (has irq: %i), status=%08x!\n", + has_aux_irq, status); + { #undef C return status; -- 1.8.1.4 ^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-27 23:06 ` Sedat Dilek @ 2013-02-28 11:18 ` Chris Wilson 2013-02-28 14:31 ` [Intel-gfx] " Paulo Zanoni 2013-02-28 17:07 ` Sedat Dilek 0 siblings, 2 replies; 33+ messages in thread From: Chris Wilson @ 2013-02-28 11:18 UTC (permalink / raw) To: Sedat Dilek; +Cc: Dave Airlie, DRI, intel-gfx, LKML, linux-next On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote: > On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: > > Hi, > > > > I am seeing this also on Linux-Next. > > > > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381] > > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout > > (has irq: 1)! > > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588] > > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout > > (has irq: 1)! > > > > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280] > > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout > > (has irq: 1)! > > > > This seems to be hard reproducible... > > Laptop-LCD... Sandybridge Mobile-GT2. > > > > Is there a way to force the error? > > > > Possible patch see [1]. > > > > - Sedat - > > > > [1] https://patchwork.kernel.org/patch/2192721/ That was: + if (!done) { + status = I915_READ_NOTRACE(ch_ctl); + DRM_ERROR("dp aux hw did not signal timeout (has irq: %i), status=%08x!\n", + has_aux_irq, status); + } You applied + if (!done) { + status = I915_READ_NOTRACE(ch_ctl); + DRM_ERROR("dp aux hw did not signal timeout (has irq: %i), status=%08x!\n", + has_aux_irq, status); + { That second '{' is the source of the compile error. -Chris -- Chris Wilson, Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1 2013-02-28 11:18 ` Chris Wilson @ 2013-02-28 14:31 ` Paulo Zanoni 2013-02-28 17:12 ` Sedat Dilek 2013-03-05 18:28 ` Imre Deak 2013-02-28 17:07 ` Sedat Dilek 1 sibling, 2 replies; 33+ messages in thread From: Paulo Zanoni @ 2013-02-28 14:31 UTC (permalink / raw) To: Chris Wilson, Sedat Dilek, Dave Airlie, DRI, intel-gfx, LKML, linux-next Hi 2013/2/28 Chris Wilson <chris@chris-wilson.co.uk>: > On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote: >> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: >> > Hi, >> > >> > I am seeing this also on Linux-Next. >> > >> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381] >> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >> > (has irq: 1)! >> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588] >> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >> > (has irq: 1)! >> > >> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280] >> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >> > (has irq: 1)! >> > >> > This seems to be hard reproducible... >> > Laptop-LCD... Sandybridge Mobile-GT2. >> > >> > Is there a way to force the error? >> > >> > Possible patch see [1]. >> > >> > - Sedat - >> > >> > [1] https://patchwork.kernel.org/patch/2192721/ > > That was: > > + if (!done) { > + status = I915_READ_NOTRACE(ch_ctl); > + DRM_ERROR("dp aux hw did not signal timeout (has irq: > %i), status=%08x!\n", > + has_aux_irq, status); > + } > > You applied > > + if (!done) { > + status = I915_READ_NOTRACE(ch_ctl); > + DRM_ERROR("dp aux hw did not signal timeout (has irq: > %i), status=%08x!\n", > + has_aux_irq, status); > + { In addition to this, after the problem happens can you please dump the registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either by running intel-reg-read (from intel-gpu-tools) or by changing the DRM_ERROR above to also print the result of I915_READ(0x44008) and I915_READ(0xC4008). If you conclude that the value of 0x44008 is 0x0 while the value of 0xC4008 is not, then this patch should help: https://patchwork.kernel.org/patch/2177841/ > > That second '{' is the source of the compile error. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1 2013-02-28 14:31 ` [Intel-gfx] " Paulo Zanoni @ 2013-02-28 17:12 ` Sedat Dilek 2013-02-28 17:29 ` Sedat Dilek 2013-03-05 18:28 ` Imre Deak 1 sibling, 1 reply; 33+ messages in thread From: Sedat Dilek @ 2013-02-28 17:12 UTC (permalink / raw) To: Paulo Zanoni; +Cc: Chris Wilson, Dave Airlie, DRI, intel-gfx, LKML, linux-next On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni <przanoni@gmail.com> wrote: > Hi > > 2013/2/28 Chris Wilson <chris@chris-wilson.co.uk>: >> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote: >>> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: >>> > Hi, >>> > >>> > I am seeing this also on Linux-Next. >>> > >>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381] >>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >>> > (has irq: 1)! >>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588] >>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >>> > (has irq: 1)! >>> > >>> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280] >>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >>> > (has irq: 1)! >>> > >>> > This seems to be hard reproducible... >>> > Laptop-LCD... Sandybridge Mobile-GT2. >>> > >>> > Is there a way to force the error? >>> > >>> > Possible patch see [1]. >>> > >>> > - Sedat - >>> > >>> > [1] https://patchwork.kernel.org/patch/2192721/ >> >> That was: >> >> + if (!done) { >> + status = I915_READ_NOTRACE(ch_ctl); >> + DRM_ERROR("dp aux hw did not signal timeout (has irq: >> %i), status=%08x!\n", >> + has_aux_irq, status); >> + } >> >> You applied >> >> + if (!done) { >> + status = I915_READ_NOTRACE(ch_ctl); >> + DRM_ERROR("dp aux hw did not signal timeout (has irq: >> %i), status=%08x!\n", >> + has_aux_irq, status); >> + { > > In addition to this, after the problem happens can you please dump the > registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either > by running intel-reg-read (from intel-gpu-tools) or by changing the > DRM_ERROR above to also print the result of I915_READ(0x44008) and > I915_READ(0xC4008). > Do I need a specific version of intel-gpu-tools? Ubuntu/precise has v1.2 in its archives - sufficient? Note: The error was twice after dozenz of Linux-Next kernel builds. - Sedat - [1] http://packages.ubuntu.com/precise/intel-gpu-tools > If you conclude that the value of 0x44008 is 0x0 while the value of > 0xC4008 is not, then this patch should help: > https://patchwork.kernel.org/patch/2177841/ > >> >> That second '{' is the source of the compile error. >> -Chris >> >> -- >> Chris Wilson, Intel Open Source Technology Centre >> _______________________________________________ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > -- > Paulo Zanoni ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1 2013-02-28 17:12 ` Sedat Dilek @ 2013-02-28 17:29 ` Sedat Dilek 2013-02-28 17:33 ` Paulo Zanoni 0 siblings, 1 reply; 33+ messages in thread From: Sedat Dilek @ 2013-02-28 17:29 UTC (permalink / raw) To: Paulo Zanoni; +Cc: Chris Wilson, Dave Airlie, DRI, intel-gfx, LKML, linux-next On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: > On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni <przanoni@gmail.com> wrote: >> Hi >> >> 2013/2/28 Chris Wilson <chris@chris-wilson.co.uk>: >>> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote: >>>> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: >>>> > Hi, >>>> > >>>> > I am seeing this also on Linux-Next. >>>> > >>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381] >>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >>>> > (has irq: 1)! >>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588] >>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >>>> > (has irq: 1)! >>>> > >>>> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280] >>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >>>> > (has irq: 1)! >>>> > >>>> > This seems to be hard reproducible... >>>> > Laptop-LCD... Sandybridge Mobile-GT2. >>>> > >>>> > Is there a way to force the error? >>>> > >>>> > Possible patch see [1]. >>>> > >>>> > - Sedat - >>>> > >>>> > [1] https://patchwork.kernel.org/patch/2192721/ >>> >>> That was: >>> >>> + if (!done) { >>> + status = I915_READ_NOTRACE(ch_ctl); >>> + DRM_ERROR("dp aux hw did not signal timeout (has irq: >>> %i), status=%08x!\n", >>> + has_aux_irq, status); >>> + } >>> >>> You applied >>> >>> + if (!done) { >>> + status = I915_READ_NOTRACE(ch_ctl); >>> + DRM_ERROR("dp aux hw did not signal timeout (has irq: >>> %i), status=%08x!\n", >>> + has_aux_irq, status); >>> + { >> >> In addition to this, after the problem happens can you please dump the >> registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either >> by running intel-reg-read (from intel-gpu-tools) or by changing the >> DRM_ERROR above to also print the result of I915_READ(0x44008) and >> I915_READ(0xC4008). >> > > Do I need a specific version of intel-gpu-tools? > Ubuntu/precise has v1.2 in its archives - sufficient? > Note: The error was twice after dozenz of Linux-Next kernel builds. > > - Sedat - > > [1] http://packages.ubuntu.com/precise/intel-gpu-tools > Installed intel-gpu-tools. # intel_reg_read Usage: intel_reg_read [-f | addr] -f : read back full range of registers. WARNING! This could be danger to hang the machine! addr : in 0xXXXX format # intel_reg_read 0x44008 Couldn't map MMIO region: Resource temporarily unavailable [ 368.281707] intel_reg_read:3657 conflicting memory types f0000000-f0400000 uncached-minus<->write-combining [ 381.521912] intel_reg_read:3658 conflicting memory types f0000000-f0400000 uncached-minus<->write-combining [ 401.136291] intel_reg_read:3659 conflicting memory types f0000000-f0400000 uncached-minus<->write-combining Wrong i-g-t version? Missing enabled kernel-config option? Boot with i915 debug enabled? - Sedat - >> If you conclude that the value of 0x44008 is 0x0 while the value of >> 0xC4008 is not, then this patch should help: >> https://patchwork.kernel.org/patch/2177841/ >> >>> >>> That second '{' is the source of the compile error. >>> -Chris >>> >>> -- >>> Chris Wilson, Intel Open Source Technology Centre >>> _______________________________________________ >>> Intel-gfx mailing list >>> Intel-gfx@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx >> >> >> >> -- >> Paulo Zanoni ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1 2013-02-28 17:29 ` Sedat Dilek @ 2013-02-28 17:33 ` Paulo Zanoni 2013-02-28 17:59 ` Sedat Dilek 0 siblings, 1 reply; 33+ messages in thread From: Paulo Zanoni @ 2013-02-28 17:33 UTC (permalink / raw) To: sedat.dilek; +Cc: Chris Wilson, Dave Airlie, DRI, intel-gfx, LKML, linux-next Hi 2013/2/28 Sedat Dilek <sedat.dilek@gmail.com>: > On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: >> On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni <przanoni@gmail.com> wrote: >>> Hi >>> >>> 2013/2/28 Chris Wilson <chris@chris-wilson.co.uk>: >>>> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote: >>>>> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: >>>>> > Hi, >>>>> > >>>>> > I am seeing this also on Linux-Next. >>>>> > >>>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381] >>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >>>>> > (has irq: 1)! >>>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588] >>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >>>>> > (has irq: 1)! >>>>> > >>>>> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280] >>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >>>>> > (has irq: 1)! >>>>> > >>>>> > This seems to be hard reproducible... >>>>> > Laptop-LCD... Sandybridge Mobile-GT2. >>>>> > >>>>> > Is there a way to force the error? >>>>> > >>>>> > Possible patch see [1]. >>>>> > >>>>> > - Sedat - >>>>> > >>>>> > [1] https://patchwork.kernel.org/patch/2192721/ >>>> >>>> That was: >>>> >>>> + if (!done) { >>>> + status = I915_READ_NOTRACE(ch_ctl); >>>> + DRM_ERROR("dp aux hw did not signal timeout (has irq: >>>> %i), status=%08x!\n", >>>> + has_aux_irq, status); >>>> + } >>>> >>>> You applied >>>> >>>> + if (!done) { >>>> + status = I915_READ_NOTRACE(ch_ctl); >>>> + DRM_ERROR("dp aux hw did not signal timeout (has irq: >>>> %i), status=%08x!\n", >>>> + has_aux_irq, status); >>>> + { >>> >>> In addition to this, after the problem happens can you please dump the >>> registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either >>> by running intel-reg-read (from intel-gpu-tools) or by changing the >>> DRM_ERROR above to also print the result of I915_READ(0x44008) and >>> I915_READ(0xC4008). >>> >> >> Do I need a specific version of intel-gpu-tools? >> Ubuntu/precise has v1.2 in its archives - sufficient? >> Note: The error was twice after dozenz of Linux-Next kernel builds. >> >> - Sedat - >> >> [1] http://packages.ubuntu.com/precise/intel-gpu-tools >> > > Installed intel-gpu-tools. > > # intel_reg_read > Usage: intel_reg_read [-f | addr] > -f : read back full range of registers. > WARNING! This could be danger to hang the machine! > addr : in 0xXXXX format > > # intel_reg_read 0x44008 > Couldn't map MMIO region: Resource temporarily unavailable > > [ 368.281707] intel_reg_read:3657 conflicting memory types > f0000000-f0400000 uncached-minus<->write-combining > [ 381.521912] intel_reg_read:3658 conflicting memory types > f0000000-f0400000 uncached-minus<->write-combining > [ 401.136291] intel_reg_read:3659 conflicting memory types > f0000000-f0400000 uncached-minus<->write-combining > > Wrong i-g-t version? Missing enabled kernel-config option? Boot with > i915 debug enabled? Just build the version from git and it should work (http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/). > > - Sedat - > >>> If you conclude that the value of 0x44008 is 0x0 while the value of >>> 0xC4008 is not, then this patch should help: >>> https://patchwork.kernel.org/patch/2177841/ >>> >>>> >>>> That second '{' is the source of the compile error. >>>> -Chris >>>> >>>> -- >>>> Chris Wilson, Intel Open Source Technology Centre >>>> _______________________________________________ >>>> Intel-gfx mailing list >>>> Intel-gfx@lists.freedesktop.org >>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx >>> >>> >>> >>> -- >>> Paulo Zanoni -- Paulo Zanoni ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1 2013-02-28 17:33 ` Paulo Zanoni @ 2013-02-28 17:59 ` Sedat Dilek 2013-03-01 16:30 ` Sedat Dilek 0 siblings, 1 reply; 33+ messages in thread From: Sedat Dilek @ 2013-02-28 17:59 UTC (permalink / raw) To: Paulo Zanoni; +Cc: Chris Wilson, Dave Airlie, DRI, intel-gfx, LKML, linux-next [-- Attachment #1: Type: text/plain, Size: 4509 bytes --] On Thu, Feb 28, 2013 at 6:33 PM, Paulo Zanoni <przanoni@gmail.com> wrote: > Hi > > 2013/2/28 Sedat Dilek <sedat.dilek@gmail.com>: >> On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: >>> On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni <przanoni@gmail.com> wrote: >>>> Hi >>>> >>>> 2013/2/28 Chris Wilson <chris@chris-wilson.co.uk>: >>>>> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote: >>>>>> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: >>>>>> > Hi, >>>>>> > >>>>>> > I am seeing this also on Linux-Next. >>>>>> > >>>>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381] >>>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >>>>>> > (has irq: 1)! >>>>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588] >>>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >>>>>> > (has irq: 1)! >>>>>> > >>>>>> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280] >>>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >>>>>> > (has irq: 1)! >>>>>> > >>>>>> > This seems to be hard reproducible... >>>>>> > Laptop-LCD... Sandybridge Mobile-GT2. >>>>>> > >>>>>> > Is there a way to force the error? >>>>>> > >>>>>> > Possible patch see [1]. >>>>>> > >>>>>> > - Sedat - >>>>>> > >>>>>> > [1] https://patchwork.kernel.org/patch/2192721/ >>>>> >>>>> That was: >>>>> >>>>> + if (!done) { >>>>> + status = I915_READ_NOTRACE(ch_ctl); >>>>> + DRM_ERROR("dp aux hw did not signal timeout (has irq: >>>>> %i), status=%08x!\n", >>>>> + has_aux_irq, status); >>>>> + } >>>>> >>>>> You applied >>>>> >>>>> + if (!done) { >>>>> + status = I915_READ_NOTRACE(ch_ctl); >>>>> + DRM_ERROR("dp aux hw did not signal timeout (has irq: >>>>> %i), status=%08x!\n", >>>>> + has_aux_irq, status); >>>>> + { >>>> >>>> In addition to this, after the problem happens can you please dump the >>>> registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either >>>> by running intel-reg-read (from intel-gpu-tools) or by changing the >>>> DRM_ERROR above to also print the result of I915_READ(0x44008) and >>>> I915_READ(0xC4008). >>>> >>> >>> Do I need a specific version of intel-gpu-tools? >>> Ubuntu/precise has v1.2 in its archives - sufficient? >>> Note: The error was twice after dozenz of Linux-Next kernel builds. >>> >>> - Sedat - >>> >>> [1] http://packages.ubuntu.com/precise/intel-gpu-tools >>> >> >> Installed intel-gpu-tools. >> >> # intel_reg_read >> Usage: intel_reg_read [-f | addr] >> -f : read back full range of registers. >> WARNING! This could be danger to hang the machine! >> addr : in 0xXXXX format >> >> # intel_reg_read 0x44008 >> Couldn't map MMIO region: Resource temporarily unavailable >> >> [ 368.281707] intel_reg_read:3657 conflicting memory types >> f0000000-f0400000 uncached-minus<->write-combining >> [ 381.521912] intel_reg_read:3658 conflicting memory types >> f0000000-f0400000 uncached-minus<->write-combining >> [ 401.136291] intel_reg_read:3659 conflicting memory types >> f0000000-f0400000 uncached-minus<->write-combining >> >> Wrong i-g-t version? Missing enabled kernel-config option? Boot with >> i915 debug enabled? > > Just build the version from git and it should work > (http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/). > NO. $ git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools intel-gpu-tools-git $ cd intel-gpu-tools-git/ $ ./autogen.sh --disable-dumper <--- requires swig2.0 and python >=3.x $ sudo ./tools/intel_reg_read 0x44008 0x44008 : 0x0 $ sudo ./tools/intel_reg_read 0xC4008 0xC4008 : 0x0 $ sudo ./tools/intel_reg_dumper > /tmp/intel_reg_dumper.txt <--- see attachment Does this help you? - Sedat - >> >> - Sedat - >> >>>> If you conclude that the value of 0x44008 is 0x0 while the value of >>>> 0xC4008 is not, then this patch should help: >>>> https://patchwork.kernel.org/patch/2177841/ >>>> >>>>> >>>>> That second '{' is the source of the compile error. >>>>> -Chris >>>>> >>>>> -- >>>>> Chris Wilson, Intel Open Source Technology Centre >>>>> _______________________________________________ >>>>> Intel-gfx mailing list >>>>> Intel-gfx@lists.freedesktop.org >>>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx >>>> >>>> >>>> >>>> -- >>>> Paulo Zanoni > > > > -- > Paulo Zanoni [-- Attachment #2: intel_reg_dumper.txt --] [-- Type: text/plain, Size: 14942 bytes --] PGETBL_CTL: 0x00000000 GEN6_INSTDONE_1: 0xfffffffe GEN6_INSTDONE_2: 0xffffffff CPU_VGACNTRL: 0x80000000 (disabled) DIGITAL_PORT_HOTPLUG_CNTRL: 0x00000000 RR_HW_CTL: 0x00000000 (low 0, high 0) FDI_PLL_BIOS_0: 0xffffffff FDI_PLL_BIOS_1: 0xffffffff FDI_PLL_BIOS_2: 0xffffffff DISPLAY_PORT_PLL_BIOS_0: 0xffffffff DISPLAY_PORT_PLL_BIOS_1: 0xffffffff DISPLAY_PORT_PLL_BIOS_2: 0xffffffff FDI_PLL_FREQ_CTL: 0xffffffff PIPEACONF: 0xc0000010 (enabled, active, pf-pd, rotate 0, 8bpc) HTOTAL_A: 0x05cd0555 (1366 active, 1486 total) HBLANK_A: 0x05cd0555 (1366 start, 1486 end) HSYNC_A: 0x05a50585 (1414 start, 1446 end) VTOTAL_A: 0x031702ff (768 active, 792 total) VBLANK_A: 0x031702ff (768 start, 792 end) VSYNC_A: 0x03060301 (770 start, 775 end) VSYNCSHIFT_A: 0x00000000 PIPEASRC: 0x055502ff (1366, 768) PIPEA_DATA_M1: 0x7e19e420 (TU 64, val 0x19e420 1696800) PIPEA_DATA_N1: 0x0020f580 (val 0x20f580 2160000) PIPEA_DATA_M2: 0x00000000 (TU 1, val 0x0 0) PIPEA_DATA_N2: 0x00000000 (val 0x0 0) PIPEA_LINK_M1: 0x0001142c (val 0x1142c 70700) PIPEA_LINK_N1: 0x00041eb0 (val 0x41eb0 270000) PIPEA_LINK_M2: 0x00000000 (val 0x0 0) PIPEA_LINK_N2: 0x00000000 (val 0x0 0) DSPACNTR: 0xd8004400 (enabled) DSPABASE: 0x00000000 DSPASTRIDE: 0x00001600 (88) DSPASURF: 0x0047a000 DSPATILEOFF: 0x00000000 (0, 0) PIPEBCONF: 0x00000000 (disabled, inactive, pf-pd, rotate 0, 8bpc) HTOTAL_B: 0x00000000 (1 active, 1 total) HBLANK_B: 0x00000000 (1 start, 1 end) HSYNC_B: 0x00000000 (1 start, 1 end) VTOTAL_B: 0x00000000 (1 active, 1 total) VBLANK_B: 0x00000000 (1 start, 1 end) VSYNC_B: 0x00000000 (1 start, 1 end) VSYNCSHIFT_B: 0x00000000 PIPEBSRC: 0x00000000 (1, 1) PIPEB_DATA_M1: 0x00000000 (TU 1, val 0x0 0) PIPEB_DATA_N1: 0x00000000 (val 0x0 0) PIPEB_DATA_M2: 0x00000000 (TU 1, val 0x0 0) PIPEB_DATA_N2: 0x00000000 (val 0x0 0) PIPEB_LINK_M1: 0x00000000 (val 0x0 0) PIPEB_LINK_N1: 0x00000000 (val 0x0 0) PIPEB_LINK_M2: 0x00000000 (val 0x0 0) PIPEB_LINK_N2: 0x00000000 (val 0x0 0) DSPBCNTR: 0x00004000 (disabled) DSPBBASE: 0x00000000 DSPBSTRIDE: 0x00000000 (0) DSPBSURF: 0x00000000 DSPBTILEOFF: 0x00000000 (0, 0) PIPECCONF: 0x00000000 (disabled, inactive, pf-pd, rotate 0, 8bpc) HTOTAL_C: 0x00000000 (1 active, 1 total) HBLANK_C: 0x00000000 (1 start, 1 end) HSYNC_C: 0x00000000 (1 start, 1 end) VTOTAL_C: 0x00000000 (1 active, 1 total) VBLANK_C: 0x00000000 (1 start, 1 end) VSYNC_C: 0x00000000 (1 start, 1 end) VSYNCSHIFT_C: 0x00000000 PIPECSRC: 0x00000000 (1, 1) PIPEC_DATA_M1: 0x00000000 (TU 1, val 0x0 0) PIPEC_DATA_N1: 0x00000000 (val 0x0 0) PIPEC_DATA_M2: 0x00000000 (TU 1, val 0x0 0) PIPEC_DATA_N2: 0x00000000 (val 0x0 0) PIPEC_LINK_M1: 0x00000000 (val 0x0 0) PIPEC_LINK_N1: 0x00000000 (val 0x0 0) PIPEC_LINK_M2: 0x00000000 (val 0x0 0) PIPEC_LINK_N2: 0x00000000 (val 0x0 0) DSPCCNTR: 0x00000000 (disabled) DSPCBASE: 0x00000000 DSPCSTRIDE: 0x00000000 (0) DSPCSURF: 0x00000000 DSPCTILEOFF: 0x00000000 (0, 0) PFA_CTL_1: 0x00000000 (disable, auto_scale yes, auto_scale_cal no, v_filter enable, vadapt disable, mode least, filter_sel programmed,chroma pre-filter disable, vert3tap auto, v_inter_invert field 1) PFA_CTL_2: 0x00007e80 (vscale 0.988281) PFA_CTL_3: 0x00003f40 (vscale initial phase 0.494141) PFA_CTL_4: 0x00007d54 (hscale 0.979126) PFA_WIN_POS: 0x00000000 (0, 0) PFA_WIN_SIZE: 0x00000000 (0, 0) PFB_CTL_1: 0x00000000 (disable, auto_scale yes, auto_scale_cal no, v_filter enable, vadapt disable, mode least, filter_sel programmed,chroma pre-filter disable, vert3tap auto, v_inter_invert field 1) PFB_CTL_2: 0x00000000 (vscale 0.000000) PFB_CTL_3: 0x00000000 (vscale initial phase 0.000000) PFB_CTL_4: 0x00000000 (hscale 0.000000) PFB_WIN_POS: 0x00000000 (0, 0) PFB_WIN_SIZE: 0x00000000 (0, 0) PFC_CTL_1: 0x00000000 (disable, auto_scale yes, auto_scale_cal no, v_filter enable, vadapt disable, mode least, filter_sel programmed,chroma pre-filter disable, vert3tap auto, v_inter_invert field 1) PFC_CTL_2: 0x00000000 (vscale 0.000000) PFC_CTL_3: 0x00000000 (vscale initial phase 0.000000) PFC_CTL_4: 0x00000000 (hscale 0.000000) PFC_WIN_POS: 0x00000000 (0, 0) PFC_WIN_SIZE: 0x00000000 (0, 0) PCH_DREF_CONTROL: 0x00001402 (cpu source disable, ssc_source enable, nonspread_source enable, superspread_source disable, ssc4_mode downspread, ssc1 enable, ssc4 disable) PCH_RAWCLK_FREQ: 0x0000007d (FDL_TP1 timer 0.5us, FDL_TP2 timer 1.5us, freq 125) PCH_DPLL_TMR_CFG: 0x0271186a PCH_SSC4_PARMS: 0x01204860 PCH_SSC4_AUX_PARMS: 0x000029c5 PCH_DPLL_SEL: 0x00000008 (TransA DPLL enable (DPLL A), TransB DPLL disable (DPLL (null))) PCH_DPLL_ANALOG_CTL: 0x00008000 PCH_DPLL_A: 0x88046004 (enable, sdvo high speed no, mode LVDS, p2 Div 14, FPA0 P1 3, FPA1 P1 3, refclk SSC, sdvo/hdmi mul 1) PCH_DPLL_B: 0x04800080 (disable, sdvo high speed no, mode (null), p2 (null), FPA0 P1 8, FPA1 P1 8, refclk default 120Mhz, sdvo/hdmi mul 1) PCH_FPA0: 0x00021007 (n = 2, m1 = 16, m2 = 7) PCH_FPA1: 0x00021007 (n = 2, m1 = 16, m2 = 7) PCH_FPB0: 0x00030d07 (n = 3, m1 = 13, m2 = 7) PCH_FPB1: 0x00030d07 (n = 3, m1 = 13, m2 = 7) TRANS_HTOTAL_A: 0x05cd0555 (1366 active, 1486 total) TRANS_HBLANK_A: 0x05cd0555 (1366 start, 1486 end) TRANS_HSYNC_A: 0x05a50585 (1414 start, 1446 end) TRANS_VTOTAL_A: 0x031702ff (768 active, 792 total) TRANS_VBLANK_A: 0x031702ff (768 start, 792 end) TRANS_VSYNC_A: 0x03060301 (770 start, 775 end) TRANS_VSYNCSHIFT_A: 0x00000000 TRANSA_DATA_M1: 0x00000000 (TU 1, val 0x0 0) TRANSA_DATA_N1: 0x00000000 (val 0x0 0) TRANSA_DATA_M2: 0x00000000 (TU 1, val 0x0 0) TRANSA_DATA_N2: 0x00000000 (val 0x0 0) TRANSA_DP_LINK_M1: 0x00000000 (val 0x0 0) TRANSA_DP_LINK_N1: 0x00000000 (val 0x0 0) TRANSA_DP_LINK_M2: 0x00000000 (val 0x0 0) TRANSA_DP_LINK_N2: 0x00000000 (val 0x0 0) TRANS_HTOTAL_B: 0x00000000 (1 active, 1 total) TRANS_HBLANK_B: 0x00000000 (1 start, 1 end) TRANS_HSYNC_B: 0x00000000 (1 start, 1 end) TRANS_VTOTAL_B: 0x00000000 (1 active, 1 total) TRANS_VBLANK_B: 0x00000000 (1 start, 1 end) TRANS_VSYNC_B: 0x00000000 (1 start, 1 end) TRANS_VSYNCSHIFT_B: 0x00000000 TRANSB_DATA_M1: 0x00000000 (TU 1, val 0x0 0) TRANSB_DATA_N1: 0x00000000 (val 0x0 0) TRANSB_DATA_M2: 0x00000000 (TU 1, val 0x0 0) TRANSB_DATA_N2: 0x00000000 (val 0x0 0) TRANSB_DP_LINK_M1: 0x00000000 (val 0x0 0) TRANSB_DP_LINK_N1: 0x00000000 (val 0x0 0) TRANSB_DP_LINK_M2: 0x00000000 (val 0x0 0) TRANSB_DP_LINK_N2: 0x00000000 (val 0x0 0) TRANS_HTOTAL_C: 0x00000000 (1 active, 1 total) TRANS_HBLANK_C: 0x00000000 (1 start, 1 end) TRANS_HSYNC_C: 0x00000000 (1 start, 1 end) TRANS_VTOTAL_C: 0x00000000 (1 active, 1 total) TRANS_VBLANK_C: 0x00000000 (1 start, 1 end) TRANS_VSYNC_C: 0x00000000 (1 start, 1 end) TRANS_VSYNCSHIFT_C: 0x00000000 TRANSC_DATA_M1: 0x00000000 (TU 1, val 0x0 0) TRANSC_DATA_N1: 0x00000000 (val 0x0 0) TRANSC_DATA_M2: 0x00000000 (TU 1, val 0x0 0) TRANSC_DATA_N2: 0x00000000 (val 0x0 0) TRANSC_DP_LINK_M1: 0x00000000 (val 0x0 0) TRANSC_DP_LINK_N1: 0x00000000 (val 0x0 0) TRANSC_DP_LINK_M2: 0x00000000 (val 0x0 0) TRANSC_DP_LINK_N2: 0x00000000 (val 0x0 0) TRANSACONF: 0xc0000000 (enable, active, progressive) TRANSBCONF: 0x00000000 (disable, inactive, progressive) TRANSCCONF: 0x00000000 (disable, inactive, progressive) FDI_TXA_CTL: 0xb0044000 (enable, train pattern not train, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing enable, FDI PLL enable, scrambing enable, master mode disable) FDI_TXB_CTL: 0x00040000 (disable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing enable, FDI PLL disable, scrambing enable, master mode disable) FDI_TXC_CTL: 0x00000000 (disable, train pattern pattern_1, voltage swing 0.4V,pre-emphasis 0dB, port width X1, enhanced framing disable, FDI PLL disable, scrambing enable, master mode disable) FDI_RXA_CTL: 0x80002350 (enable, train pattern not train, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL enable,FS ecc disable, FE ecc disable, FS err report enable, FE err report enable,scrambing enable, enhanced framing enable, PCDClk) FDI_RXB_CTL: 0x00000040 (disable, train pattern pattern_1, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL disable,FS ecc disable, FE ecc disable, FS err report disable, FE err report disable,scrambing enable, enhanced framing enable, RawClk) FDI_RXC_CTL: 0x00000040 (disable, train pattern pattern_1, port width X1, 8bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL disable,FS ecc disable, FE ecc disable, FS err report disable, FE err report disable,scrambing enable, enhanced framing enable, RawClk) DPAFE_BMFUNC: 0x8e97861c DPAFE_DL_IREFCAL0: 0x00000b6d DPAFE_DL_IREFCAL1: 0x00000b6d DPAFE_DP_IREFCAL: 0x00000965 PCH_DSPCLK_GATE_D: 0x100000a0 PCH_DSP_CHICKEN1: 0x00600000 PCH_DSP_CHICKEN2: 0x0260c000 PCH_DSP_CHICKEN3: 0x00000000 FDI_RXA_MISC: 0x00200090 (FDI Delay 144) FDI_RXB_MISC: 0x00000080 (FDI Delay 128) FDI_RXC_MISC: 0x00000080 (FDI Delay 128) FDI_RXA_TUSIZE1: 0x7e000000 FDI_RXA_TUSIZE2: 0x7e000000 FDI_RXB_TUSIZE1: 0x7e000000 FDI_RXB_TUSIZE2: 0x7e000000 FDI_RXC_TUSIZE1: 0x7e000000 FDI_RXC_TUSIZE2: 0x7e000000 FDI_PLL_CTL_1: 0x7e000000 FDI_PLL_CTL_2: 0x7e000000 FDI_RXA_IIR: 0x00000000 FDI_RXA_IMR: 0x000008ff FDI_RXB_IIR: 0x00000000 FDI_RXB_IMR: 0x000008ff PCH_ADPA: 0x00f40000 (disabled, transcoder A, -hsync, -vsync) HDMIB: 0x0000001c (disabled pipe A 8bpc SDVO DVI audio disabled +vsync +hsync detected) HDMIC: 0x00000018 (disabled pipe A 8bpc SDVO DVI audio disabled +vsync +hsync non-detected) HDMID: 0x00000018 (disabled pipe A 8bpc SDVO DVI audio disabled +vsync +hsync non-detected) PCH_LVDS: 0x813003c2 (enabled, pipe A, 24 bit, 1 channel) CPU_eDP_A: 0x00000018 PCH_DP_B: 0x00000004 PCH_DP_C: 0x00000000 PCH_DP_D: 0x00000000 TRANS_DP_CTL_A: 0x60000018 (disable port none 8bpc +vsync +hsync) TRANS_DP_CTL_B: 0x60000018 (disable port none 8bpc +vsync +hsync) TRANS_DP_CTL_C: 0x60000018 (disable port none 8bpc +vsync +hsync) BLC_PWM_CPU_CTL2: 0x80000000 BLC_PWM_CPU_CTL: 0x000003fc BLC_PWM_PCH_CTL1: 0x80000000 BLC_PWM_PCH_CTL2: 0x12281228 PCH_PP_STATUS: 0xc0000008 (on, ready, sequencing idle) PCH_PP_CONTROL: 0xabcd0003 (blacklight disabled, power down on reset, panel on) PCH_PP_ON_DELAYS: 0x01901388 PCH_PP_OFF_DELAYS: 0x012c1388 PCH_PP_DIVISOR: 0x00186905 PORT_DBG: 0x00000000 (HW DRRS off) RC6_RESIDENCY_TIME: 0x6858843c RC6p_RESIDENCY_TIME: 0x00000000 RC6pp_RESIDENCY_TIME: 0x00000000 GEN6_RP_CONTROL: 0x00000d91 (enabled) GEN6_RPNSWREQ: 0x0e000000 GEN6_RP_DOWN_TIMEOUT: 0x000f4240 GEN6_RP_INTERRUPT_LIMITS: 0x17070000 GEN6_RP_UP_THRESHOLD: 0x0000e808 GEN6_RP_UP_EI: 0x000101d0 GEN6_RP_DOWN_EI: 0x00055730 GEN6_RP_IDLE_HYSTERSIS: 0x0000000a GEN6_RC_STATE: 0x00000000 GEN6_RC_CONTROL: 0x88040000 GEN6_RC1_WAKE_RATE_LIMIT: 0x03e80000 GEN6_RC6_WAKE_RATE_LIMIT: 0x0028001e GEN6_RC_EVALUATION_INTERVAL: 0x0001e848 GEN6_RC_IDLE_HYSTERSIS: 0x00000019 GEN6_RC_SLEEP: 0x00000000 GEN6_RC1e_THRESHOLD: 0x000003e8 GEN6_RC6_THRESHOLD: 0x0000c350 GEN6_RC_VIDEO_FREQ: 0x18000000 GEN6_PMIER: 0x00000070 GEN6_PMIMR: 0x00000000 GEN6_PMINTRMSK: 0x00000000 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1 2013-02-28 17:59 ` Sedat Dilek @ 2013-03-01 16:30 ` Sedat Dilek 0 siblings, 0 replies; 33+ messages in thread From: Sedat Dilek @ 2013-03-01 16:30 UTC (permalink / raw) To: Paulo Zanoni; +Cc: Chris Wilson, Dave Airlie, DRI, intel-gfx, LKML, linux-next On Thu, Feb 28, 2013 at 6:59 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: > On Thu, Feb 28, 2013 at 6:33 PM, Paulo Zanoni <przanoni@gmail.com> wrote: >> Hi >> >> 2013/2/28 Sedat Dilek <sedat.dilek@gmail.com>: >>> On Thu, Feb 28, 2013 at 6:12 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: >>>> On Thu, Feb 28, 2013 at 3:31 PM, Paulo Zanoni <przanoni@gmail.com> wrote: >>>>> Hi >>>>> >>>>> 2013/2/28 Chris Wilson <chris@chris-wilson.co.uk>: >>>>>> On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote: >>>>>>> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: >>>>>>> > Hi, >>>>>>> > >>>>>>> > I am seeing this also on Linux-Next. >>>>>>> > >>>>>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381] >>>>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >>>>>>> > (has irq: 1)! >>>>>>> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588] >>>>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >>>>>>> > (has irq: 1)! >>>>>>> > >>>>>>> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280] >>>>>>> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >>>>>>> > (has irq: 1)! >>>>>>> > >>>>>>> > This seems to be hard reproducible... >>>>>>> > Laptop-LCD... Sandybridge Mobile-GT2. >>>>>>> > >>>>>>> > Is there a way to force the error? >>>>>>> > >>>>>>> > Possible patch see [1]. >>>>>>> > >>>>>>> > - Sedat - >>>>>>> > >>>>>>> > [1] https://patchwork.kernel.org/patch/2192721/ >>>>>> >>>>>> That was: >>>>>> >>>>>> + if (!done) { >>>>>> + status = I915_READ_NOTRACE(ch_ctl); >>>>>> + DRM_ERROR("dp aux hw did not signal timeout (has irq: >>>>>> %i), status=%08x!\n", >>>>>> + has_aux_irq, status); >>>>>> + } >>>>>> >>>>>> You applied >>>>>> >>>>>> + if (!done) { >>>>>> + status = I915_READ_NOTRACE(ch_ctl); >>>>>> + DRM_ERROR("dp aux hw did not signal timeout (has irq: >>>>>> %i), status=%08x!\n", >>>>>> + has_aux_irq, status); >>>>>> + { >>>>> >>>>> In addition to this, after the problem happens can you please dump the >>>>> registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either >>>>> by running intel-reg-read (from intel-gpu-tools) or by changing the >>>>> DRM_ERROR above to also print the result of I915_READ(0x44008) and >>>>> I915_READ(0xC4008). >>>>> >>>> >>>> Do I need a specific version of intel-gpu-tools? >>>> Ubuntu/precise has v1.2 in its archives - sufficient? >>>> Note: The error was twice after dozenz of Linux-Next kernel builds. >>>> >>>> - Sedat - >>>> >>>> [1] http://packages.ubuntu.com/precise/intel-gpu-tools >>>> >>> >>> Installed intel-gpu-tools. >>> >>> # intel_reg_read >>> Usage: intel_reg_read [-f | addr] >>> -f : read back full range of registers. >>> WARNING! This could be danger to hang the machine! >>> addr : in 0xXXXX format >>> >>> # intel_reg_read 0x44008 >>> Couldn't map MMIO region: Resource temporarily unavailable >>> >>> [ 368.281707] intel_reg_read:3657 conflicting memory types >>> f0000000-f0400000 uncached-minus<->write-combining >>> [ 381.521912] intel_reg_read:3658 conflicting memory types >>> f0000000-f0400000 uncached-minus<->write-combining >>> [ 401.136291] intel_reg_read:3659 conflicting memory types >>> f0000000-f0400000 uncached-minus<->write-combining >>> >>> Wrong i-g-t version? Missing enabled kernel-config option? Boot with >>> i915 debug enabled? >> >> Just build the version from git and it should work >> (http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/). >> > > NO. > > $ git clone git://anongit.freedesktop.org/xorg/app/intel-gpu-tools > intel-gpu-tools-git > > $ cd intel-gpu-tools-git/ > > $ ./autogen.sh --disable-dumper <--- requires swig2.0 and python >=3.x > > $ sudo ./tools/intel_reg_read 0x44008 > 0x44008 : 0x0 > > $ sudo ./tools/intel_reg_read 0xC4008 > 0xC4008 : 0x0 > > $ sudo ./tools/intel_reg_dumper > /tmp/intel_reg_dumper.txt <--- see attachment > > Does this help you? > Ping Paulo. - Sedat - > - Sedat - > > >>> >>> - Sedat - >>> >>>>> If you conclude that the value of 0x44008 is 0x0 while the value of >>>>> 0xC4008 is not, then this patch should help: >>>>> https://patchwork.kernel.org/patch/2177841/ >>>>> >>>>>> >>>>>> That second '{' is the source of the compile error. >>>>>> -Chris >>>>>> >>>>>> -- >>>>>> Chris Wilson, Intel Open Source Technology Centre >>>>>> _______________________________________________ >>>>>> Intel-gfx mailing list >>>>>> Intel-gfx@lists.freedesktop.org >>>>>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx >>>>> >>>>> >>>>> >>>>> -- >>>>> Paulo Zanoni >> >> >> >> -- >> Paulo Zanoni ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [Intel-gfx] [git pull] drm merge for 3.9-rc1 2013-02-28 14:31 ` [Intel-gfx] " Paulo Zanoni 2013-02-28 17:12 ` Sedat Dilek @ 2013-03-05 18:28 ` Imre Deak 1 sibling, 0 replies; 33+ messages in thread From: Imre Deak @ 2013-03-05 18:28 UTC (permalink / raw) To: Paulo Zanoni Cc: Chris Wilson, Sedat Dilek, Dave Airlie, DRI, intel-gfx, LKML, linux-next On Thu, 2013-02-28 at 11:31 -0300, Paulo Zanoni wrote: > Hi > > 2013/2/28 Chris Wilson <chris@chris-wilson.co.uk>: > > On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote: > >> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: > >> > Hi, > >> > > >> > I am seeing this also on Linux-Next. > >> > > >> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381] > >> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout > >> > (has irq: 1)! > >> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588] > >> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout > >> > (has irq: 1)! > >> > > >> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280] > >> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout > >> > (has irq: 1)! > >> > > >> > This seems to be hard reproducible... > >> > Laptop-LCD... Sandybridge Mobile-GT2. > >> > > >> > Is there a way to force the error? > >> > > >> > Possible patch see [1]. > >> > > >> > - Sedat - > >> > > >> > [1] https://patchwork.kernel.org/patch/2192721/ > > > > That was: > > > > + if (!done) { > > + status = I915_READ_NOTRACE(ch_ctl); > > + DRM_ERROR("dp aux hw did not signal timeout (has irq: > > %i), status=%08x!\n", > > + has_aux_irq, status); > > + } > > > > You applied > > > > + if (!done) { > > + status = I915_READ_NOTRACE(ch_ctl); > > + DRM_ERROR("dp aux hw did not signal timeout (has irq: > > %i), status=%08x!\n", > > + has_aux_irq, status); > > + { > > In addition to this, after the problem happens can you please dump the > registers 0x44008 (DEIIR) and 0xC4008 (SDEIIR)? You can do this either > by running intel-reg-read (from intel-gpu-tools) or by changing the > DRM_ERROR above to also print the result of I915_READ(0x44008) and > I915_READ(0xC4008). > > If you conclude that the value of 0x44008 is 0x0 while the value of > 0xC4008 is not, then this patch should help: > https://patchwork.kernel.org/patch/2177841/ I can trigger the bug on an ILK consistently by calling udelay(400) just before 'I915_WRITE(SDEIIR, pch_iir);' in ironlake_irq_handler() until the first timeout. Afterwards SDEIIR will contain SDE_AUXD and DEIIR will be 0 and no more AUXD events will be serviced. With Paolo's patch I can't trigger the bug even with the udelay being in place. --Imre > > > > > That second '{' is the source of the compile error. > > -Chris > > > > -- > > Chris Wilson, Intel Open Source Technology Centre > > _______________________________________________ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-28 11:18 ` Chris Wilson 2013-02-28 14:31 ` [Intel-gfx] " Paulo Zanoni @ 2013-02-28 17:07 ` Sedat Dilek 1 sibling, 0 replies; 33+ messages in thread From: Sedat Dilek @ 2013-02-28 17:07 UTC (permalink / raw) To: Chris Wilson, Sedat Dilek, Dave Airlie, DRI, intel-gfx, LKML, linux-next On Thu, Feb 28, 2013 at 12:18 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote: > On Thu, Feb 28, 2013 at 12:06:28AM +0100, Sedat Dilek wrote: >> On Wed, Feb 27, 2013 at 11:36 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote: >> > Hi, >> > >> > I am seeing this also on Linux-Next. >> > >> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.202381] >> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >> > (has irq: 1)! >> > /var/log/kern.log:Feb 27 22:52:35 fambox kernel: [ 28.210588] >> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >> > (has irq: 1)! >> > >> > /var/log/kern.log.1:Feb 22 07:36:04 fambox kernel: [ 27.408280] >> > [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout >> > (has irq: 1)! >> > >> > This seems to be hard reproducible... >> > Laptop-LCD... Sandybridge Mobile-GT2. >> > >> > Is there a way to force the error? >> > >> > Possible patch see [1]. >> > >> > - Sedat - >> > >> > [1] https://patchwork.kernel.org/patch/2192721/ > > That was: > > + if (!done) { > + status = I915_READ_NOTRACE(ch_ctl); > + DRM_ERROR("dp aux hw did not signal timeout (has irq: > %i), status=%08x!\n", > + has_aux_irq, status); > + } > > You applied > > + if (!done) { > + status = I915_READ_NOTRACE(ch_ctl); > + DRM_ERROR("dp aux hw did not signal timeout (has irq: > %i), status=%08x!\n", > + has_aux_irq, status); > + { > > That second '{' is the source of the compile error. Schei**e, OK I try with a v2. A hint how to force the error? - Sedat - > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre ^ permalink raw reply [flat|nested] 33+ messages in thread
* [git pull] drm merge for 3.9-rc1 @ 2013-02-26 0:05 Dave Airlie 2013-02-26 1:22 ` Linus Torvalds ` (2 more replies) 0 siblings, 3 replies; 33+ messages in thread From: Dave Airlie @ 2013-02-26 0:05 UTC (permalink / raw) To: torvalds; +Cc: DRI mailing list, linux-kernel [-- Attachment #1: Type: TEXT/PLAIN, Size: 64500 bytes --] Hi Linus, This is the main drm pull for the 3.9-rc1 merge, and my chance to have my email published verbatim as an article by the worst news site ever. So up front, this has a massive merge conflict in drivers/gpu/drm/radeon/evergreen_cs.c I've fixed it up in drm-next-merged in the same tree, I fixed up some small ordering issues in my merge as well, however they aren't important if you want the fun of doing a major conflict resolution. Highlights: TI LCD controller KMS driver TI OMAP KMS driver merged from staging drop gma500 stub driver the fbcon locking fixes the vgacon dirty like zebra fix. open firmware videomode and hdmi common code helpers major locking rework for kms object handling - pageflip/cursor won't block on polling anymore! fbcon helper and prime helper cleanups i915: all over the map, haswell power well enhancements, valleyview macro horrors cleaned up, killing lots of legacy GTT code, radeon: CS ioctl unification, deprecated UMS support, gpu reset rework, VM fixes nouveau: reworked thermal code, external dp/tmds encoder support (anx9805), fences sleep instead of polling, exynos: all over the driver fixes. Dave. The following changes since commit 1589a3e7777631ff56dd58cd7dcdf275185e62b5: Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media (2013-02-06 08:36:12 +1100) are available in the git repository at: git://people.freedesktop.org/~airlied/linux.git drm-next for you to fetch changes up to 28ee46184fc64591e286fa0355845e09c39e2a84: Merge branch 'drm/hdmi-for-3.9' of git://anongit.freedesktop.org/tegra/linux into drm-next (2013-02-24 12:39:42 +1000) ---------------------------------------------------------------- Aaron Plattner (3): drm: add prime helpers drm/nouveau: use prime helpers drm/radeon: use prime helpers Ajay Kumar (1): drm/exynos: Add device tree based discovery support for G2D Alan Cox (1): fb: rework locking to fix lock ordering on takeover Alex Deucher (29): drm/radeon: add additional reset flags drm/radeon: add a bios scratch asic hung helper drm/radeon: rework GPU reset on r6xx/r7xx drm/radeon: rework GPU reset on evergreen drm/radeon: rework GPU reset on cayman/TN drm/radeon: rework GPU reset on cayman/TN drm/radeon: use status regs to determine what to reset (6xx/7xx) drm/radeon: use status regs to determine what to reset (evergreen) drm/radeon: use status regs to determine what to reset (cayman) drm/radeon: use status regs to determine what to reset (si) drm/radeon: halt engines before disabling MC (6xx/7xx) drm/radeon: halt engines before disabling MC (evergreen) drm/radeon: halt engines before disabling MC (cayman/TN) drm/radeon: halt engines before disabling MC (si) drm/radeon: use the reset mask to determine if rings are hung drm/radeon: don't reset the MC on IGPs/APUs drm/radeon: use IBs for VM page table updates v2 drm/radeon: switch back to using the DMA ring for VM PT updates drm/radeon: add Oland chip family drm/radeon: fill in gpu init for Oland drm/radeon: add ucode loading support for Oland drm/radeon: radeon-asic updates for Oland drm/radeon: add Oland pci ids drm/radeon/dce6: fix display powergating drm/radeon: fix multi-head power profile stability on BTC+ asics drm/radeon: remove overzealous warning in hdmi handling drm/radeon: add a asic callback to get the xclk drm/radeon: switch get_gpu_clock() to a callback (v2) drm/radeon: properly validate the atpx interface Andy Gross (2): drm/omap: Add PM capabilities drm/omap: Add OMAP5 support Ben Hutchings (1): nouveau: ACPI support depends on X86 and X86_PLATFORM_DEVICES Ben Skeggs (55): nvd0/therm: implement more appropriate pwm fan control functions drm/nouveau/therm: fix various style issues, make more consistent drm/nouveau/therm: collect fan tach info in common fan constructor drm/nva3/therm: add support for hardware fan tachometer drm/nvd0/therm: add support for hardware fan tachometer drm/nouveau/therm: add interfaces to allow forcing off pwm fan control drm/nouveau/therm: cleanly separate pwm control logic from therm drm/nvc0/bus: report useful data on mmio fault drm/nouveau/therm: better transitions and debug logging drm/nouveau/hwmon: s/fan0/fan1/ drm/nouveau/hwmon: create hwmon attributes under hwmon device in sysfs drm/nouveau: remove legacy vbios type detection drm/nouveau: remove some more unnecessary legacy bios code drm/nouveau/bios: add support for parsing xpio table data drm/nouveau/bios: rename DCB_GPIO_PWM_FAN to DCB_GPIO_FAN drm/nouveau/therm: don't try pwm/toggle control if GPIO_FAN is input drm/nv50/disp: fix missing sor modectrl sync flags drm/nouveau/fifo/nvc0: improve interrupt handler somewhat drm/nouveau/core: basic event interface between core and drm drm/nouveau/disp/nv04: implement a base display object class drm/nouveau/disp: port vblank handling to event interface drm/nouveau/fifo/nvc0-: use interrupt 31 as an event trigger drm/nouveau/fifo/nv84: support user event trigger drm/nouveau/fifo/nvc0: bash some magic reg to make uevent interrupt work drm/nouveau/fence/nv84-: put processes to sleep while waiting on fences drm/nouveau/drm: store full dcb gpio function data in connector drm/nouveau/gpio: pass number of on-die gpio lines to base drm/nouveau/gpio: use event interfaces for interrupt signalling drm/nouveau/gpio/nve0: interrupt regs moved on kepler apparently drm/nv84/fence: access fences with full virtual address, not offset drm/nv84-/fence: abstract class emit/sync functions to virt+sequence drm/nv17/fence: split from nv10 code drm/nouveau/fence: make internal hooks part of the context drm/nv84-/fence: prepare for emit/sync support of sysram sequences drm/nv50/graph: avoid touching 400724, it doesn't exist drm/nouveau/i2c: handle i2c/aux mux outside of port lookup function drm/nouveau: store i2c port pointer directly in nouveau_encoder drm/nouveau/bios: parse external transmitter type if off-chip drm/nouveau/i2c: fix a bit of a thinko in nv_wri2cr helper functions drm/nouveau/i2c: aux channels not necessarily on nvio drm/nouveau/i2c: extend type to 16-bits, add lookup-by-type function drm/nouveau/bios: store a type/mask hash in parsed dcb data drm/nv50/devinit: reverse the logic for running encoder init scripts drm/nv50-/disp: 0x0000 is a valid udisp config value drm/nouveau/i2c: create proper chipset-specific class implementations drm/nv50-/disp: handle supervisor tasks from workqueue drm/nv50-/disp: move DP link training to core and train from supervisor drm/nv50-/kms: remove unnecessary wait-for-completion points drm/nv50-/disp: initial work towards supporting external encoders drm/nv50-/disp: initial supervisor support for off-chip encoders drm/nv50: initial kms support for off-chip TMDS/DP encoders drm/nouveau/i2c: add support for ddc/aux, and dp link training on anx9805 drm/nv50/disp: handle multiple actions from one set of supervisor intrs drm/nvd0/disp: handle multiple actions from one set of supervisor intrs drm/nv50-/kms: remove UPDATE methods after each encoder disconnect Ben Widawsky (28): drm/i915: BUG() if fences are used on unsupported platform drm/i915: Bug on unsupported swizzled platforms drm/i915: Missed conversion to gtt_pte_t drm/i915: Move even more gtt code to i915_gem_gtt drm/i915: Move GSM mapping into dev_priv drm/i915: Make GSM void drm/i915: Kill gtt_end drm/i915: Mappable_end can't ever be > end drm/i915: Remove gtt_mappable_total drm/i915: Create a gtt structure drm/i915: Remove use on gma_bus_addr on gen6+ drm/i915: Remove use of gtt_mappable_entries drm/i915: Cut out the infamous ILK w/a from AGP layer drm/i915: Remove scratch page from shared drm/i915: Needs_dmar, not agp/intel: Add gma_bus_addr drm/i915: Implement WaVSRefCountFullforceMissDisable drm/i915: Error state should print /sys/kernel/debug drm/i915: Add probe and remove to the gtt ops drm/i915: remove intel_gtt structure drm/i915: Reclaim GTT space for failed PPGTT drm/i915: Fix CAGF for HSW drm/i915: Fix RC6VIDS encode/decode drm/i915: Clarify HW context size logic drm/i915: Fix gen2 mappable calculations drm/i915: Extract ring init from hw_init drm/i915/ctx: Remove bad invariant drm/i915: Print the hw context status is debugfs Bjorn Helgaas (4): drm/pci: Use the standard #defines for PCIe Link Capability bits drm/pci: Set all supported speeds in speed cap mask for pre-3.0 devices drm/pci: Use PCI Express Capability accessors drm/pci: define drm_pcie_get_speed_cap_mask() only when CONFIG_PCI=y Borislav Petkov (1): x86/intel/cacheinfo: Shut up annoying warning Carsten Emde (1): drm: Load EDID: Explain better how to write your own EDID firmware Changlong Xie (1): drm/i915: gen6_gmch_remove can be static Chris Metcalf (1): drm: fix compile failure by including <linux/swiotlb.h> Chris Wilson (32): drm/i915/debugfs: Prune a couple of superfluous leading zeros from bo domains drm: Introduce drm_mm_create_block() drm: Introduce an iterator over holes in the drm_mm range manager drm/i915: Fix detection of base of stolen memory drm/i915: Avoid clearing preallocated regions from the GTT drm/i915: Delay allocation of stolen space for FBC drm/i915: Allow objects to be created with no backing pages, but stolen space drm/i915: Support readback of stolen objects upon error drm/i915: Introduce i915_gem_object_create_stolen() drm/i915: Allocate fbcon from stolen memory drm/i915: Allocate ringbuffers from stolen memory drm/i915: Allocate overlay registers from stolen memory drm/i915: Use a slab for object allocation drm/i915: Tighten the checks for invalid relocation domains drm/i915: Remove check for conflicting relocation write-domains drm/i915: Reduce memory pressure during shrinker by preallocating swizzle pages drm/i915: Open-code i915_gpu_idle() for handling seqno wrapping drm/i915: Access to snooped system memory through the GTT is incoherent drm/i915: Clear the stolen fb before enabling drm/i915: Return the real error code from intel_set_mode() drm/i915: Add a debug interface to forcibly evict and shrink our object caches drm/i915: Bail if we attempt to allocate pages for a purged object drm/i915: Mark a temporary allocation for copy-from-user as such drm/i915: Take the handle idr spinlock once for looking up the exec objects drm/i915: Move the execbuffer objects list from the stack into the tracker drm/i915: Use the reloc.handle as an index into the execbuffer array drm/i915: Only insert the mb() before updating the fence parameter drm/i915: Only apply the mb() when flushing the GTT domain during a finish drm/i915: Only run idle processing from i915_gem_retire_requests_worker drm/udl: Inline memcmp() for RLE compression of xfer drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK drm/i915: Handle untiled planes when computing their offsets Christian König (1): drm/radeon: Deprecate UMS support v2 Cong Ding (2): staging: omapdrm/omap_gem_dmabuf.c: fix memory leakage drm/nouveau: remove unnecessary null pointer check from nouveau_fence_new Damien Lespiau (10): drm/i915: Fix dieing -> dying typo drm/i915: Cleanup SHOTPLUG_CTL status bits definitions drm/i915/hdmi: Read the HPD status before trying to read the EDID drm/i915/dp: Read the HPD status before trying to read the DPCD drm/i915/dp: Log the DPCD only if we have successfully retrieved one drm/i915: Implement ibx_digital_port_connected() for IBX drm/i915: Remove stale comment about intel_dp_detect() drm/i915: Fix a typo in a intel_modeset_stage_output_state() comment drm/i915: Preserve the FDI line reversal override bit on CPT drm/i915: Preserve the DDI link reversal configuration Dan Carpenter (1): drm/nouveau/disp: sizeof() wrong pointer Daniel Kurtz (1): drm: make frame duration time calculation more precise Daniel Vetter (121): drm/i915: remove duplicate register #defines drm/i915: add encoder->pre_pll_enable callback drm/i915: replace ad-hoc dual-link lvds checks drm/i915: move is_dual_link_lvds to intel_lvds.c drm/i915: track is_dual_link in intel_lvds drm/i915: add intel_lvds->reg drm/i915: move intel_update_lvds to intel_lvds->pre_pll_enable drm/i915: enable intel_lvds->pre_pll_enable for ilk+, too drm/i915: simplify shmem pwrite/pread slowpath handling drm/i915: optimize the shmem_pwrite slowpath handling drm/i915: optimize ilk/snb irq handler drm/i915: fixup sparse warnings drm/i915: haswell has the same irq handlers as ivb drm/i915: don't handle PIPE_LEGACY_BLC_EVENT_STATUS on vlv drm/i915: setup the hangcheck timer early drm/i915: reorder setup sequence to have irqs for output setup drm/i915: extract gmbus_wait_hw_status drm/i915: wire up gmbus irq handler drm/i915: use the gmbus irq for waits drm/i915: use gmbus irq to wait for gmbus idle drm/i915: wire up do aux channel done interrupt drm/i915: irq-drive the dp aux communication drm/i915: use _NOTRACE for gmbus/dp aux wait loops drm/i915: rip out pre-DDI stuff from haswell_crtc_mode_set drm/i915: move set_pll_edp to intel_dp.c drm/i915: rip out pre-production ilk cpu edp w/a drm/i915: use wait_for_vblank instead of msleep(17) drm/i915: WARN on !crtc in intel_dp_link_down drm/i915: drop unnecessary clearing of pch dp transcoder timings drm/i915: extract common link_m_n helpers drm/i915: Fixup hpd irq register setup ordering drm/i915: rework locking for intel_dpio|sbi_read|write drm/i915: clean up PIPECONF bpc #defines drm/i915: fixup overlay stolen memory leak drm/i915: wake up all pageflip waiters drm/i915: Allow userspace to hint that the relocations were known drm/i915: move dev_priv->mm out of line drm/i915: extract hangcheck/reset/error_state state into substruct drm/i915: move wedged to the other gpu error handling stuff drm/i915: fix reset handling in the throttle ioctl drm/i915: clear up wedged transitions drm: review locking rules in drm_crtc.c drm/doc: integrate drm_crtc.c kerneldoc drm/<drivers>: reorder framebuffer init sequence drm/vmwgfx: reorder framebuffer init sequence drm/gma500: move fbcon restore to lastclose drm/nouveau: protect evo_wait/evo_kick sections with a channel mutex drm/nouveau: try to protect nbo->pin_refcount drm/<drivers>: Unified handling of unimplemented fb->create_handle drm: encapsulate crtc->set_config calls drm: add drm_modeset_lock|unlock_all drm/i915: use drm_modeset_lock_all drm/gma500: use drm_modeset_lock_all drm/ast: use drm_modeset_lock_all drm/shmobile: use drm_modeset_lock_all drm/vmwgfx: use drm_modeset_lock_all omapdrm: use modeset_lock_all drm: add per-crtc locks drm: only take the crtc lock for ->cursor_set drm: only take the crtc lock for ->cursor_move drm: revamp locking around fb creation/destruction drm: create drm_framebuffer_lookup drm: revamp framebuffer cleanup interfaces drm: reference framebuffers which are on the idr drm: nest modeset locks within fpriv->fbs_lock drm: push modeset_lock_all into ->fb_create driver callbacks drm: don't take modeset locks in getfb ioctl drm: fb refcounting for dirtyfb_ioctl drm: refcounting for sprite framebuffers drm: refcounting for crtc framebuffers drm/i915: dump refcount into framebuffer debugfs file drm/vmwgfx: add proper framebuffer refcounting drm: optimize drm_framebuffer_remove drm: only grab the crtc lock for pageflips drm: don't hold crtc mutexes for connector ->detect callbacks drm/doc: updates for new framebuffer lifetime rules drm/fb_helper: check whether fbcon is bound drm/i915: create a race-free reset detection drm/i915: clarify concurrent hang detect/gpu reset consistency drm/i915: fixup sbi_read/write locking drm/i915: fixup per-crtc locking in intel_release_load_detect_pipe drm/i915: move modeset checks out of save/restore_modeset_reg drm/i915: extract ums suspend/resume into i915_ums.c drm/i915: dont save/restore VGA state for kms drm/i915: move DP save/restore into i915_ums.c drm/i915: vfuncs for gtt_clear_range/insert_entries drm/i915: vfuncs for ppgtt drm/i915: pte_encode is gen6+ drm/i915: extract hw ppgtt setup/cleanup code drm/i915: kill cargo-culted locking from power well code drm/i915: don't run hsw power well code on !hsw drm/i915: dynamic Haswell display power well support Revert "drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S" drm: review locking for drm_fb_helper_restore_fbdev_mode drm/fb-helper: kill drm_fb_helper_restore drm/fb-helper: unexport drm_fb_helper_panic drm/fb-helper: unexport drm_fb_helper_single_fb_probe drm/tegra: don't set up initial fbcon config twice drm/fb-helper: don't disable everything in initial_config drm/i915: rip out helper->disable noop functions drm/fb-helper: fixup set_config semantics drm/fb-helper: directly call set_par from the hotplug handler drm/fb-helper: streamline drm_fb_helper_single_fb_probe drm/<drivers>: simplify ->fb_probe callback drm/fb-helper: improve kerneldoc drm/fb-helper: don't sleep for screen unblank when an oopps is in progress drm/fb-helper: remove unused members of struct drm_fb_helper drm/i915: write backlight harder drm/i915: unify HDMI/DP hpd definitions omapdrm: only take crtc->mutex in crtc callbacks omapdrm: simplify locking in the fb debugfs file drm/cma-helper: fixup compilation drm: Don't set the plane->fb to NULL on successfull set_plane drm/cma-helper: fixup compilation drm: Don't set the plane->fb to NULL on successfull set_plane drm/i915: detect wrong MCH watermark values drm/i915: remove bogus mutex_unlock from error-path drm/i915: Use HAS_L3_GPU_CACHE in i915_gem_l3_remap drm/i915: inverted brightness quirk for Acer Aspire 4736Z intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets drm/i915: Revert hdmi HDP pin checks Dave Airlie (27): Merge tag 'drm-intel-next-2012-12-21' of git://people.freedesktop.org/~danvet/drm-intel into drm-next Merge branch 'drm-kms-locking' of git://people.freedesktop.org/~danvet/drm-intel into drm-next vgacon/vt: clear buffer attributes when we load a 512 character font (v2) fbcon: don't lose the console font across generic->chip driver switch drm/usb: bind driver to correct device drm/udl: make usage as a console safer Merge tag 'drm-intel-next-2013-02-01' of git://people.freedesktop.org/~danvet/drm-intel into drm-next drm/udl: disable fb_defio by default fbcon: fix locking harder Revert "Revert "console: implement lockdep support for console_lock"" Merge branch 'fbcon-locking-fixes' of ssh://people.freedesktop.org/~airlied/linux into drm-next Merge branch 'console-fixes' into drm-next Merge branch 'udl-fixes' into drm-next Merge tag 'of_videomode_helper' of git://git.pengutronix.de/git/str/linux into drm-next Merge branch 'drm-next-3.9' of git://people.freedesktop.org/~agd5f/linux into drm-next Merge branch 'for-airlied' of git://people.freedesktop.org/~mlankhorst/linux into drm-next Merge branch 'drm-fb-helper' of git://people.freedesktop.org/~danvet/drm into drm-next Merge branch 'omapdrm-next' of git://people.freedesktop.org/~robclark/linux into drm-next Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next Merge branch 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next Merge branch 'drm-next-3.9' of git://people.freedesktop.org/~agd5f/linux into drm-next Merge branch 'tilcdc-next' of git://people.freedesktop.org/~robclark/linux into drm-next Merge branch 'exynos-drm-next' of git://git.kernel.org/.../daeinki/drm-exynos into drm-next Merge branch 'drm/tegra-for-3.9' of git://anongit.freedesktop.org/tegra/linux into drm-next Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next Merge branch 'drm/hdmi-for-3.9' of git://anongit.freedesktop.org/tegra/linux into drm-next Dexuan Cui (1): drm/i915: Remove duplicate and unused register #defines in i915_reg.h Egbert Eich (1): drm/i915: Remove pch_rq_mask from struct drm_i915_private. Emil Velikov (1): drm/nouveau: set legacy bios data before parsing the structure H. Peter Anvin (1): x86, doc: Boot protocol 2.12 is in 3.8 Ilija Hadzic (12): drm/radeon: remove unecessary assignment drm/radeon: remove unused prototype from radeon_cs drm/radeon: fix formatting drm/radeon: implement common cs packet parse function drm/radeon: use common cs packet parse function drm/radeon: factor out cs_next_is_pkt3_nop function drm/radeon: refactor vline packet parsing function drm/radeon: add a check to wait_reg_mem command drm/radeon: rename r100_cs_dump_packet to radeon_cs_dump_packet drm/radeon: pull out common next_reloc function drm/radeon: use common next_reloc function drm/radeon: consolidate redundant macros and constants Imre Deak (4): drm/i915: merge get_gtt_alignment/get_unfenced_gtt_alignment() drm/i915: merge {i965, sandybridge}_write_fence_reg() drm/i915: use gtt_get_size() instead of open coding it drm/i915: don't clflush gem objects in stolen memory Inki Dae (2): drm/exynos: fix iommu address allocation order drm/exynos: consider exception case to fb handle creation Jan Beulich (1): x86-64: Replace left over sti/cli in ia32 audit exit code Jani Nikula (4): drm/i915: add quirk to invert brightness on eMachines G725 drm/i915: add quirk to invert brightness on eMachines e725 drm/i915: add quirk to invert brightness on Packard Bell NCL20 drm/i915: add missing \n to UTS_RELEASE in the error_state Jerome Glisse (1): radeon/kms: cleanup async dma packet checking Lee, Chun-Yi (1): gpu: remove gma500 stub driver Luis R. Rodriguez (1): i915: convert struct spinlock to spinlock_t Maarten Lankhorst (9): drm/vmwgfx: always use ttm_bo_is_reserved drm/nouveau: increase reservation sequence every retry drm/ttm: remove lru_lock around ttm_bo_reserve drm/ttm: cleanup ttm_eu_reserve_buffers handling drm/ttm: add ttm_bo_reserve_slowpath drm/ttm: use ttm_bo_reserve_slowpath_nolru in ttm_eu_reserve_buffers, v2 drm/nouveau: use ttm_bo_reserve_slowpath in validate_init, v2 drm/ttm: unexport ttm_bo_wait_unreserved drm: shut up invalid edid messages Marcin Slusarz (20): drm/nouveau: split fifo interrupt handler drm/nouveau: use pr_cont drm/nouveau: prepare for reporting channel owner drm/nouveau: report channel owner in error messages drm/nouveau: share fence structures between nv10+ and nv50 implementations drm/nouveau: mark nv_printk_ as printf-like function drm/nouveau/bios: tiny debugging messages fixes drm/nouveau: quiet static-related sparse noise drm/nouveau/fan: fix selection of fan speed when fan->get returns an error drm/nvc0/graph: remove redundant null checks drm/nouveau: use drm_property_create_range helper drm/nouveau: use kmemdup for edid allocation/copying drm/nouveau: handle backlight_device_register failure drm/nouveau/therm: always initialize alarm_program_lock drm/nouveau: report channel owner in ioctl error paths drm/nouveau/therm: turn on fan only when threshold hit in positive direction drm/nv40/therm: reset temperature sensor on init drm/nouveau/therm: use workqueue to shutdown the machine drm/nouveau/therm: reduce stack usage of nouveau_therm_ic_ctor drm/nouveau: restore debugfs/vbios.rom support Martin Peres (11): drm/nouveau/fan: add toggle fan support drm/nouveau/bios: parse fan bump/slow periods, and trip points drm/nouveau/fan: obey fan bump/slow periods as defined by vbios drm/nouveau/therm: implement automatic fan management drm/nouveau/pbus: add a PBUS subdev that hands IRQs to the right subdevs drm/nv41/bus: report useful data on mmio fault drm/nouveau/therm: implement support for temperature alarms drm/nouveau/hwmon: add missing alarm thresholds drm/nouveau/doc: document the sysfs thermal management interface drm/nouveau/therm: force a minimum hysteresis on temperature alarm thresholds drm/nouveau/fan: handle the cases where we are outside of the linear zone Mika Kuoppala (14): drm/i915: Add debugfs entry to read/write next_seqno drm/i915: Fix debugfs seqno info print to use uint drm/i915: Split intel_ring_begin drm/i915: Add intel_ring_handle_seqno wrap drm/i915: Don't emit semaphore wait if wrap happened drm/i915: Set initial seqno value close to wrap boundary drm/i915: Introduce ring set_seqno drm/i915: Initialize hardware semaphore state on ring init drm/i915: Always clear semaphore mboxes on seqno wrap drm/i915: Introduce i915_gem_set_seqno() drm/i915: Make next_seqno debugs entry to use i915_gem_set_seqno drm/i915: use gem_set_seqno() on hardware init drm/i915: disable shared panel fitter for pipe drm/i915: clean up panel fitter handling in lvds Patrik Jakobsson (3): drm/i915: Set i9xx lvds clock limits according to specifications drm/i915: Set i9xx sdvo clock limits according to specifications gma500: Fix n, m1 and m2 clock limits for sdvo and lvds Paulo Zanoni (18): drm/i915: intel_prepare_ddi_buffers should be static drm/i915: remove Haswell code from ironlake_fdi_pll_enable drm/i915: add HAS_DDI check drm/i915: invert the log inside intel_prepare_ddi drm/i915: kill intel_dp_link_clock() drm/i915: be less verbose when handling gmbus/aux irqs drm/i915: check for the PCH when setting pch_transcoder drm/i915: remove leftover display.update_wm assignment drm/i915: add intel_dp_set_signal_levels drm/i915: don't save/restore DSPARB on gen5+ drm/i915: fix intel_init_power_wells drm/i915: only disable enabled planes on intel_fb_restore_mode drm/i915: set TRANSCODER_EDP even earlier drm/i915: turn on the power well before suspending drm/i915: don't send DP "idle" pattern before "normal" on HSW PORT_A drm/i915: check the power down well on assert_pipe() drm/i915: add ibx_irq_postinstall drm: don't add inferred modes for monitors that don't support them Peter Huewe (1): staging/omapdrm: Use kmemdup rather than duplicating its implementation Rahul Sharma (3): drm/exynos: add display-mode-check operation to exynos_mixer_ops struct drm/exynos: implement display-mode-check callback in mixer driver drm/exynos: mixer: set correct mode for range of resolutions Rob Clark (11): drm/i2c: give i2c it's own Kconfig drm/omap: move out of staging drm/omap: remove fbdev debug enter/leave hooks drm: small fix in drm_send_vblank_event() drm/cma: add debugfs helpers drm: i2c encoder helper wrappers drm/nouveau: use i2c encoder helper wrappers drm/tilcdc: add TI LCD Controller DRM driver (v4) drm/i2c: nxp-tda998x (v3) drm/tilcdc: add encoder slave (v2) drm/tilcdc: add support for LCD panels (v5) Sachin Kamat (2): drm/i915: Remove duplicate inclusion of drm/drm_edid.h drm/exynos: Add missing braces around sizeof Sean Paul (1): drm/exynos: hdmi: support extra resolutions using drm_display_mode timings Stefan de Konink (1): drm/nouveau: Fix DPMS 1 on G4 Snowball, from snow white to coal black. Steffen Trumtrar (7): viafb: rename display_timing to via_display_timing video: add display_timing and videomode video: add of helper for display timings/videomode fbmon: add videomode helpers fbmon: add of_videomode helpers drm_modes: add videomode helpers drm_modes: add of_videomode helpers Takashi Iwai (1): fb: Yet another band-aid for fixing lockdep mess Thierry Reding (18): drm: Allow vblank support without DRIVER_HAVE_IRQ drm: Remove duplicate drm_mode_cea_vic() drm: Move mode tables to drm_edid.c drm: Add some missing forward declarations video: Add generic HDMI infoframe helpers drm: Add HDMI infoframe helpers drm: Add EDID helper documentation drm/tegra: Use generic HDMI infoframe helpers drm/radeon: Use generic HDMI infoframe helpers drm: Add consistency check for page-flipping drm/tegra: Remove bogus tegra_framebuffer structure drm/tegra: Add plane support drm/tegra: Implement .mode_set_base() drm/tegra: Implement VBLANK support drm/tegra: Implement page-flipping support drm/tegra: Split DC_CMD_STATE_CONTROL register write drm/tegra: Fix color expansion drm/tegra: Add list of framebuffers to debugfs Tim Gardner (2): i915: intel_set_mode: Reduce stack allocation from 500 bytes to 2 pointers drm/radeon: Avoid NULL pointer dereference from atom_index_iio() allocation failure Tomas Janousek (1): drm/i915: don't prevent CPU idle states Ville Syrjälä (46): drm/i915: Kill i915_gem_execbuffer_wait_for_flips() drm/i915: Fix SPRITE0_FLIP_DONE_INT_EN_VLV and SPRITE0_FLIPDONE_INT_STATUS_VLV drm/i915: Fix RGB color range property for PCH platforms drm/i915: Add "Automatic" mode for the "Broadcast RGB" property drm/edid: Add drm_rgb_quant_range_selectable() drm/i915: Provide the quantization range in the AVI infoframe drm/i915: Convert intel_hdmi to enum port drm/i915: Convert intel_dp to enum port drm/i915: Add display_display_mmio_offset to intel_device_info drm/i915: AUD_VID_DID needs an offset on VLV drm/i915: Per-pipe PP registers are for VLV only drm/i915: VLV_VIDEO_DIP_CTL is for VLV only drm/i915: PIPE M/N registers need an offset on VLV drm/i915: Primary plane registers need an offset on VLV drm/i915: Pipe registers need an offset on VLV drm/i915: Cursor registers need an offset on VLV drm/i915: VLV_DDL is VLV only and needs an offset drm/i915: DSPFW registers need an offset on VLV drm/i915: DPFLIPSTAT and DPINVGTT registers are VLV only and need an offset drm/i915: Panel fitter registers need an offset on VLV drm/i915: PORT_HOTPLUG registers need an offset on VLV drm/i915: Pipe timing registers need an offset on VLV drm/i915: Pipe palette registers need an offset on VLV drm/i915: FB_BLC_SELF_VLV is VLV only and needs an offset drm/i915: Make VLV_GUNIT_CLOCK_GATE register value more readable drm/i915: Spell out VLV_DISPLAY_BASE for interrupt registers drm/i915: DPIO registers are VLV only and need an offset drm/i915: GPIO/GMBUS registers need an offset on VLV drm/i915: Set display_mmio_offset for VLV drm/i915: PLL registers need an offset on VLV drm/i915: Always use adpa_reg drm/i915: VLV doesn't have SDVO drm/i915: Pass VLV_DISPLAY_BASE + reg to intel_{hdmi, dp}_init on VLV drm/i915: Include display_mmio_offset in sequencer index/data registers drm/i915: SWF screatch registers need an offset on VLV drm/i915: Introduce i915_vgacntrl_reg() drm/i915: Kill IS_DISPLAYREG() drm/i915: Set the SR01 "screen off" bit in i915_redisable_vga() too drm/i915: Fix sprite_scaling_enabled for multiple sprites drm/i915: Print the pipe control page GTT address drm/i915: Kill obj->pending_flip drm/i915: Don't wait for page flips if there was GPU reset drm: Fill depth/bits_per_pixel for C8 format drm: Use C8 instead of RGB332 when determining the format from depth/bpp drm/i915: Fix PIPE_CONTROL DW/QW write through global GTT on IVB+ drm/i915: Implement pipe CSC based limited range RGB output Wang Xingchao (1): drm/i915: HDMI/DP - ELD info refresh support for Haswell Yasuaki Ishimatsu (1): GPU/i915: Fix acpi_bus_get_device() check in drivers/gpu/drm/i915/intel_opregion.c YoungJun Cho (2): drm/exynos: fix wrong pointer access at vm close. drm/exynos: release resources properly when fb creation is failed. Zhang Rui (1): i915: ignore lid open event when resuming Documentation/DocBook/drm.tmpl | 78 +- Documentation/EDID/HOWTO.txt | 27 +- .../devicetree/bindings/drm/tilcdc/panel.txt | 59 + .../devicetree/bindings/drm/tilcdc/slave.txt | 18 + .../devicetree/bindings/drm/tilcdc/tfp410.txt | 21 + .../devicetree/bindings/drm/tilcdc/tilcdc.txt | 21 + .../devicetree/bindings/video/display-timing.txt | 109 ++ Documentation/thermal/nouveau_thermal | 81 ++ drivers/char/agp/intel-gtt.c | 128 ++- drivers/gpu/Makefile | 2 +- drivers/gpu/drm/Kconfig | 8 + drivers/gpu/drm/Makefile | 2 + drivers/gpu/drm/ast/ast_drv.c | 4 +- drivers/gpu/drm/ast/ast_drv.h | 2 + drivers/gpu/drm/ast/ast_fb.c | 27 +- drivers/gpu/drm/ast/ast_main.c | 12 +- drivers/gpu/drm/cirrus/cirrus_fbdev.c | 27 +- drivers/gpu/drm/cirrus/cirrus_main.c | 12 +- drivers/gpu/drm/drm_crtc.c | 816 ++++++++------ drivers/gpu/drm/drm_edid.c | 843 +++++++++++++- drivers/gpu/drm/drm_edid_modes.h | 774 ------------- drivers/gpu/drm/drm_encoder_slave.c | 63 ++ drivers/gpu/drm/drm_fb_cma_helper.c | 95 +- drivers/gpu/drm/drm_fb_helper.c | 310 ++++-- drivers/gpu/drm/drm_fops.c | 1 + drivers/gpu/drm/drm_gem_cma_helper.c | 21 + drivers/gpu/drm/drm_irq.c | 12 +- drivers/gpu/drm/drm_mm.c | 96 +- drivers/gpu/drm/drm_modes.c | 70 ++ drivers/gpu/drm/drm_pci.c | 81 +- drivers/gpu/drm/drm_prime.c | 186 +++- drivers/gpu/drm/drm_usb.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_fb.c | 55 +- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 39 +- drivers/gpu/drm/exynos/exynos_drm_g2d.c | 12 +- drivers/gpu/drm/exynos/exynos_drm_gem.c | 33 +- drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 12 + drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 5 +- drivers/gpu/drm/exynos/exynos_drm_iommu.h | 2 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 1035 +++++++----------- drivers/gpu/drm/exynos/exynos_mixer.c | 34 +- drivers/gpu/drm/gma500/framebuffer.c | 43 +- drivers/gpu/drm/gma500/psb_device.c | 8 +- drivers/gpu/drm/gma500/psb_drv.c | 14 +- drivers/gpu/drm/gma500/psb_intel_display.c | 12 +- drivers/gpu/drm/i2c/Kconfig | 28 + drivers/gpu/drm/i2c/Makefile | 3 + drivers/gpu/drm/i2c/ch7006_drv.c | 2 +- drivers/gpu/drm/i2c/tda998x_drv.c | 906 +++++++++++++++ drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_debugfs.c | 254 ++++- drivers/gpu/drm/i915/i915_dma.c | 94 +- drivers/gpu/drm/i915/i915_drv.c | 131 +-- drivers/gpu/drm/i915/i915_drv.h | 475 +++++--- drivers/gpu/drm/i915/i915_gem.c | 516 ++++----- drivers/gpu/drm/i915/i915_gem_context.c | 12 +- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 5 +- drivers/gpu/drm/i915/i915_gem_evict.c | 2 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 333 +++--- drivers/gpu/drm/i915/i915_gem_gtt.c | 645 ++++++----- drivers/gpu/drm/i915/i915_gem_stolen.c | 305 ++++-- drivers/gpu/drm/i915/i915_gem_tiling.c | 33 +- drivers/gpu/drm/i915/i915_irq.c | 370 ++++--- drivers/gpu/drm/i915/i915_reg.h | 436 ++++---- drivers/gpu/drm/i915/i915_suspend.c | 540 +-------- drivers/gpu/drm/i915/i915_ums.c | 503 +++++++++ drivers/gpu/drm/i915/intel_crt.c | 46 +- drivers/gpu/drm/i915/intel_ddi.c | 79 +- drivers/gpu/drm/i915/intel_display.c | 975 +++++++---------- drivers/gpu/drm/i915/intel_dp.c | 374 ++++--- drivers/gpu/drm/i915/intel_drv.h | 41 +- drivers/gpu/drm/i915/intel_dvo.c | 1 - drivers/gpu/drm/i915/intel_fb.c | 55 +- drivers/gpu/drm/i915/intel_hdmi.c | 108 +- drivers/gpu/drm/i915/intel_i2c.c | 103 +- drivers/gpu/drm/i915/intel_lvds.c | 250 ++++- drivers/gpu/drm/i915/intel_modes.c | 6 +- drivers/gpu/drm/i915/intel_opregion.c | 2 +- drivers/gpu/drm/i915/intel_overlay.c | 24 +- drivers/gpu/drm/i915/intel_panel.c | 13 +- drivers/gpu/drm/i915/intel_pm.c | 95 +- drivers/gpu/drm/i915/intel_ringbuffer.c | 113 +- drivers/gpu/drm/i915/intel_ringbuffer.h | 11 +- drivers/gpu/drm/i915/intel_sdvo.c | 67 +- drivers/gpu/drm/i915/intel_sprite.c | 46 +- drivers/gpu/drm/i915/intel_tv.c | 4 +- drivers/gpu/drm/mgag200/mgag200_fb.c | 28 +- drivers/gpu/drm/mgag200/mgag200_main.c | 16 +- drivers/gpu/drm/nouveau/Kconfig | 28 +- drivers/gpu/drm/nouveau/Makefile | 29 +- drivers/gpu/drm/nouveau/core/core/client.c | 10 + drivers/gpu/drm/nouveau/core/core/enum.c | 11 +- drivers/gpu/drm/nouveau/core/core/event.c | 106 ++ drivers/gpu/drm/nouveau/core/engine/copy/nva3.c | 6 +- drivers/gpu/drm/nouveau/core/engine/crypt/nv84.c | 8 +- drivers/gpu/drm/nouveau/core/engine/crypt/nv98.c | 6 +- drivers/gpu/drm/nouveau/core/engine/disp/base.c | 52 + drivers/gpu/drm/nouveau/core/engine/disp/dport.c | 346 ++++++ drivers/gpu/drm/nouveau/core/engine/disp/dport.h | 78 ++ drivers/gpu/drm/nouveau/core/engine/disp/nv04.c | 33 +- drivers/gpu/drm/nouveau/core/engine/disp/nv50.c | 371 ++++--- drivers/gpu/drm/nouveau/core/engine/disp/nv50.h | 37 +- drivers/gpu/drm/nouveau/core/engine/disp/nv84.c | 12 +- drivers/gpu/drm/nouveau/core/engine/disp/nv94.c | 24 +- drivers/gpu/drm/nouveau/core/engine/disp/nva0.c | 9 +- drivers/gpu/drm/nouveau/core/engine/disp/nva3.c | 24 +- drivers/gpu/drm/nouveau/core/engine/disp/nvd0.c | 309 +++--- drivers/gpu/drm/nouveau/core/engine/disp/nve0.c | 17 +- .../gpu/drm/nouveau/core/engine/disp/piornv50.c | 140 +++ drivers/gpu/drm/nouveau/core/engine/disp/sornv50.c | 25 - drivers/gpu/drm/nouveau/core/engine/disp/sornv94.c | 153 +-- drivers/gpu/drm/nouveau/core/engine/disp/sornvd0.c | 90 +- drivers/gpu/drm/nouveau/core/engine/fifo/base.c | 21 + drivers/gpu/drm/nouveau/core/engine/fifo/nv04.c | 187 ++-- drivers/gpu/drm/nouveau/core/engine/fifo/nv50.c | 5 +- drivers/gpu/drm/nouveau/core/engine/fifo/nv84.c | 22 +- drivers/gpu/drm/nouveau/core/engine/fifo/nvc0.c | 109 +- drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c | 64 +- drivers/gpu/drm/nouveau/core/engine/graph/nv04.c | 16 +- drivers/gpu/drm/nouveau/core/engine/graph/nv10.c | 16 +- drivers/gpu/drm/nouveau/core/engine/graph/nv20.c | 15 +- drivers/gpu/drm/nouveau/core/engine/graph/nv40.c | 16 +- drivers/gpu/drm/nouveau/core/engine/graph/nv50.c | 53 +- drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 33 +- drivers/gpu/drm/nouveau/core/engine/graph/nve0.c | 44 +- drivers/gpu/drm/nouveau/core/engine/mpeg/nv31.c | 7 +- .../gpu/drm/nouveau/core/engine/software/nv50.c | 40 +- .../gpu/drm/nouveau/core/engine/software/nvc0.c | 29 +- drivers/gpu/drm/nouveau/core/include/core/class.h | 44 +- drivers/gpu/drm/nouveau/core/include/core/client.h | 3 +- drivers/gpu/drm/nouveau/core/include/core/device.h | 1 + drivers/gpu/drm/nouveau/core/include/core/enum.h | 3 +- drivers/gpu/drm/nouveau/core/include/core/event.h | 36 + drivers/gpu/drm/nouveau/core/include/core/object.h | 12 +- drivers/gpu/drm/nouveau/core/include/core/printk.h | 3 +- drivers/gpu/drm/nouveau/core/include/engine/disp.h | 27 +- drivers/gpu/drm/nouveau/core/include/engine/fifo.h | 4 + .../gpu/drm/nouveau/core/include/engine/software.h | 4 +- .../gpu/drm/nouveau/core/include/subdev/bios/dcb.h | 3 + .../drm/nouveau/core/include/subdev/bios/gpio.h | 11 +- .../gpu/drm/nouveau/core/include/subdev/bios/i2c.h | 2 +- .../drm/nouveau/core/include/subdev/bios/therm.h | 16 + .../drm/nouveau/core/include/subdev/bios/xpio.h | 19 + drivers/gpu/drm/nouveau/core/include/subdev/bus.h | 41 + drivers/gpu/drm/nouveau/core/include/subdev/gpio.h | 39 +- drivers/gpu/drm/nouveau/core/include/subdev/i2c.h | 127 ++- .../gpu/drm/nouveau/core/include/subdev/therm.h | 37 +- .../gpu/drm/nouveau/core/include/subdev/timer.h | 8 + drivers/gpu/drm/nouveau/core/os.h | 1 + drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 2 +- drivers/gpu/drm/nouveau/core/subdev/bios/dcb.c | 32 +- drivers/gpu/drm/nouveau/core/subdev/bios/extdev.c | 2 +- drivers/gpu/drm/nouveau/core/subdev/bios/gpio.c | 11 +- drivers/gpu/drm/nouveau/core/subdev/bios/i2c.c | 15 +- drivers/gpu/drm/nouveau/core/subdev/bios/init.c | 15 +- drivers/gpu/drm/nouveau/core/subdev/bios/therm.c | 28 +- drivers/gpu/drm/nouveau/core/subdev/bios/xpio.c | 76 ++ drivers/gpu/drm/nouveau/core/subdev/bus/nv04.c | 95 ++ drivers/gpu/drm/nouveau/core/subdev/bus/nv31.c | 112 ++ drivers/gpu/drm/nouveau/core/subdev/bus/nv50.c | 105 ++ drivers/gpu/drm/nouveau/core/subdev/bus/nvc0.c | 101 ++ drivers/gpu/drm/nouveau/core/subdev/device/base.c | 5 +- drivers/gpu/drm/nouveau/core/subdev/device/nv04.c | 7 +- drivers/gpu/drm/nouveau/core/subdev/device/nv10.c | 25 +- drivers/gpu/drm/nouveau/core/subdev/device/nv20.c | 13 +- drivers/gpu/drm/nouveau/core/subdev/device/nv30.c | 16 +- drivers/gpu/drm/nouveau/core/subdev/device/nv40.c | 50 +- drivers/gpu/drm/nouveau/core/subdev/device/nv50.c | 51 +- drivers/gpu/drm/nouveau/core/subdev/device/nvc0.c | 43 +- drivers/gpu/drm/nouveau/core/subdev/device/nve0.c | 22 +- drivers/gpu/drm/nouveau/core/subdev/devinit/nv50.c | 14 +- drivers/gpu/drm/nouveau/core/subdev/fb/nv50.c | 64 +- drivers/gpu/drm/nouveau/core/subdev/gpio/base.c | 140 +-- drivers/gpu/drm/nouveau/core/subdev/gpio/nv10.c | 40 +- drivers/gpu/drm/nouveau/core/subdev/gpio/nv50.c | 45 +- drivers/gpu/drm/nouveau/core/subdev/gpio/nvd0.c | 14 +- drivers/gpu/drm/nouveau/core/subdev/gpio/nve0.c | 131 +++ drivers/gpu/drm/nouveau/core/subdev/gpio/priv.h | 17 + drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c | 279 +++++ drivers/gpu/drm/nouveau/core/subdev/i2c/aux.c | 154 +-- drivers/gpu/drm/nouveau/core/subdev/i2c/base.c | 481 ++++---- drivers/gpu/drm/nouveau/core/subdev/i2c/bit.c | 18 +- drivers/gpu/drm/nouveau/core/subdev/i2c/nv04.c | 143 +++ drivers/gpu/drm/nouveau/core/subdev/i2c/nv4e.c | 135 +++ drivers/gpu/drm/nouveau/core/subdev/i2c/nv50.c | 149 +++ drivers/gpu/drm/nouveau/core/subdev/i2c/nv50.h | 32 + drivers/gpu/drm/nouveau/core/subdev/i2c/nv94.c | 285 +++++ drivers/gpu/drm/nouveau/core/subdev/i2c/nvd0.c | 124 +++ drivers/gpu/drm/nouveau/core/subdev/mc/nv04.c | 2 +- drivers/gpu/drm/nouveau/core/subdev/mc/nv50.c | 1 + drivers/gpu/drm/nouveau/core/subdev/mc/nv98.c | 2 + drivers/gpu/drm/nouveau/core/subdev/mc/nvc0.c | 2 + drivers/gpu/drm/nouveau/core/subdev/mxm/mxms.c | 8 +- drivers/gpu/drm/nouveau/core/subdev/therm/base.c | 218 +++- drivers/gpu/drm/nouveau/core/subdev/therm/fan.c | 244 +++-- drivers/gpu/drm/nouveau/core/subdev/therm/fannil.c | 54 + drivers/gpu/drm/nouveau/core/subdev/therm/fanpwm.c | 107 ++ drivers/gpu/drm/nouveau/core/subdev/therm/fantog.c | 115 ++ drivers/gpu/drm/nouveau/core/subdev/therm/ic.c | 54 +- drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c | 82 +- drivers/gpu/drm/nouveau/core/subdev/therm/nv50.c | 199 +++- drivers/gpu/drm/nouveau/core/subdev/therm/nva3.c | 99 ++ drivers/gpu/drm/nouveau/core/subdev/therm/nvd0.c | 153 +++ drivers/gpu/drm/nouveau/core/subdev/therm/priv.h | 103 +- drivers/gpu/drm/nouveau/core/subdev/therm/temp.c | 162 +++ drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c | 2 +- drivers/gpu/drm/nouveau/nouveau_acpi.h | 2 +- drivers/gpu/drm/nouveau/nouveau_backlight.c | 2 + drivers/gpu/drm/nouveau/nouveau_bios.c | 130 +-- drivers/gpu/drm/nouveau/nouveau_bios.h | 12 +- drivers/gpu/drm/nouveau/nouveau_bo.c | 25 +- drivers/gpu/drm/nouveau/nouveau_bo.h | 3 +- drivers/gpu/drm/nouveau/nouveau_chan.c | 5 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 96 +- drivers/gpu/drm/nouveau/nouveau_connector.h | 10 +- drivers/gpu/drm/nouveau/nouveau_debugfs.c | 64 ++ drivers/gpu/drm/nouveau/nouveau_debugfs.h | 22 + drivers/gpu/drm/nouveau/nouveau_display.c | 95 +- drivers/gpu/drm/nouveau/nouveau_display.h | 3 - drivers/gpu/drm/nouveau/nouveau_dma.h | 2 +- drivers/gpu/drm/nouveau/nouveau_dp.c | 297 +---- drivers/gpu/drm/nouveau/nouveau_drm.c | 60 +- drivers/gpu/drm/nouveau/nouveau_drm.h | 2 + drivers/gpu/drm/nouveau/nouveau_encoder.h | 9 +- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 26 +- drivers/gpu/drm/nouveau/nouveau_fence.c | 103 +- drivers/gpu/drm/nouveau/nouveau_fence.h | 42 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 103 +- drivers/gpu/drm/nouveau/nouveau_gem.h | 10 +- drivers/gpu/drm/nouveau/nouveau_pm.c | 233 +++- drivers/gpu/drm/nouveau/nouveau_prime.c | 173 +-- drivers/gpu/drm/nouveau/nv04_dfp.c | 4 +- drivers/gpu/drm/nouveau/nv04_display.c | 18 +- drivers/gpu/drm/nouveau/nv04_display.h | 1 + drivers/gpu/drm/nouveau/nv04_fence.c | 6 +- drivers/gpu/drm/nouveau/nv04_tv.c | 39 +- drivers/gpu/drm/nouveau/nv10_fence.c | 118 +- drivers/gpu/drm/nouveau/nv10_fence.h | 19 + drivers/gpu/drm/nouveau/nv17_fence.c | 149 +++ drivers/gpu/drm/nouveau/nv17_tv.c | 2 +- drivers/gpu/drm/nouveau/nv50_display.c | 307 +++++- drivers/gpu/drm/nouveau/nv50_fence.c | 36 +- drivers/gpu/drm/nouveau/nv84_fence.c | 214 +++- drivers/gpu/drm/nouveau/nvc0_fence.c | 186 +--- drivers/{staging => gpu/drm}/omapdrm/Kconfig | 0 drivers/{staging => gpu/drm}/omapdrm/Makefile | 0 drivers/gpu/drm/omapdrm/TODO | 23 + .../{staging => gpu/drm}/omapdrm/omap_connector.c | 2 +- drivers/{staging => gpu/drm}/omapdrm/omap_crtc.c | 14 +- .../{staging => gpu/drm}/omapdrm/omap_debugfs.c | 18 +- .../{staging => gpu/drm}/omapdrm/omap_dmm_priv.h | 5 + .../{staging => gpu/drm}/omapdrm/omap_dmm_tiler.c | 159 ++- .../{staging => gpu/drm}/omapdrm/omap_dmm_tiler.h | 0 drivers/{staging => gpu/drm}/omapdrm/omap_drv.c | 20 +- drivers/{staging => gpu/drm}/omapdrm/omap_drv.h | 8 +- .../{staging => gpu/drm}/omapdrm/omap_encoder.c | 2 +- drivers/{staging => gpu/drm}/omapdrm/omap_fb.c | 18 +- drivers/{staging => gpu/drm}/omapdrm/omap_fbdev.c | 34 +- drivers/{staging => gpu/drm}/omapdrm/omap_gem.c | 34 +- .../{staging => gpu/drm}/omapdrm/omap_gem_dmabuf.c | 8 +- .../drm}/omapdrm/omap_gem_helpers.c | 2 +- drivers/{staging => gpu/drm}/omapdrm/omap_irq.c | 2 +- drivers/{staging => gpu/drm}/omapdrm/omap_plane.c | 2 +- drivers/{staging => gpu/drm}/omapdrm/tcm-sita.c | 0 drivers/{staging => gpu/drm}/omapdrm/tcm-sita.h | 0 drivers/{staging => gpu/drm}/omapdrm/tcm.h | 2 + drivers/gpu/drm/radeon/Kconfig | 33 +- drivers/gpu/drm/radeon/Makefile | 10 +- drivers/gpu/drm/radeon/atom.c | 9 +- drivers/gpu/drm/radeon/atombios_crtc.c | 6 +- drivers/gpu/drm/radeon/evergreen.c | 366 +++++-- drivers/gpu/drm/radeon/evergreen_cs.c | 1149 ++++++++------------ drivers/gpu/drm/radeon/evergreen_hdmi.c | 85 +- drivers/gpu/drm/radeon/evergreen_reg.h | 1 + drivers/gpu/drm/radeon/evergreend.h | 54 +- drivers/gpu/drm/radeon/ni.c | 339 ++++-- drivers/gpu/drm/radeon/nid.h | 27 +- drivers/gpu/drm/radeon/r100.c | 224 +--- drivers/gpu/drm/radeon/r100_track.h | 4 - drivers/gpu/drm/radeon/r100d.h | 11 - drivers/gpu/drm/radeon/r200.c | 26 +- drivers/gpu/drm/radeon/r300.c | 42 +- drivers/gpu/drm/radeon/r300_cmdbuf.c | 2 + drivers/gpu/drm/radeon/r300d.h | 11 - drivers/gpu/drm/radeon/r500_reg.h | 1 + drivers/gpu/drm/radeon/r600.c | 401 ++++--- drivers/gpu/drm/radeon/r600_blit.c | 33 +- drivers/gpu/drm/radeon/r600_blit_kms.c | 31 + drivers/gpu/drm/radeon/r600_cp.c | 2 + drivers/gpu/drm/radeon/r600_cs.c | 332 ++---- drivers/gpu/drm/radeon/r600_hdmi.c | 135 +-- drivers/gpu/drm/radeon/r600d.h | 17 +- drivers/gpu/drm/radeon/radeon.h | 38 +- drivers/gpu/drm/radeon/radeon_asic.c | 70 +- drivers/gpu/drm/radeon/radeon_asic.h | 24 +- drivers/gpu/drm/radeon/radeon_atpx_handler.c | 73 +- drivers/gpu/drm/radeon/radeon_cp.c | 2 + drivers/gpu/drm/radeon/radeon_cs.c | 176 ++- drivers/gpu/drm/radeon/radeon_cursor.c | 8 +- drivers/gpu/drm/radeon/radeon_device.c | 10 +- drivers/gpu/drm/radeon/radeon_display.c | 2 +- drivers/gpu/drm/radeon/radeon_drv.c | 91 +- drivers/gpu/drm/radeon/radeon_drv.h | 16 +- drivers/gpu/drm/radeon/radeon_family.h | 1 + drivers/gpu/drm/radeon/radeon_fb.c | 27 +- drivers/gpu/drm/radeon/radeon_gart.c | 60 +- drivers/gpu/drm/radeon/radeon_irq.c | 2 + drivers/gpu/drm/radeon/radeon_kms.c | 11 +- drivers/gpu/drm/radeon/radeon_mem.c | 2 + drivers/gpu/drm/radeon/radeon_pm.c | 2 +- drivers/gpu/drm/radeon/radeon_prime.c | 170 +-- drivers/gpu/drm/radeon/radeon_reg.h | 15 + drivers/gpu/drm/radeon/radeon_ring.c | 19 + drivers/gpu/drm/radeon/radeon_state.c | 2 + drivers/gpu/drm/radeon/radeon_ttm.c | 1 + drivers/gpu/drm/radeon/rv515d.h | 11 - drivers/gpu/drm/radeon/rv770.c | 25 + drivers/gpu/drm/radeon/rv770d.h | 4 + drivers/gpu/drm/radeon/si.c | 509 ++++++--- drivers/gpu/drm/radeon/sid.h | 30 +- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 +- drivers/gpu/drm/tegra/Kconfig | 1 + drivers/gpu/drm/tegra/dc.c | 585 ++++++++-- drivers/gpu/drm/tegra/dc.h | 14 +- drivers/gpu/drm/tegra/drm.c | 103 ++ drivers/gpu/drm/tegra/drm.h | 43 +- drivers/gpu/drm/tegra/fb.c | 4 - drivers/gpu/drm/tegra/hdmi.c | 226 ++-- drivers/gpu/drm/tegra/hdmi.h | 189 ---- drivers/gpu/drm/tilcdc/Kconfig | 13 + drivers/gpu/drm/tilcdc/Makefile | 10 + drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 602 ++++++++++ drivers/gpu/drm/tilcdc/tilcdc_drv.c | 611 +++++++++++ drivers/gpu/drm/tilcdc/tilcdc_drv.h | 150 +++ drivers/gpu/drm/tilcdc/tilcdc_panel.c | 436 ++++++++ drivers/gpu/drm/tilcdc/tilcdc_panel.h | 26 + drivers/gpu/drm/tilcdc/tilcdc_regs.h | 154 +++ drivers/gpu/drm/tilcdc/tilcdc_slave.c | 376 +++++++ drivers/gpu/drm/tilcdc/tilcdc_slave.h | 26 + drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 419 +++++++ drivers/gpu/drm/tilcdc/tilcdc_tfp410.h | 26 + drivers/gpu/drm/ttm/ttm_bo.c | 103 +- drivers/gpu/drm/ttm/ttm_execbuf_util.c | 78 +- drivers/gpu/drm/udl/udl_drv.h | 2 + drivers/gpu/drm/udl/udl_fb.c | 78 +- drivers/gpu/drm/udl/udl_transfer.c | 46 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 38 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 87 +- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 4 +- drivers/gpu/stub/Kconfig | 18 - drivers/gpu/stub/Makefile | 1 - drivers/gpu/stub/poulsbo.c | 64 -- drivers/gpu/vga/vga_switcheroo.c | 3 + drivers/iommu/intel-iommu.c | 8 +- drivers/staging/Kconfig | 2 - drivers/staging/Makefile | 1 - drivers/staging/omapdrm/TODO | 32 - drivers/tty/vt/vt.c | 136 ++- drivers/video/Kconfig | 26 +- drivers/video/Makefile | 5 + drivers/video/console/fbcon.c | 58 +- drivers/video/console/vgacon.c | 22 +- drivers/video/display_timing.c | 24 + drivers/video/fbmem.c | 11 +- drivers/video/fbmon.c | 94 ++ drivers/video/fbsysfs.c | 3 + drivers/video/hdmi.c | 308 ++++++ drivers/video/of_display_timing.c | 239 ++++ drivers/video/of_videomode.c | 54 + drivers/video/via/hw.c | 6 +- drivers/video/via/hw.h | 2 +- drivers/video/via/lcd.c | 2 +- drivers/video/via/share.h | 2 +- drivers/video/via/via_modesetting.c | 8 +- drivers/video/via/via_modesetting.h | 6 +- drivers/video/videomode.c | 39 + include/drm/drmP.h | 34 + include/drm/drm_crtc.h | 38 +- include/drm/drm_edid.h | 6 + include/drm/drm_encoder_slave.h | 20 + include/drm/drm_fb_cma_helper.h | 5 + include/drm/drm_fb_helper.h | 18 +- include/drm/drm_gem_cma_helper.h | 4 + include/drm/drm_mm.h | 40 + include/drm/drm_pciids.h | 13 + include/drm/intel-gtt.h | 22 +- include/drm/ttm/ttm_bo_driver.h | 61 +- include/linux/console.h | 2 + include/linux/fb.h | 8 + include/linux/hdmi.h | 231 ++++ include/linux/vt_kern.h | 3 + include/uapi/drm/i915_drm.h | 20 + .../omapdrm => include/uapi/drm}/omap_drm.h | 2 +- include/video/display_timing.h | 124 +++ include/video/of_display_timing.h | 20 + include/video/of_videomode.h | 18 + include/video/videomode.h | 48 + kernel/printk.c | 9 + 399 files changed, 23655 insertions(+), 11557 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/panel.txt create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/slave.txt create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt create mode 100644 Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt create mode 100644 Documentation/thermal/nouveau_thermal delete mode 100644 drivers/gpu/drm/drm_edid_modes.h create mode 100644 drivers/gpu/drm/i2c/Kconfig create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.c create mode 100644 drivers/gpu/drm/i915/i915_ums.c create mode 100644 drivers/gpu/drm/nouveau/core/core/event.c create mode 100644 drivers/gpu/drm/nouveau/core/engine/disp/base.c create mode 100644 drivers/gpu/drm/nouveau/core/engine/disp/dport.c create mode 100644 drivers/gpu/drm/nouveau/core/engine/disp/dport.h create mode 100644 drivers/gpu/drm/nouveau/core/engine/disp/piornv50.c create mode 100644 drivers/gpu/drm/nouveau/core/include/core/event.h create mode 100644 drivers/gpu/drm/nouveau/core/include/subdev/bios/xpio.h create mode 100644 drivers/gpu/drm/nouveau/core/include/subdev/bus.h create mode 100644 drivers/gpu/drm/nouveau/core/subdev/bios/xpio.c create mode 100644 drivers/gpu/drm/nouveau/core/subdev/bus/nv04.c create mode 100644 drivers/gpu/drm/nouveau/core/subdev/bus/nv31.c create mode 100644 drivers/gpu/drm/nouveau/core/subdev/bus/nv50.c create mode 100644 drivers/gpu/drm/nouveau/core/subdev/bus/nvc0.c create mode 100644 drivers/gpu/drm/nouveau/core/subdev/gpio/nve0.c create mode 100644 drivers/gpu/drm/nouveau/core/subdev/gpio/priv.h create mode 100644 drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c create mode 100644 drivers/gpu/drm/nouveau/core/subdev/i2c/nv04.c create mode 100644 drivers/gpu/drm/nouveau/core/subdev/i2c/nv4e.c create mode 100644 drivers/gpu/drm/nouveau/core/subdev/i2c/nv50.c create mode 100644 drivers/gpu/drm/nouveau/core/subdev/i2c/nv50.h create mode 100644 drivers/gpu/drm/nouveau/core/subdev/i2c/nv94.c create mode 100644 drivers/gpu/drm/nouveau/core/subdev/i2c/nvd0.c create mode 100644 drivers/gpu/drm/nouveau/core/subdev/therm/fannil.c create mode 100644 drivers/gpu/drm/nouveau/core/subdev/therm/fanpwm.c create mode 100644 drivers/gpu/drm/nouveau/core/subdev/therm/fantog.c create mode 100644 drivers/gpu/drm/nouveau/core/subdev/therm/nva3.c create mode 100644 drivers/gpu/drm/nouveau/core/subdev/therm/nvd0.c create mode 100644 drivers/gpu/drm/nouveau/nouveau_debugfs.c create mode 100644 drivers/gpu/drm/nouveau/nouveau_debugfs.h create mode 100644 drivers/gpu/drm/nouveau/nv10_fence.h create mode 100644 drivers/gpu/drm/nouveau/nv17_fence.c rename drivers/{staging => gpu/drm}/omapdrm/Kconfig (100%) rename drivers/{staging => gpu/drm}/omapdrm/Makefile (100%) create mode 100644 drivers/gpu/drm/omapdrm/TODO rename drivers/{staging => gpu/drm}/omapdrm/omap_connector.c (99%) rename drivers/{staging => gpu/drm}/omapdrm/omap_crtc.c (98%) rename drivers/{staging => gpu/drm}/omapdrm/omap_debugfs.c (90%) rename drivers/{staging => gpu/drm}/omapdrm/omap_dmm_priv.h (96%) rename drivers/{staging => gpu/drm}/omapdrm/omap_dmm_tiler.c (86%) rename drivers/{staging => gpu/drm}/omapdrm/omap_dmm_tiler.h (100%) rename drivers/{staging => gpu/drm}/omapdrm/omap_drv.c (97%) rename drivers/{staging => gpu/drm}/omapdrm/omap_drv.h (98%) rename drivers/{staging => gpu/drm}/omapdrm/omap_encoder.c (99%) rename drivers/{staging => gpu/drm}/omapdrm/omap_fb.c (99%) rename drivers/{staging => gpu/drm}/omapdrm/omap_fbdev.c (95%) rename drivers/{staging => gpu/drm}/omapdrm/omap_gem.c (97%) rename drivers/{staging => gpu/drm}/omapdrm/omap_gem_dmabuf.c (98%) rename drivers/{staging => gpu/drm}/omapdrm/omap_gem_helpers.c (98%) rename drivers/{staging => gpu/drm}/omapdrm/omap_irq.c (99%) rename drivers/{staging => gpu/drm}/omapdrm/omap_plane.c (99%) rename drivers/{staging => gpu/drm}/omapdrm/tcm-sita.c (100%) rename drivers/{staging => gpu/drm}/omapdrm/tcm-sita.h (100%) rename drivers/{staging => gpu/drm}/omapdrm/tcm.h (99%) create mode 100644 drivers/gpu/drm/tilcdc/Kconfig create mode 100644 drivers/gpu/drm/tilcdc/Makefile create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_crtc.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_drv.h create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_panel.h create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_regs.h create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave.h create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c create mode 100644 drivers/gpu/drm/tilcdc/tilcdc_tfp410.h delete mode 100644 drivers/gpu/stub/Kconfig delete mode 100644 drivers/gpu/stub/Makefile delete mode 100644 drivers/gpu/stub/poulsbo.c delete mode 100644 drivers/staging/omapdrm/TODO create mode 100644 drivers/video/display_timing.c create mode 100644 drivers/video/hdmi.c create mode 100644 drivers/video/of_display_timing.c create mode 100644 drivers/video/of_videomode.c create mode 100644 drivers/video/videomode.c create mode 100644 include/linux/hdmi.h rename {drivers/staging/omapdrm => include/uapi/drm}/omap_drm.h (99%) create mode 100644 include/video/display_timing.h create mode 100644 include/video/of_display_timing.h create mode 100644 include/video/of_videomode.h create mode 100644 include/video/videomode.h ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-26 0:05 Dave Airlie @ 2013-02-26 1:22 ` Linus Torvalds 2013-02-26 1:59 ` Dave Airlie 2013-02-27 1:39 ` Linus Torvalds 2013-02-27 16:34 ` Josh Boyer 2 siblings, 1 reply; 33+ messages in thread From: Linus Torvalds @ 2013-02-26 1:22 UTC (permalink / raw) To: Dave Airlie; +Cc: DRI mailing list, Linux Kernel Mailing List On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie <airlied@linux.ie> wrote: > > So up front, this has a massive merge conflict in > drivers/gpu/drm/radeon/evergreen_cs.c I've fixed it up in drm-next-merged > in the same tree, I fixed up some small ordering issues in my merge as > well, however they aren't important if you want the fun of doing a major > conflict resolution. I did the fun conflict resolution, so my tree doesn't have the ordering changes. I also did some things slightly differently from you - you had left some direct ib[] accesses that I spotted (see for example "case 0x48" (aka "Copy L2T Frame to Field"), and yours apparently has a few cases where you use "idx_value" instead of my mindless conflict resolution that just re-did the brute-force "repace direct ib[] read accesses with the radeon_get_ib_value() helper function". But you don't do it for *all* the radeon_get_ib_value(p, idx+2) users, so whatever. Anyway - my conflict resolution isn't exactly the same as yours, and maybe I screwed something up. But it's damn close, and the differences _seem_ be all be benign. Btw, why is it ok that some functions still read the ib[] array directly (eg evergreen_vm_packet3_check() or evergreen_cs_check_reg() etc)? Whatever. I prefer doing my own resolutions just so that I know what's going on, and it all seems to build and looks reasonable, but it's always good to get a second opinion. Particularly since I can't actually test the radeon stuff, so just eyeballing it and saying "looks semantically identical to Dave's resolution" may not be 100% sufficient.. Linus ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-26 1:22 ` Linus Torvalds @ 2013-02-26 1:59 ` Dave Airlie 0 siblings, 0 replies; 33+ messages in thread From: Dave Airlie @ 2013-02-26 1:59 UTC (permalink / raw) To: Linus Torvalds; +Cc: Dave Airlie, DRI mailing list, Linux Kernel Mailing List > > I did the fun conflict resolution, so my tree doesn't have the ordering changes. > > I also did some things slightly differently from you - you had left > some direct ib[] accesses that I spotted (see for example "case 0x48" > (aka "Copy L2T Frame to Field"), and yours apparently has a few cases > where you use "idx_value" instead of my mindless conflict resolution > that just re-did the brute-force "repace direct ib[] read accesses > with the radeon_get_ib_value() helper function". But you don't do it > for *all* the radeon_get_ib_value(p, idx+2) users, so whatever. Yeah the rules for radeon_get_ib_value are that they are meant to be sequential, but it actually doesn't matter as long as the values are within a page of each other, I was just avoiding multiple calls to get the same value with the idx_value, but I think Alex or Jerome can clean this up a bit further anyways. > Anyway - my conflict resolution isn't exactly the same as yours, and > maybe I screwed something up. But it's damn close, and the differences > _seem_ be all be benign. > > Btw, why is it ok that some functions still read the ib[] array > directly (eg evergreen_vm_packet3_check() or evergreen_cs_check_reg() > etc)? The semantics for that function are a bit underdocumented, and I thought the other developers understood them after I explained them, but I found out that they hadn't quite grasped the true extent of pain. So yes there are other places that need to be cleaned up, but most of the time direct ib access will work fine, until you have a buffer that straddles a page boundary. > Whatever. I prefer doing my own resolutions just so that I know what's > going on, and it all seems to build and looks reasonable, but it's > always good to get a second opinion. Particularly since I can't > actually test the radeon stuff, so just eyeballing it and saying > "looks semantically identical to Dave's resolution" may not be 100% > sufficient.. Yup I've reviewed it and it looks fine, any cleanup is just going to be an optimisation. So I'll work with Alex/Jerome to clean up anything else out-of-band and hopefully we can avoid any big conflicts in future! Dave. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-26 0:05 Dave Airlie 2013-02-26 1:22 ` Linus Torvalds @ 2013-02-27 1:39 ` Linus Torvalds 2013-02-27 2:25 ` Linus Torvalds ` (4 more replies) 2013-02-27 16:34 ` Josh Boyer 2 siblings, 5 replies; 33+ messages in thread From: Linus Torvalds @ 2013-02-27 1:39 UTC (permalink / raw) To: Dave Airlie, Daniel Vetter, Imre Deak Cc: DRI mailing list, Linux Kernel Mailing List On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie <airlied@linux.ie> wrote: > > Highlights: > > i915: all over the map, haswell power well enhancements, valleyview macro horrors cleaned up, killing lots of legacy GTT > code, Lowlight: There's something wrong with i915 DP detection or whatever. I get stuff like this: [ 5.710827] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 5.720810] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 5.730794] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 5.740782] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 5.750775] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 5.750778] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status 0xa145003f ..... [ 8.149931] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status 0xa145003f and after that the screen ends up black. It's happened twice now, but is not 100% repeatable. It looks like the message itself is new, but the black screen is also new and does seem to happen when I get the message, so... The second time I touched the power button, and the machine came back. Apparently the suspend/resume cycle made it all magically work: the suspend caused the same errors, but then the resume made it all good again. Some kind of missed initialization at bootup? It's not reliable enough to bisect, but I obviously suspect commit 9ee32fea5fe8 ("drm/i915: irq-drive the dp aux communication") since that is where the message was added.. Btw, looking at that commit, what do you think the semantics of the timeout in something like done = wait_event_timeout(dev_priv->gmbus_wait_queue, C, 10); would be? What's that magic "10"? It's some totally random number. Guys, it should be something meaningful. If you meant a tenth of a second, use HZ/10 or something. Because just the plain "10" is crazy. I happen to have CONFIG_HZ_1000=y, and you're apparently waiting for a hundreth of a second. Was that what you intended? Because if it was, it is still crap, since CONFIG_HZ might be 100, and then you're waiting for ten times longer. IOW, passing in a random number like that is crazy. It cannot possibly be right. I have no idea whether the timeout has anything to do with anything, but it reinforces my suspicion that there is something wrong with that commit. Linus ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-27 1:39 ` Linus Torvalds @ 2013-02-27 2:25 ` Linus Torvalds 2013-02-27 3:30 ` Dave Airlie ` (3 subsequent siblings) 4 siblings, 0 replies; 33+ messages in thread From: Linus Torvalds @ 2013-02-27 2:25 UTC (permalink / raw) To: Dave Airlie, Daniel Vetter, Imre Deak Cc: DRI mailing list, Linux Kernel Mailing List On Tue, Feb 26, 2013 at 5:39 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > Lowlight: > > [ 5.710827] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not > signal timeout (has irq: 1)! Oh, forgot to mention - this is my trusty old Westmere chip (aka "Core i5-670", aka Clarkdale, aka GMA-some-random-number). The one before SB. Linus ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-27 1:39 ` Linus Torvalds 2013-02-27 2:25 ` Linus Torvalds @ 2013-02-27 3:30 ` Dave Airlie 2013-02-27 3:38 ` Linus Torvalds 2013-02-27 10:04 ` Chris Wilson ` (2 subsequent siblings) 4 siblings, 1 reply; 33+ messages in thread From: Dave Airlie @ 2013-02-27 3:30 UTC (permalink / raw) To: Linus Torvalds Cc: Dave Airlie, Daniel Vetter, Imre Deak, Linux Kernel Mailing List, DRI mailing list [-- Attachment #1: Type: text/plain, Size: 2725 bytes --] On Wed, Feb 27, 2013 at 11:39 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie <airlied@linux.ie> wrote: >> >> Highlights: >> >> i915: all over the map, haswell power well enhancements, valleyview macro horrors cleaned up, killing lots of legacy GTT >> code, > > Lowlight: > > There's something wrong with i915 DP detection or whatever. I get > stuff like this: > > [ 5.710827] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not > signal timeout (has irq: 1)! > [ 5.720810] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not > signal timeout (has irq: 1)! > [ 5.730794] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not > signal timeout (has irq: 1)! > [ 5.740782] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not > signal timeout (has irq: 1)! > [ 5.750775] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not > signal timeout (has irq: 1)! > [ 5.750778] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status > 0xa145003f > ..... > [ 8.149931] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status > 0xa145003f > > and after that the screen ends up black. > > It's happened twice now, but is not 100% repeatable. It looks like the > message itself is new, but the black screen is also new and does seem > to happen when I get the message, so... > > The second time I touched the power button, and the machine came back. > Apparently the suspend/resume cycle made it all magically work: the > suspend caused the same errors, but then the resume made it all good > again. > > Some kind of missed initialization at bootup? It's not reliable enough > to bisect, but I obviously suspect commit 9ee32fea5fe8 ("drm/i915: > irq-drive the dp aux communication") since that is where the message > was added.. > > Btw, looking at that commit, what do you think the semantics of the > timeout in something like > > done = wait_event_timeout(dev_priv->gmbus_wait_queue, C, 10); > > would be? What's that magic "10"? It's some totally random number. > > Guys, it should be something meaningful. If you meant a tenth of a > second, use HZ/10 or something. Because just the plain "10" is crazy. > I happen to have CONFIG_HZ_1000=y, and you're apparently waiting for a > hundreth of a second. Was that what you intended? Because if it was, > it is still crap, since CONFIG_HZ might be 100, and then you're > waiting for ten times longer. Yeah the looks bogus, Daniel and Imre fail, though I think Daniel is on holiday this week, so maybe if you can make it revert, that might be the best option, If you want to just bump it so Ironlake isn't affected, (patch attached). Is this external DP monitor or eDP laptop panel btw? Dave. [-- Attachment #2: 0001-drm-i915-only-use-irq-for-dp-on-post-ilk.patch --] [-- Type: application/octet-stream, Size: 999 bytes --] From 5d68af13f663833c7d3394ca4ecd597f4d8aba1c Mon Sep 17 00:00:00 2001 From: Dave Airlie <airlied@gmail.com> Date: Wed, 27 Feb 2013 13:28:21 +1000 Subject: [PATCH] drm/i915: only use irq for dp on post-ilk Linus reports his ILK is broken. Signed-off-by: Dave Airlie <airlied@redhat.com> --- drivers/gpu/drm/i915/intel_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 31c0205..012553f 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -379,7 +379,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp, uint32_t status; uint32_t aux_clock_divider; int try, precharge; - bool has_aux_irq = INTEL_INFO(dev)->gen >= 5 && !IS_VALLEYVIEW(dev); + bool has_aux_irq = INTEL_INFO(dev)->gen >= 6 && !IS_VALLEYVIEW(dev); /* dp aux is extremely sensitive to irq latency, hence request the * lowest possible wakeup latency and so prevent the cpu from going into -- 1.8.1 ^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-27 3:30 ` Dave Airlie @ 2013-02-27 3:38 ` Linus Torvalds 0 siblings, 0 replies; 33+ messages in thread From: Linus Torvalds @ 2013-02-27 3:38 UTC (permalink / raw) To: Dave Airlie Cc: Dave Airlie, Daniel Vetter, Imre Deak, Linux Kernel Mailing List, DRI mailing list On Tue, Feb 26, 2013 at 7:30 PM, Dave Airlie <airlied@gmail.com> wrote: > > If you want to just bump it so Ironlake isn't affected, (patch attached). It works fine 95% of the time and isn't a hard failure when it doesn't, so this isn't critical. I can wait for it to be fixed a while. > Is this external DP monitor or eDP laptop panel btw? External monitor. Oh, and the monitor is actually connected to HDMI, but the black screen and the DP messages definitely go hand-in-hand. Linus ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-27 1:39 ` Linus Torvalds 2013-02-27 2:25 ` Linus Torvalds 2013-02-27 3:30 ` Dave Airlie @ 2013-02-27 10:04 ` Chris Wilson 2013-03-03 15:39 ` Azat Khuzhin 2013-03-05 19:18 ` Daniel Vetter 4 siblings, 0 replies; 33+ messages in thread From: Chris Wilson @ 2013-02-27 10:04 UTC (permalink / raw) To: Linus Torvalds Cc: Dave Airlie, Daniel Vetter, Imre Deak, Linux Kernel Mailing List, DRI mailing list On Tue, Feb 26, 2013 at 05:39:46PM -0800, Linus Torvalds wrote: > On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie <airlied@linux.ie> wrote: > > > > Highlights: > > > > i915: all over the map, haswell power well enhancements, valleyview macro horrors cleaned up, killing lots of legacy GTT > > code, > > Lowlight: > > There's something wrong with i915 DP detection or whatever. I get > stuff like this: > > [ 8.149931] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status > 0xa145003f > > and after that the screen ends up black. > > It's happened twice now, but is not 100% repeatable. It looks like the > message itself is new, but the black screen is also new and does seem > to happen when I get the message, so... That message appears to be the canary. For whatever reason the DP transfer is not functioning, likely the VDD is not powered up. However, the failure to communicate there causes the modeset to abort, resulting in the blank screen. > The second time I touched the power button, and the machine came back. > Apparently the suspend/resume cycle made it all magically work: the > suspend caused the same errors, but then the resume made it all good > again. So it is reproducible during suspend. That should help narrow down the sequence, thank you. > Some kind of missed initialization at bootup? It's not reliable enough > to bisect, but I obviously suspect commit 9ee32fea5fe8 ("drm/i915: > irq-drive the dp aux communication") since that is where the message > was added.. > > Btw, looking at that commit, what do you think the semantics of the > timeout in something like > > done = wait_event_timeout(dev_priv->gmbus_wait_queue, C, 10); > > would be? What's that magic "10"? It's some totally random number. The hardware is required to return a timedout error message after 400 microseconds. The timeout here is to catch the dysfunction driver, and so was intended to be 10 milliseconds, cf https://patchwork.kernel.org/patch/2160541/ As it happens with your machine 10 jiffies is approximately 10 millisecond, and so we should not be aborting before the hardware has had a chance to signal failure. One way to check whether it is a failure to setup the IRQ or a failure to setup the DP comms would be: diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 7b8bfe8..f2486f1 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -356,9 +356,11 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq) done = wait_event_timeout(dev_priv->gmbus_wait_queue, C, 10); else done = wait_for_atomic(C, 10) == 0; - if (!done) - DRM_ERROR("dp aux hw did not signal timeout (has irq: %i)!\n", - has_aux_irq); + if (!done) { + status = I915_READ_NOTRACE(ch_ctl); + DRM_ERROR("dp aux hw did not signal timeout (has irq: %i), status=%08x!\n", + has_aux_irq, status); + } #undef C return status; -- Chris Wilson, Intel Open Source Technology Centre ^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-27 1:39 ` Linus Torvalds ` (2 preceding siblings ...) 2013-02-27 10:04 ` Chris Wilson @ 2013-03-03 15:39 ` Azat Khuzhin 2013-03-05 19:18 ` Daniel Vetter 4 siblings, 0 replies; 33+ messages in thread From: Azat Khuzhin @ 2013-03-03 15:39 UTC (permalink / raw) To: Linus Torvalds Cc: Dave Airlie, Daniel Vetter, Imre Deak, DRI mailing list, Linux Kernel Mailing List On Wed, Feb 27, 2013 at 5:39 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie <airlied@linux.ie> wrote: >> >> Highlights: >> >> i915: all over the map, haswell power well enhancements, valleyview macro horrors cleaned up, killing lots of legacy GTT >> code, > > Lowlight: > > There's something wrong with i915 DP detection or whatever. I get > stuff like this: > > [ 5.710827] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not > signal timeout (has irq: 1)! > [ 5.720810] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not > signal timeout (has irq: 1)! > [ 5.730794] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not > signal timeout (has irq: 1)! > [ 5.740782] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not > signal timeout (has irq: 1)! > [ 5.750775] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not > signal timeout (has irq: 1)! > [ 5.750778] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status > 0xa145003f > ..... > [ 8.149931] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status > 0xa145003f I have the same messages after upgrading up to b0af9cd9aab60ceb17d3ebabb9fdf4ff0a99cf50 But in my case when I reboot computer the second monitor, that plugged via HDMI, didn't works, end when I run `xrandr`, I have next messages in kern.log Mar 3 18:09:15 home-spb kernel: [12321.758273] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status 0xa143003f Mar 3 18:09:15 home-spb kernel: [12321.771715] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! Mar 3 18:09:15 home-spb kernel: [12321.782712] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! Mar 3 18:09:15 home-spb kernel: [12321.793715] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! Mar 3 18:09:15 home-spb kernel: [12321.804719] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! Mar 3 18:09:15 home-spb kernel: [12321.815725] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! Mar 3 18:09:15 home-spb kernel: [12321.817293] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status 0xa143003f # lspci | fgrep -i graph 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) I tested some commits, and here the results: - Breaked at v3.8-10206-gb0af9cd - Works normal v3.8-rc3-139-g34f2be4 - Works normal v3.8-rc3-188-g10aa17c - Works normal 6dc1c49 I've tested 0001-drm-i915-only-use-irq-for-dp-on-post-ilk.patch and it works for me. Thank, Dave. > > and after that the screen ends up black. > > It's happened twice now, but is not 100% repeatable. It looks like the > message itself is new, but the black screen is also new and does seem > to happen when I get the message, so... > > The second time I touched the power button, and the machine came back. > Apparently the suspend/resume cycle made it all magically work: the > suspend caused the same errors, but then the resume made it all good > again. > > Some kind of missed initialization at bootup? It's not reliable enough > to bisect, but I obviously suspect commit 9ee32fea5fe8 ("drm/i915: > irq-drive the dp aux communication") since that is where the message > was added.. > > Btw, looking at that commit, what do you think the semantics of the > timeout in something like > > done = wait_event_timeout(dev_priv->gmbus_wait_queue, C, 10); > > would be? What's that magic "10"? It's some totally random number. > > Guys, it should be something meaningful. If you meant a tenth of a > second, use HZ/10 or something. Because just the plain "10" is crazy. > I happen to have CONFIG_HZ_1000=y, and you're apparently waiting for a > hundreth of a second. Was that what you intended? Because if it was, > it is still crap, since CONFIG_HZ might be 100, and then you're > waiting for ten times longer. > > IOW, passing in a random number like that is crazy. It cannot possibly > be right. > > I have no idea whether the timeout has anything to do with anything, > but it reinforces my suspicion that there is something wrong with that > commit. > > Linus > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Respectfully Azat Khuzhin Primary email a3at.mail@gmail.com ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-27 1:39 ` Linus Torvalds ` (3 preceding siblings ...) 2013-03-03 15:39 ` Azat Khuzhin @ 2013-03-05 19:18 ` Daniel Vetter 4 siblings, 0 replies; 33+ messages in thread From: Daniel Vetter @ 2013-03-05 19:18 UTC (permalink / raw) To: Linus Torvalds Cc: Dave Airlie, Daniel Vetter, Imre Deak, DRI mailing list, Linux Kernel Mailing List, Paulo Zanoni On Tue, Feb 26, 2013 at 05:39:46PM -0800, Linus Torvalds wrote: > On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie <airlied@linux.ie> wrote: > > > > Highlights: > > > > i915: all over the map, haswell power well enhancements, valleyview macro horrors cleaned up, killing lots of legacy GTT > > code, > > Lowlight: > > There's something wrong with i915 DP detection or whatever. I get > stuff like this: > > [ 5.710827] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not > signal timeout (has irq: 1)! > [ 5.720810] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not > signal timeout (has irq: 1)! > [ 5.730794] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not > signal timeout (has irq: 1)! > [ 5.740782] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not > signal timeout (has irq: 1)! > [ 5.750775] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not > signal timeout (has irq: 1)! > [ 5.750778] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status > 0xa145003f > ..... > [ 8.149931] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status > 0xa145003f > > and after that the screen ends up black. > > It's happened twice now, but is not 100% repeatable. It looks like the > message itself is new, but the black screen is also new and does seem > to happen when I get the message, so... > > The second time I touched the power button, and the machine came back. > Apparently the suspend/resume cycle made it all magically work: the > suspend caused the same errors, but then the resume made it all good > again. > > Some kind of missed initialization at bootup? It's not reliable enough > to bisect, but I obviously suspect commit 9ee32fea5fe8 ("drm/i915: > irq-drive the dp aux communication") since that is where the message > was added.. > > Btw, looking at that commit, what do you think the semantics of the > timeout in something like > > done = wait_event_timeout(dev_priv->gmbus_wait_queue, C, 10); > > would be? What's that magic "10"? It's some totally random number. > > Guys, it should be something meaningful. If you meant a tenth of a > second, use HZ/10 or something. Because just the plain "10" is crazy. > I happen to have CONFIG_HZ_1000=y, and you're apparently waiting for a > hundreth of a second. Was that what you intended? Because if it was, > it is still crap, since CONFIG_HZ might be 100, and then you're > waiting for ten times longer. > > IOW, passing in a random number like that is crazy. It cannot possibly > be right. > > I have no idea whether the timeout has anything to do with anything, > but it reinforces my suspicion that there is something wrong with that > commit. Ok, I've merged two patches from Paulo, one to fixup the harmless jiffies vs. msec confusion. And the other to plug a race in our irq handler which did lead to missed dp aux interrupts according to some digging done by Imre. The important patch is the current tip of git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes 44498aea293b37af1d463acd9658cdce1ecdf427 drm/i915: also disable south interrupts when handling them Just in case you want to give it a quick whirl. Since the failed dp aux transaction caused the resume modeset to fail for you (resulting in the black screen) I hope that this should fix both issues. I'll forward the pull to Dave in a few days since atm I'm stalling a bit for confirmation on another little regression fix. And there's nothing earth-shattering in my -fixes queue right now. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-26 0:05 Dave Airlie 2013-02-26 1:22 ` Linus Torvalds 2013-02-27 1:39 ` Linus Torvalds @ 2013-02-27 16:34 ` Josh Boyer 2013-02-27 20:20 ` Josh Boyer 2 siblings, 1 reply; 33+ messages in thread From: Josh Boyer @ 2013-02-27 16:34 UTC (permalink / raw) To: Dave Airlie, Alex Deucher, Jerome Glisse Cc: torvalds, DRI mailing list, linux-kernel On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie <airlied@linux.ie> wrote: > Alex Deucher (29): > drm/radeon: halt engines before disabling MC (6xx/7xx) > drm/radeon: halt engines before disabling MC (evergreen) > drm/radeon: halt engines before disabling MC (cayman/TN) > drm/radeon: halt engines before disabling MC (si) > drm/radeon: use the reset mask to determine if rings are hung Something in this series of commits is causing the GPU to hang on reboot on my Dell XPS 8300 machine. That has a: 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Caicos [Radeon HD 6450] card in it. After reboots, I get a screen that looks like this: http://t.co/tPnT6xQZUK I can hit it fairly consistently after a few reboots, so I tried doing a git bisect on the radeon driver and it came down to: ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit commit ca57802e521de54341efc8a56f70571f79ffac72 Author: Alex Deucher <alexander.deucher@amd.com> Date: Wed Jan 23 18:56:08 2013 -0500 drm/radeon: halt engines before disabling MC (6xx/7xx) It's better to halt the engines before we disable the MC. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Basically what seems to be happening is drm:r600_ring_test fails the ring 0 test and disables GPU accel. Things go downhill from there, as the driver continues to try and set hpd after the interrupts have been disabled already. The relevant dmesg portions are below. I think Alex has a patch to not do that and I built a kernel with that and the splat went away, but the actual problem of the rainbow static screen still remains. I can send the bisect log if people are interested. I'll try reverting that single commit and seeing if it fixes things on a known "bad" kernel. I'd be happy to try further debugging suggestions if this doesn't make sense. josh Full dmesg can be found here: http://paste.fedoraproject.org/3903/ [ 3.277618] [drm] radeon kernel modesetting enabled. [ 3.277708] checking generic (d0000000 5b0000) vs hw (d0000000 10000000) [ 3.277710] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver [ 3.277787] Console: switching to colour dummy device 80x25 [ 3.282108] [drm] initializing kernel modesetting (CAICOS 0x1002:0x6779 0x1B0A:0x909D). [ 3.282286] [drm] register mmio base: 0xFE620000 [ 3.282287] [drm] register mmio size: 131072 [ 3.282782] ATOM BIOS: DeLL [ 3.282806] radeon 0000:01:00.0: GPU softreset: 0x00000400 [ 3.282808] radeon 0000:01:00.0: GRBM_STATUS = 0x00003828 [ 3.282810] radeon 0000:01:00.0: GRBM_STATUS_SE0 = 0x00000007 [ 3.282812] radeon 0000:01:00.0: GRBM_STATUS_SE1 = 0x00000007 [ 3.282814] radeon 0000:01:00.0: SRBM_STATUS = 0x200000C0 [ 3.282816] radeon 0000:01:00.0: SRBM_STATUS2 = 0x00000000 [ 3.282818] radeon 0000:01:00.0: R_008674_CP_STALLED_STAT1 = 0x00000000 [ 3.282820] radeon 0000:01:00.0: R_008678_CP_STALLED_STAT2 = 0x00000000 [ 3.282822] radeon 0000:01:00.0: R_00867C_CP_BUSY_STAT = 0x00000000 [ 3.282824] radeon 0000:01:00.0: R_008680_CP_STAT = 0x00000000 [ 3.282826] radeon 0000:01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 3.291890] radeon 0000:01:00.0: SRBM_SOFT_RESET=0x00000800 [ 3.309450] radeon 0000:01:00.0: GRBM_STATUS = 0x00003828 [ 3.309452] radeon 0000:01:00.0: GRBM_STATUS_SE0 = 0x00000007 [ 3.309454] radeon 0000:01:00.0: GRBM_STATUS_SE1 = 0x00000007 [ 3.309456] radeon 0000:01:00.0: SRBM_STATUS = 0x200002C0 [ 3.309458] radeon 0000:01:00.0: SRBM_STATUS2 = 0x00000000 [ 3.309460] radeon 0000:01:00.0: R_008674_CP_STALLED_STAT1 = 0x00000000 [ 3.309462] radeon 0000:01:00.0: R_008678_CP_STALLED_STAT2 = 0x00000000 [ 3.309464] radeon 0000:01:00.0: R_00867C_CP_BUSY_STAT = 0x00000000 [ 3.309466] radeon 0000:01:00.0: R_008680_CP_STAT = 0x00000000 [ 3.309468] radeon 0000:01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 [ 3.309997] radeon 0000:01:00.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used) [ 3.310000] radeon 0000:01:00.0: GTT: 512M 0x0000000040000000 - 0x000000005FFFFFFF [ 3.314766] [drm] Detected VRAM RAM=1024M, BAR=256M [ 3.314770] [drm] RAM width 64bits DDR [ 3.316172] [TTM] Zone kernel: Available graphics memory: 6131076 kiB [ 3.316176] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [ 3.316179] [TTM] Initializing pool allocator [ 3.316288] [TTM] Initializing DMA pool allocator [ 3.316950] [drm] radeon: 1024M of VRAM memory ready [ 3.316975] [drm] radeon: 512M of GTT memory ready. [ 3.317367] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 3.317369] [drm] Driver supports precise vblank timestamp query. [ 3.317529] radeon 0000:01:00.0: irq 44 for MSI/MSI-X [ 3.317599] radeon 0000:01:00.0: radeon: using MSI. [ 3.317882] [drm] radeon: irq initialized. [ 3.317902] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 3.318405] [drm] probing gen 2 caps for device 8086:101 = 2/0 [ 3.318409] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [ 3.318739] [drm] Loading CAICOS Microcode [ 3.343934] [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). [ 3.345316] radeon 0000:01:00.0: WB enabled [ 3.345322] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0xffff8803125a5c00 [ 3.345326] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0xffff8803125a5c0c [ 3.569822] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD) [ 3.569835] radeon 0000:01:00.0: disabling GPU acceleration [ 3.576708] radeon 0000:01:00.0: ffff88031413eee8 unpin not necessary [ 3.583089] [drm] Radeon Display Connectors [ 3.583091] [drm] Connector 0: [ 3.583093] [drm] HDMI-A-1 [ 3.583093] [drm] HPD2 [ 3.583095] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c [ 3.583096] [drm] Encoders: [ 3.583097] [drm] DFP1: INTERNAL_UNIPHY1 [ 3.583098] [drm] Connector 1: [ 3.583098] [drm] DVI-D-1 [ 3.583099] [drm] HPD4 [ 3.583101] [drm] DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c [ 3.583101] [drm] Encoders: [ 3.583102] [drm] DFP2: INTERNAL_UNIPHY [ 3.583103] [drm] Connector 2: [ 3.583104] [drm] VGA-1 [ 3.583105] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [ 3.583106] [drm] Encoders: [ 3.583107] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 3.583257] ------------[ cut here ]------------ [ 3.583275] WARNING: at drivers/gpu/drm/radeon/evergreen.c:2659 evergreen_irq_set+0xaaa/0xac0 [radeon]() [ 3.583276] Hardware name: XPS 8300 [ 3.583277] Can't enable IRQ/MSI because no handler is installed [ 3.583278] Modules linked in: radeon(+) usb_storage i2c_algo_bit drm_kms_helper ttm drm i2c_core [ 3.583284] Pid: 197, comm: systemd-udevd Not tainted 3.8.0-rc3+ #23 [ 3.583285] Call Trace: [ 3.583290] [<ffffffff8106a7bf>] warn_slowpath_common+0x7f/0xc0 [ 3.583292] [<ffffffff8106a8b6>] warn_slowpath_fmt+0x46/0x50 [ 3.583303] [<ffffffffa00f86ca>] evergreen_irq_set+0xaaa/0xac0 [radeon] [ 3.583306] [<ffffffff817179e1>] ? _raw_spin_lock_irqsave+0x91/0xb0 [ 3.583318] [<ffffffffa00c74a2>] ? radeon_irq_kms_enable_hpd+0x32/0x90 [radeon] [ 3.583328] [<ffffffffa00c74db>] radeon_irq_kms_enable_hpd+0x6b/0x90 [radeon] [ 3.583339] [<ffffffffa00f5e64>] evergreen_hpd_init+0xb4/0x150 [radeon] [ 3.583349] [<ffffffffa00bf655>] radeon_modeset_init+0x325/0xb90 [radeon] [ 3.583359] [<ffffffffa009b220>] radeon_driver_load_kms+0xf0/0x180 [radeon] [ 3.583366] [<ffffffffa001ddc6>] drm_get_pci_dev+0x186/0x2d0 [drm] [ 3.583375] [<ffffffffa00980c1>] ? radeon_pci_probe+0xa1/0xf0 [radeon] [ 3.583383] [<ffffffffa00980d3>] radeon_pci_probe+0xb3/0xf0 [radeon] [ 3.583386] [<ffffffff8138f87b>] local_pci_probe+0x4b/0x80 [ 3.583389] [<ffffffff8138fad1>] pci_device_probe+0x111/0x120 [ 3.583392] [<ffffffff8146fa9b>] driver_probe_device+0x8b/0x390 [ 3.583393] [<ffffffff8146fe4b>] __driver_attach+0xab/0xb0 [ 3.583395] [<ffffffff8146fda0>] ? driver_probe_device+0x390/0x390 [ 3.583398] [<ffffffff8146da25>] bus_for_each_dev+0x55/0x90 [ 3.583400] [<ffffffff8146f3fe>] driver_attach+0x1e/0x20 [ 3.583402] [<ffffffff8146f020>] bus_add_driver+0x1b0/0x2a0 [ 3.583403] [<ffffffffa015b000>] ? 0xffffffffa015afff [ 3.583405] [<ffffffff81470547>] driver_register+0x77/0x170 [ 3.583407] [<ffffffffa015b000>] ? 0xffffffffa015afff [ 3.583409] [<ffffffff8138e894>] __pci_register_driver+0x64/0x70 [ 3.583414] [<ffffffffa001e02a>] drm_pci_init+0x11a/0x130 [drm] [ 3.583416] [<ffffffffa015b000>] ? 0xffffffffa015afff [ 3.583417] [<ffffffffa015b000>] ? 0xffffffffa015afff [ 3.583425] [<ffffffffa015b05f>] radeon_init+0x5f/0x1000 [radeon] [ 3.583428] [<ffffffff8100215a>] do_one_initcall+0x12a/0x180 [ 3.583431] [<ffffffff810ebfd4>] load_module+0x1b74/0x2230 [ 3.583433] [<ffffffff8137cfd0>] ? ddebug_proc_open+0xd0/0xd0 [ 3.583436] [<ffffffff8136870e>] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 3.583438] [<ffffffff810ec767>] sys_init_module+0xd7/0x120 [ 3.583441] [<ffffffff81720e99>] system_call_fastpath+0x16/0x1b [ 3.583442] ---[ end trace e25f56762621a4a9 ]--- [ 3.583482] [drm] Internal thermal controller with fan control [ 3.585338] [drm] radeon: power management initialized [ 3.640125] [drm] fb mappable at 0xD0142000 [ 3.640130] [drm] vram apper at 0xD0000000 [ 3.640132] [drm] size 8294400 [ 3.640134] [drm] fb depth is 24 [ 3.640136] [drm] pitch is 7680 [ 3.641668] fbcon: radeondrmfb (fb0) is primary device [ 3.664208] Console: switching to colour frame buffer device 240x67 [ 3.672340] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device [ 3.672344] radeon 0000:01:00.0: registered panic notifier [ 3.672462] [drm] Initialized radeon 2.29.0 20080528 for 0000:01:00.0 on minor 0 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-27 16:34 ` Josh Boyer @ 2013-02-27 20:20 ` Josh Boyer 2013-02-27 20:24 ` Josh Boyer 2013-02-28 0:01 ` Josh Boyer 0 siblings, 2 replies; 33+ messages in thread From: Josh Boyer @ 2013-02-27 20:20 UTC (permalink / raw) To: Dave Airlie, Alex Deucher, Jerome Glisse Cc: torvalds, DRI mailing list, linux-kernel On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer <jwboyer@gmail.com> wrote: > On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie <airlied@linux.ie> wrote: >> Alex Deucher (29): >> drm/radeon: halt engines before disabling MC (6xx/7xx) >> drm/radeon: halt engines before disabling MC (evergreen) >> drm/radeon: halt engines before disabling MC (cayman/TN) >> drm/radeon: halt engines before disabling MC (si) >> drm/radeon: use the reset mask to determine if rings are hung > > Something in this series of commits is causing the GPU to hang on reboot > on my Dell XPS 8300 machine. That has a: > > 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee > ATI Caicos [Radeon HD 6450] > > card in it. After reboots, I get a screen that looks like this: > > http://t.co/tPnT6xQZUK > > I can hit it fairly consistently after a few reboots, so I tried doing a > git bisect on the radeon driver and it came down to: > > ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit So I don't think that's actually the cause of the problem. Or at least not that alone. I reverted it on top of Linus' latest tree and I still get the lockups. Thus far I've reverted: drm/radeon: use status regs to determine what to reset (6xx/7xx) drm/radeon: use status regs to determine what to reset (evergreen) drm/radeon: use status regs to determine what to reset (cayman) drm/radeon: use status regs to determine what to reset (si) drm/radeon: halt engines before disabling MC (6xx/7xx) drm/radeon: halt engines before disabling MC (evergreen) drm/radeon: halt engines before disabling MC (cayman/TN) drm/radeon: halt engines before disabling MC (si) drm/radeon: use the reset mask to determine if rings are hung and can still recreate the issue. I'm starting to think the problem is in one of: drm/radeon: rework GPU reset on r6xx/r7xx drm/radeon: rework GPU reset on evergreen drm/radeon: rework GPU reset on cayman/TN drm/radeon: rework GPU reset on cayman/TN (which should be si) Still trying to figure out exactly which code paths are used on this card, but I'll keep poking at it. Any ideas or tips for debug are more than welcome. josh ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-27 20:20 ` Josh Boyer @ 2013-02-27 20:24 ` Josh Boyer 2013-02-28 0:01 ` Josh Boyer 1 sibling, 0 replies; 33+ messages in thread From: Josh Boyer @ 2013-02-27 20:24 UTC (permalink / raw) To: Dave Airlie, Alex Deucher, Jerome Glisse Cc: torvalds, DRI mailing list, linux-kernel On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer <jwboyer@gmail.com> wrote: > On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer <jwboyer@gmail.com> wrote: >> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie <airlied@linux.ie> wrote: >>> Alex Deucher (29): >>> drm/radeon: halt engines before disabling MC (6xx/7xx) >>> drm/radeon: halt engines before disabling MC (evergreen) >>> drm/radeon: halt engines before disabling MC (cayman/TN) >>> drm/radeon: halt engines before disabling MC (si) >>> drm/radeon: use the reset mask to determine if rings are hung >> >> Something in this series of commits is causing the GPU to hang on reboot >> on my Dell XPS 8300 machine. That has a: >> >> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee >> ATI Caicos [Radeon HD 6450] >> >> card in it. After reboots, I get a screen that looks like this: >> >> http://t.co/tPnT6xQZUK >> >> I can hit it fairly consistently after a few reboots, so I tried doing a >> git bisect on the radeon driver and it came down to: >> >> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit > > So I don't think that's actually the cause of the problem. Or at least > not that alone. I reverted it on top of Linus' latest tree and I still > get the lockups. > > Thus far I've reverted: > > drm/radeon: use status regs to determine what to reset (6xx/7xx) > drm/radeon: use status regs to determine what to reset (evergreen) > drm/radeon: use status regs to determine what to reset (cayman) > drm/radeon: use status regs to determine what to reset (si) > drm/radeon: halt engines before disabling MC (6xx/7xx) > drm/radeon: halt engines before disabling MC (evergreen) > drm/radeon: halt engines before disabling MC (cayman/TN) > drm/radeon: halt engines before disabling MC (si) > drm/radeon: use the reset mask to determine if rings are hung > > and can still recreate the issue. I'm starting to think the problem is Sigh. Of course I just realized that I haven't been regenerating the initramfs, so I'm not even testing what I'm building at this point. So all I know is that it's broken somewhere between the two commits in my initial bisect log. I've had better days. josh ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-27 20:20 ` Josh Boyer 2013-02-27 20:24 ` Josh Boyer @ 2013-02-28 0:01 ` Josh Boyer 2013-02-28 1:14 ` Josh Boyer 1 sibling, 1 reply; 33+ messages in thread From: Josh Boyer @ 2013-02-28 0:01 UTC (permalink / raw) To: Dave Airlie, Alex Deucher, Jerome Glisse Cc: torvalds, DRI mailing list, linux-kernel On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer <jwboyer@gmail.com> wrote: > On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer <jwboyer@gmail.com> wrote: >> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie <airlied@linux.ie> wrote: >>> Alex Deucher (29): >>> drm/radeon: halt engines before disabling MC (6xx/7xx) >>> drm/radeon: halt engines before disabling MC (evergreen) >>> drm/radeon: halt engines before disabling MC (cayman/TN) >>> drm/radeon: halt engines before disabling MC (si) >>> drm/radeon: use the reset mask to determine if rings are hung >> >> Something in this series of commits is causing the GPU to hang on reboot >> on my Dell XPS 8300 machine. That has a: >> >> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee >> ATI Caicos [Radeon HD 6450] >> >> card in it. After reboots, I get a screen that looks like this: >> >> http://t.co/tPnT6xQZUK >> >> I can hit it fairly consistently after a few reboots, so I tried doing a >> git bisect on the radeon driver and it came down to: >> >> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit > > So I don't think that's actually the cause of the problem. Or at least > not that alone. I reverted it on top of Linus' latest tree and I still > get the lockups. Actually, git bisect does seem to have gotten it correct. Once I actually tested the revert of just that on top of Linus' tree (commit d895cb1af1), things seem to be working much better. I've rebooted a dozen times without a lockup. The most I've seen it take on a kernel with that commit included is 3 reboots, so that's definitely at least an improvement. Now that I seem to have narrowed down which commit is broken, I'd be happy to test fixes, etc. Sorry for the noise from earlier today. josh ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-28 0:01 ` Josh Boyer @ 2013-02-28 1:14 ` Josh Boyer 2013-02-28 13:38 ` Alex Deucher 0 siblings, 1 reply; 33+ messages in thread From: Josh Boyer @ 2013-02-28 1:14 UTC (permalink / raw) To: Dave Airlie, Alex Deucher, Jerome Glisse Cc: torvalds, DRI mailing list, linux-kernel On Wed, Feb 27, 2013 at 7:01 PM, Josh Boyer <jwboyer@gmail.com> wrote: > On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer <jwboyer@gmail.com> wrote: >> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer <jwboyer@gmail.com> wrote: >>> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie <airlied@linux.ie> wrote: >>>> Alex Deucher (29): >>>> drm/radeon: halt engines before disabling MC (6xx/7xx) >>>> drm/radeon: halt engines before disabling MC (evergreen) >>>> drm/radeon: halt engines before disabling MC (cayman/TN) >>>> drm/radeon: halt engines before disabling MC (si) >>>> drm/radeon: use the reset mask to determine if rings are hung >>> >>> Something in this series of commits is causing the GPU to hang on reboot >>> on my Dell XPS 8300 machine. That has a: >>> >>> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee >>> ATI Caicos [Radeon HD 6450] >>> >>> card in it. After reboots, I get a screen that looks like this: >>> >>> http://t.co/tPnT6xQZUK >>> >>> I can hit it fairly consistently after a few reboots, so I tried doing a >>> git bisect on the radeon driver and it came down to: >>> >>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit >> >> So I don't think that's actually the cause of the problem. Or at least >> not that alone. I reverted it on top of Linus' latest tree and I still >> get the lockups. > > Actually, git bisect does seem to have gotten it correct. Once I > actually tested the revert of just that on top of Linus' tree (commit > d895cb1af1), things seem to be working much better. I've rebooted a > dozen times without a lockup. The most I've seen it take on a kernel > with that commit included is 3 reboots, so that's definitely at least an > improvement. I give up. GPU issues are not my thing. 2 reboots after I sent that it gave me pretty rainbow static again. So it might have been an improvement, but revert it is not a solution. Looking at there rest of the commits, the whole GPU rework might be suspect, but I clearly have no clue. josh ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-28 1:14 ` Josh Boyer @ 2013-02-28 13:38 ` Alex Deucher 2013-02-28 13:44 ` Josh Boyer 0 siblings, 1 reply; 33+ messages in thread From: Alex Deucher @ 2013-02-28 13:38 UTC (permalink / raw) To: Josh Boyer Cc: Dave Airlie, Alex Deucher, Jerome Glisse, torvalds, linux-kernel, DRI mailing list On Wed, Feb 27, 2013 at 8:14 PM, Josh Boyer <jwboyer@gmail.com> wrote: > On Wed, Feb 27, 2013 at 7:01 PM, Josh Boyer <jwboyer@gmail.com> wrote: >> On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer <jwboyer@gmail.com> wrote: >>> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer <jwboyer@gmail.com> wrote: >>>> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie <airlied@linux.ie> wrote: >>>>> Alex Deucher (29): >>>>> drm/radeon: halt engines before disabling MC (6xx/7xx) >>>>> drm/radeon: halt engines before disabling MC (evergreen) >>>>> drm/radeon: halt engines before disabling MC (cayman/TN) >>>>> drm/radeon: halt engines before disabling MC (si) >>>>> drm/radeon: use the reset mask to determine if rings are hung >>>> >>>> Something in this series of commits is causing the GPU to hang on reboot >>>> on my Dell XPS 8300 machine. That has a: >>>> >>>> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee >>>> ATI Caicos [Radeon HD 6450] >>>> >>>> card in it. After reboots, I get a screen that looks like this: >>>> >>>> http://t.co/tPnT6xQZUK >>>> >>>> I can hit it fairly consistently after a few reboots, so I tried doing a >>>> git bisect on the radeon driver and it came down to: >>>> >>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit >>> >>> So I don't think that's actually the cause of the problem. Or at least >>> not that alone. I reverted it on top of Linus' latest tree and I still >>> get the lockups. >> >> Actually, git bisect does seem to have gotten it correct. Once I >> actually tested the revert of just that on top of Linus' tree (commit >> d895cb1af1), things seem to be working much better. I've rebooted a >> dozen times without a lockup. The most I've seen it take on a kernel >> with that commit included is 3 reboots, so that's definitely at least an >> improvement. > > I give up. GPU issues are not my thing. 2 reboots after I sent that it > gave me pretty rainbow static again. So it might have been an > improvement, but revert it is not a solution. > > Looking at there rest of the commits, the whole GPU rework might be > suspect, but I clearly have no clue. GPUs are tricky beasts :) ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the problem anyway since it only affects 6xx/7xx and your card is handled by the evergreen code. I'll put together some patches to help narrow down the problem. Alex ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-28 13:38 ` Alex Deucher @ 2013-02-28 13:44 ` Josh Boyer 2013-02-28 15:09 ` Alex Deucher 0 siblings, 1 reply; 33+ messages in thread From: Josh Boyer @ 2013-02-28 13:44 UTC (permalink / raw) To: Alex Deucher Cc: Dave Airlie, Alex Deucher, Jerome Glisse, torvalds, linux-kernel, DRI mailing list On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher <alexdeucher@gmail.com> wrote: > On Wed, Feb 27, 2013 at 8:14 PM, Josh Boyer <jwboyer@gmail.com> wrote: >> On Wed, Feb 27, 2013 at 7:01 PM, Josh Boyer <jwboyer@gmail.com> wrote: >>> On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer <jwboyer@gmail.com> wrote: >>>> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer <jwboyer@gmail.com> wrote: >>>>> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie <airlied@linux.ie> wrote: >>>>>> Alex Deucher (29): >>>>>> drm/radeon: halt engines before disabling MC (6xx/7xx) >>>>>> drm/radeon: halt engines before disabling MC (evergreen) >>>>>> drm/radeon: halt engines before disabling MC (cayman/TN) >>>>>> drm/radeon: halt engines before disabling MC (si) >>>>>> drm/radeon: use the reset mask to determine if rings are hung >>>>> >>>>> Something in this series of commits is causing the GPU to hang on reboot >>>>> on my Dell XPS 8300 machine. That has a: >>>>> >>>>> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee >>>>> ATI Caicos [Radeon HD 6450] >>>>> >>>>> card in it. After reboots, I get a screen that looks like this: >>>>> >>>>> http://t.co/tPnT6xQZUK >>>>> >>>>> I can hit it fairly consistently after a few reboots, so I tried doing a >>>>> git bisect on the radeon driver and it came down to: >>>>> >>>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit >>>> >>>> So I don't think that's actually the cause of the problem. Or at least >>>> not that alone. I reverted it on top of Linus' latest tree and I still >>>> get the lockups. >>> >>> Actually, git bisect does seem to have gotten it correct. Once I >>> actually tested the revert of just that on top of Linus' tree (commit >>> d895cb1af1), things seem to be working much better. I've rebooted a >>> dozen times without a lockup. The most I've seen it take on a kernel >>> with that commit included is 3 reboots, so that's definitely at least an >>> improvement. >> >> I give up. GPU issues are not my thing. 2 reboots after I sent that it >> gave me pretty rainbow static again. So it might have been an >> improvement, but revert it is not a solution. >> >> Looking at there rest of the commits, the whole GPU rework might be >> suspect, but I clearly have no clue. > > GPUs are tricky beasts :) Understatement ;). > ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the > problem anyway since it only affects 6xx/7xx and your card is handled > by the evergreen code. I'll put together some patches to help narrow > down the problem. Yeah, that's the biggest problem I have, not knowing which functions are actually being executed for this card. It looks like a combination of stuff in evergreen.c and ni.c, but I have no idea. Patches would be great. If nothing else, I'm really good at building kernels and rebooting by now. josh ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-28 13:44 ` Josh Boyer @ 2013-02-28 15:09 ` Alex Deucher 2013-02-28 15:15 ` Josh Boyer 0 siblings, 1 reply; 33+ messages in thread From: Alex Deucher @ 2013-02-28 15:09 UTC (permalink / raw) To: Josh Boyer Cc: Dave Airlie, Alex Deucher, Jerome Glisse, torvalds, linux-kernel, DRI mailing list [-- Attachment #1: Type: text/plain, Size: 3404 bytes --] On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer <jwboyer@gmail.com> wrote: > On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher <alexdeucher@gmail.com> wrote: >> On Wed, Feb 27, 2013 at 8:14 PM, Josh Boyer <jwboyer@gmail.com> wrote: >>> On Wed, Feb 27, 2013 at 7:01 PM, Josh Boyer <jwboyer@gmail.com> wrote: >>>> On Wed, Feb 27, 2013 at 3:20 PM, Josh Boyer <jwboyer@gmail.com> wrote: >>>>> On Wed, Feb 27, 2013 at 11:34 AM, Josh Boyer <jwboyer@gmail.com> wrote: >>>>>> On Mon, Feb 25, 2013 at 7:05 PM, Dave Airlie <airlied@linux.ie> wrote: >>>>>>> Alex Deucher (29): >>>>>>> drm/radeon: halt engines before disabling MC (6xx/7xx) >>>>>>> drm/radeon: halt engines before disabling MC (evergreen) >>>>>>> drm/radeon: halt engines before disabling MC (cayman/TN) >>>>>>> drm/radeon: halt engines before disabling MC (si) >>>>>>> drm/radeon: use the reset mask to determine if rings are hung >>>>>> >>>>>> Something in this series of commits is causing the GPU to hang on reboot >>>>>> on my Dell XPS 8300 machine. That has a: >>>>>> >>>>>> 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee >>>>>> ATI Caicos [Radeon HD 6450] >>>>>> >>>>>> card in it. After reboots, I get a screen that looks like this: >>>>>> >>>>>> http://t.co/tPnT6xQZUK >>>>>> >>>>>> I can hit it fairly consistently after a few reboots, so I tried doing a >>>>>> git bisect on the radeon driver and it came down to: >>>>>> >>>>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit >>>>> >>>>> So I don't think that's actually the cause of the problem. Or at least >>>>> not that alone. I reverted it on top of Linus' latest tree and I still >>>>> get the lockups. >>>> >>>> Actually, git bisect does seem to have gotten it correct. Once I >>>> actually tested the revert of just that on top of Linus' tree (commit >>>> d895cb1af1), things seem to be working much better. I've rebooted a >>>> dozen times without a lockup. The most I've seen it take on a kernel >>>> with that commit included is 3 reboots, so that's definitely at least an >>>> improvement. >>> >>> I give up. GPU issues are not my thing. 2 reboots after I sent that it >>> gave me pretty rainbow static again. So it might have been an >>> improvement, but revert it is not a solution. >>> >>> Looking at there rest of the commits, the whole GPU rework might be >>> suspect, but I clearly have no clue. >> >> GPUs are tricky beasts :) > > Understatement ;). > >> ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the >> problem anyway since it only affects 6xx/7xx and your card is handled >> by the evergreen code. I'll put together some patches to help narrow >> down the problem. > > Yeah, that's the biggest problem I have, not knowing which functions are > actually being executed for this card. It looks like a combination of > stuff in evergreen.c and ni.c, but I have no idea. > > Patches would be great. If nothing else, I'm really good at building > kernels and rebooting by now. Two possible fixes attached. The first attempts a full reset of all blocks if the MC (memory controller) is hung. That may work better than just resetting the MC. The second just disables MC reset. I'm not sure we can reliably tell if it's busy due to display requests hitting the MC periodically which would lead to needlessly resetting it possibly leading to failures like you are seeing. Alex [-- Attachment #2: 0001-drm-radeon-XXX-try-a-full-reset-if-the-MC-is-busy.patch --] [-- Type: text/x-patch, Size: 992 bytes --] From 9a648b04474ed230601c3c3e816cb281ebaad604 Mon Sep 17 00:00:00 2001 From: Alex Deucher <alexander.deucher@amd.com> Date: Thu, 28 Feb 2013 09:56:48 -0500 Subject: [PATCH] drm/radeon: XXX try a full reset if the MC is busy See if this helps. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> --- drivers/gpu/drm/radeon/evergreen.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c index 3c38ea4..bbcac11 100644 --- a/drivers/gpu/drm/radeon/evergreen.c +++ b/drivers/gpu/drm/radeon/evergreen.c @@ -2438,6 +2438,12 @@ static u32 evergreen_gpu_check_soft_reset(struct radeon_device *rdev) if (tmp & L2_BUSY) reset_mask |= RADEON_RESET_VMC; + /* reset everything if we attempt to reset the MC */ + if (reset_mask & RADEON_RESET_MC) { + dev_info(rdev->dev, "MC busy: 0x%08X, resetting ALL\n", reset_mask); + reset_mask = 0xffffffff; + } + return reset_mask; } -- 1.7.7.5 [-- Attachment #3: 0001-drm-radeon-XXX-skip-MC-reset-as-it-s-probably-not-hu.patch --] [-- Type: text/x-patch, Size: 1138 bytes --] From 834c26ab02e3581ea97b39a90fc0637e7becfa67 Mon Sep 17 00:00:00 2001 From: Alex Deucher <alexander.deucher@amd.com> Date: Thu, 28 Feb 2013 10:03:08 -0500 Subject: [PATCH] drm/radeon: XXX skip MC reset as it's probably not hung The MC is mostly likely busy (e.g., display requests), not hung so no need to reset it. Doing an MC reset is tricky and not particularly reliable. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> --- drivers/gpu/drm/radeon/evergreen.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c index 3c38ea4..0f15ada 100644 --- a/drivers/gpu/drm/radeon/evergreen.c +++ b/drivers/gpu/drm/radeon/evergreen.c @@ -2438,6 +2438,12 @@ static u32 evergreen_gpu_check_soft_reset(struct radeon_device *rdev) if (tmp & L2_BUSY) reset_mask |= RADEON_RESET_VMC; + /* Skip MC reset as it's mostly likely not hung, just busy */ + if (reset_mask & RADEON_RESET_MC) { + dev_info(rdev->dev, "MC busy: 0x%08X, clearing.\n", reset_mask); + reset_mask &= ~RADEON_RESET_MC; + } + return reset_mask; } -- 1.7.7.5 ^ permalink raw reply related [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-28 15:09 ` Alex Deucher @ 2013-02-28 15:15 ` Josh Boyer 2013-02-28 18:59 ` Josh Boyer 0 siblings, 1 reply; 33+ messages in thread From: Josh Boyer @ 2013-02-28 15:15 UTC (permalink / raw) To: Alex Deucher Cc: Dave Airlie, Alex Deucher, Jerome Glisse, torvalds, linux-kernel, DRI mailing list On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher <alexdeucher@gmail.com> wrote: > On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer <jwboyer@gmail.com> wrote: >> On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher <alexdeucher@gmail.com> wrote: >>>>>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit >>>>>> >>>>>> So I don't think that's actually the cause of the problem. Or at least >>>>>> not that alone. I reverted it on top of Linus' latest tree and I still >>>>>> get the lockups. >>>>> >>>>> Actually, git bisect does seem to have gotten it correct. Once I >>>>> actually tested the revert of just that on top of Linus' tree (commit >>>>> d895cb1af1), things seem to be working much better. I've rebooted a >>>>> dozen times without a lockup. The most I've seen it take on a kernel >>>>> with that commit included is 3 reboots, so that's definitely at least an >>>>> improvement. >>>> >>>> I give up. GPU issues are not my thing. 2 reboots after I sent that it >>>> gave me pretty rainbow static again. So it might have been an >>>> improvement, but revert it is not a solution. >>>> >>>> Looking at there rest of the commits, the whole GPU rework might be >>>> suspect, but I clearly have no clue. >>> >>> GPUs are tricky beasts :) >> >> Understatement ;). >> >>> ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the >>> problem anyway since it only affects 6xx/7xx and your card is handled >>> by the evergreen code. I'll put together some patches to help narrow >>> down the problem. >> >> Yeah, that's the biggest problem I have, not knowing which functions are >> actually being executed for this card. It looks like a combination of >> stuff in evergreen.c and ni.c, but I have no idea. >> >> Patches would be great. If nothing else, I'm really good at building >> kernels and rebooting by now. > > Two possible fixes attached. The first attempts a full reset of all > blocks if the MC (memory controller) is hung. That may work better > than just resetting the MC. The second just disables MC reset. I'm > not sure we can reliably tell if it's busy due to display requests > hitting the MC periodically which would lead to needlessly resetting > it possibly leading to failures like you are seeing. OK. I'll test them individually. It will probably take a bit because I'll want to do numerous reboots if things seem "fixed" with one or the other. I'll let you know how things go. josh ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-28 15:15 ` Josh Boyer @ 2013-02-28 18:59 ` Josh Boyer 2013-03-05 15:21 ` Josh Boyer 0 siblings, 1 reply; 33+ messages in thread From: Josh Boyer @ 2013-02-28 18:59 UTC (permalink / raw) To: Alex Deucher Cc: Dave Airlie, Alex Deucher, Jerome Glisse, torvalds, linux-kernel, DRI mailing list On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer <jwboyer@gmail.com> wrote: > On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher <alexdeucher@gmail.com> wrote: >> On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer <jwboyer@gmail.com> wrote: >>> On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher <alexdeucher@gmail.com> wrote: >>>>>>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit >>>>>>> >>>>>>> So I don't think that's actually the cause of the problem. Or at least >>>>>>> not that alone. I reverted it on top of Linus' latest tree and I still >>>>>>> get the lockups. >>>>>> >>>>>> Actually, git bisect does seem to have gotten it correct. Once I >>>>>> actually tested the revert of just that on top of Linus' tree (commit >>>>>> d895cb1af1), things seem to be working much better. I've rebooted a >>>>>> dozen times without a lockup. The most I've seen it take on a kernel >>>>>> with that commit included is 3 reboots, so that's definitely at least an >>>>>> improvement. >>>>> >>>>> I give up. GPU issues are not my thing. 2 reboots after I sent that it >>>>> gave me pretty rainbow static again. So it might have been an >>>>> improvement, but revert it is not a solution. >>>>> >>>>> Looking at there rest of the commits, the whole GPU rework might be >>>>> suspect, but I clearly have no clue. >>>> >>>> GPUs are tricky beasts :) >>> >>> Understatement ;). >>> >>>> ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the >>>> problem anyway since it only affects 6xx/7xx and your card is handled >>>> by the evergreen code. I'll put together some patches to help narrow >>>> down the problem. >>> >>> Yeah, that's the biggest problem I have, not knowing which functions are >>> actually being executed for this card. It looks like a combination of >>> stuff in evergreen.c and ni.c, but I have no idea. >>> >>> Patches would be great. If nothing else, I'm really good at building >>> kernels and rebooting by now. >> >> Two possible fixes attached. The first attempts a full reset of all >> blocks if the MC (memory controller) is hung. That may work better >> than just resetting the MC. The second just disables MC reset. I'm >> not sure we can reliably tell if it's busy due to display requests >> hitting the MC periodically which would lead to needlessly resetting >> it possibly leading to failures like you are seeing. > > OK. I'll test them individually. It will probably take a bit because > I'll want to do numerous reboots if things seem "fixed" with one or the > other. > > I'll let you know how things go. I applied each individually on top of Linus' tree as of this morning (commit 2a7d2b96d5) built, installed, and tested. 0001-drm-radeon-XXX-try-a-full-reset-if-the-MC-is-busy.patch failed in two reboots. 0001-drm-radeon-XXX-skip-MC-reset-as-it-s-probably-not-hu.patch has gone 21 reboots without a hang/rainbow static. You'll understand if I'm hesitant to declare success, but resetting the MC does indeed appear to be the issue. I'll keep rebooting for a while to make sure. josh ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-02-28 18:59 ` Josh Boyer @ 2013-03-05 15:21 ` Josh Boyer 2013-03-05 15:48 ` Alex Deucher 0 siblings, 1 reply; 33+ messages in thread From: Josh Boyer @ 2013-03-05 15:21 UTC (permalink / raw) To: Alex Deucher Cc: Dave Airlie, Alex Deucher, Jerome Glisse, torvalds, linux-kernel, DRI mailing list On Thu, Feb 28, 2013 at 1:59 PM, Josh Boyer <jwboyer@gmail.com> wrote: > On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer <jwboyer@gmail.com> wrote: >> On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher <alexdeucher@gmail.com> wrote: >>> On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer <jwboyer@gmail.com> wrote: >>>> On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher <alexdeucher@gmail.com> wrote: >>>>>>>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit >>>>>>>> >>>>>>>> So I don't think that's actually the cause of the problem. Or at least >>>>>>>> not that alone. I reverted it on top of Linus' latest tree and I still >>>>>>>> get the lockups. >>>>>>> >>>>>>> Actually, git bisect does seem to have gotten it correct. Once I >>>>>>> actually tested the revert of just that on top of Linus' tree (commit >>>>>>> d895cb1af1), things seem to be working much better. I've rebooted a >>>>>>> dozen times without a lockup. The most I've seen it take on a kernel >>>>>>> with that commit included is 3 reboots, so that's definitely at least an >>>>>>> improvement. >>>>>> >>>>>> I give up. GPU issues are not my thing. 2 reboots after I sent that it >>>>>> gave me pretty rainbow static again. So it might have been an >>>>>> improvement, but revert it is not a solution. >>>>>> >>>>>> Looking at there rest of the commits, the whole GPU rework might be >>>>>> suspect, but I clearly have no clue. >>>>> >>>>> GPUs are tricky beasts :) >>>> >>>> Understatement ;). >>>> >>>>> ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the >>>>> problem anyway since it only affects 6xx/7xx and your card is handled >>>>> by the evergreen code. I'll put together some patches to help narrow >>>>> down the problem. >>>> >>>> Yeah, that's the biggest problem I have, not knowing which functions are >>>> actually being executed for this card. It looks like a combination of >>>> stuff in evergreen.c and ni.c, but I have no idea. >>>> >>>> Patches would be great. If nothing else, I'm really good at building >>>> kernels and rebooting by now. >>> >>> Two possible fixes attached. The first attempts a full reset of all >>> blocks if the MC (memory controller) is hung. That may work better >>> than just resetting the MC. The second just disables MC reset. I'm >>> not sure we can reliably tell if it's busy due to display requests >>> hitting the MC periodically which would lead to needlessly resetting >>> it possibly leading to failures like you are seeing. >> >> OK. I'll test them individually. It will probably take a bit because >> I'll want to do numerous reboots if things seem "fixed" with one or the >> other. >> >> I'll let you know how things go. > > I applied each individually on top of Linus' tree as of this morning > (commit 2a7d2b96d5) built, installed, and tested. > > 0001-drm-radeon-XXX-try-a-full-reset-if-the-MC-is-busy.patch failed in > two reboots. > > 0001-drm-radeon-XXX-skip-MC-reset-as-it-s-probably-not-hu.patch has gone > 21 reboots without a hang/rainbow static. You'll understand if I'm > hesitant to declare success, but resetting the MC does indeed appear to > be the issue. I'll keep rebooting for a while to make sure. OK, I'm still running on the kernel with that patch and things still work. The only other "issue" I'm seeing at the moment is my dmesg is full of: [349316.595749] radeon 0000:01:00.0: MC busy: 0x00000409, clearing. [349436.654946] radeon 0000:01:00.0: MC busy: 0x00000409, clearing. [349436.655997] radeon 0000:01:00.0: MC busy: 0x00000409, clearing. [349496.698441] radeon 0000:01:00.0: MC busy: 0x00000409, clearing. [349556.726767] radeon 0000:01:00.0: MC busy: 0x00000409, clearing. [349556.727797] radeon 0000:01:00.0: MC busy: 0x00000409, clearing. So hopefully your patch is on the way into Linus' tree at some point soon. josh ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [git pull] drm merge for 3.9-rc1 2013-03-05 15:21 ` Josh Boyer @ 2013-03-05 15:48 ` Alex Deucher 0 siblings, 0 replies; 33+ messages in thread From: Alex Deucher @ 2013-03-05 15:48 UTC (permalink / raw) To: Josh Boyer Cc: Dave Airlie, Alex Deucher, Jerome Glisse, torvalds, linux-kernel, DRI mailing list On Tue, Mar 5, 2013 at 10:21 AM, Josh Boyer <jwboyer@gmail.com> wrote: > On Thu, Feb 28, 2013 at 1:59 PM, Josh Boyer <jwboyer@gmail.com> wrote: >> On Thu, Feb 28, 2013 at 10:15 AM, Josh Boyer <jwboyer@gmail.com> wrote: >>> On Thu, Feb 28, 2013 at 10:09 AM, Alex Deucher <alexdeucher@gmail.com> wrote: >>>> On Thu, Feb 28, 2013 at 8:44 AM, Josh Boyer <jwboyer@gmail.com> wrote: >>>>> On Thu, Feb 28, 2013 at 8:38 AM, Alex Deucher <alexdeucher@gmail.com> wrote: >>>>>>>>>> ca57802e521de54341efc8a56f70571f79ffac72 is the first bad commit >>>>>>>>> >>>>>>>>> So I don't think that's actually the cause of the problem. Or at least >>>>>>>>> not that alone. I reverted it on top of Linus' latest tree and I still >>>>>>>>> get the lockups. >>>>>>>> >>>>>>>> Actually, git bisect does seem to have gotten it correct. Once I >>>>>>>> actually tested the revert of just that on top of Linus' tree (commit >>>>>>>> d895cb1af1), things seem to be working much better. I've rebooted a >>>>>>>> dozen times without a lockup. The most I've seen it take on a kernel >>>>>>>> with that commit included is 3 reboots, so that's definitely at least an >>>>>>>> improvement. >>>>>>> >>>>>>> I give up. GPU issues are not my thing. 2 reboots after I sent that it >>>>>>> gave me pretty rainbow static again. So it might have been an >>>>>>> improvement, but revert it is not a solution. >>>>>>> >>>>>>> Looking at there rest of the commits, the whole GPU rework might be >>>>>>> suspect, but I clearly have no clue. >>>>>> >>>>>> GPUs are tricky beasts :) >>>>> >>>>> Understatement ;). >>>>> >>>>>> ca57802e521de54341efc8a56f70571f79ffac72 mostly likely wasn't the >>>>>> problem anyway since it only affects 6xx/7xx and your card is handled >>>>>> by the evergreen code. I'll put together some patches to help narrow >>>>>> down the problem. >>>>> >>>>> Yeah, that's the biggest problem I have, not knowing which functions are >>>>> actually being executed for this card. It looks like a combination of >>>>> stuff in evergreen.c and ni.c, but I have no idea. >>>>> >>>>> Patches would be great. If nothing else, I'm really good at building >>>>> kernels and rebooting by now. >>>> >>>> Two possible fixes attached. The first attempts a full reset of all >>>> blocks if the MC (memory controller) is hung. That may work better >>>> than just resetting the MC. The second just disables MC reset. I'm >>>> not sure we can reliably tell if it's busy due to display requests >>>> hitting the MC periodically which would lead to needlessly resetting >>>> it possibly leading to failures like you are seeing. >>> >>> OK. I'll test them individually. It will probably take a bit because >>> I'll want to do numerous reboots if things seem "fixed" with one or the >>> other. >>> >>> I'll let you know how things go. >> >> I applied each individually on top of Linus' tree as of this morning >> (commit 2a7d2b96d5) built, installed, and tested. >> >> 0001-drm-radeon-XXX-try-a-full-reset-if-the-MC-is-busy.patch failed in >> two reboots. >> >> 0001-drm-radeon-XXX-skip-MC-reset-as-it-s-probably-not-hu.patch has gone >> 21 reboots without a hang/rainbow static. You'll understand if I'm >> hesitant to declare success, but resetting the MC does indeed appear to >> be the issue. I'll keep rebooting for a while to make sure. > > OK, I'm still running on the kernel with that patch and things still > work. The only other "issue" I'm seeing at the moment is my dmesg is > full of: > > [349316.595749] radeon 0000:01:00.0: MC busy: 0x00000409, clearing. > [349436.654946] radeon 0000:01:00.0: MC busy: 0x00000409, clearing. > [349436.655997] radeon 0000:01:00.0: MC busy: 0x00000409, clearing. > [349496.698441] radeon 0000:01:00.0: MC busy: 0x00000409, clearing. > [349556.726767] radeon 0000:01:00.0: MC busy: 0x00000409, clearing. > [349556.727797] radeon 0000:01:00.0: MC busy: 0x00000409, clearing. > I'll make those debug only when the patch goes upstream. > So hopefully your patch is on the way into Linus' tree at some point > soon. It'll be in my next -fixes pull. Alex ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2013-03-05 19:16 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-02-27 22:36 [git pull] drm merge for 3.9-rc1 Sedat Dilek 2013-02-27 23:06 ` Sedat Dilek 2013-02-28 11:18 ` Chris Wilson 2013-02-28 14:31 ` [Intel-gfx] " Paulo Zanoni 2013-02-28 17:12 ` Sedat Dilek 2013-02-28 17:29 ` Sedat Dilek 2013-02-28 17:33 ` Paulo Zanoni 2013-02-28 17:59 ` Sedat Dilek 2013-03-01 16:30 ` Sedat Dilek 2013-03-05 18:28 ` Imre Deak 2013-02-28 17:07 ` Sedat Dilek -- strict thread matches above, loose matches on Subject: below -- 2013-02-26 0:05 Dave Airlie 2013-02-26 1:22 ` Linus Torvalds 2013-02-26 1:59 ` Dave Airlie 2013-02-27 1:39 ` Linus Torvalds 2013-02-27 2:25 ` Linus Torvalds 2013-02-27 3:30 ` Dave Airlie 2013-02-27 3:38 ` Linus Torvalds 2013-02-27 10:04 ` Chris Wilson 2013-03-03 15:39 ` Azat Khuzhin 2013-03-05 19:18 ` Daniel Vetter 2013-02-27 16:34 ` Josh Boyer 2013-02-27 20:20 ` Josh Boyer 2013-02-27 20:24 ` Josh Boyer 2013-02-28 0:01 ` Josh Boyer 2013-02-28 1:14 ` Josh Boyer 2013-02-28 13:38 ` Alex Deucher 2013-02-28 13:44 ` Josh Boyer 2013-02-28 15:09 ` Alex Deucher 2013-02-28 15:15 ` Josh Boyer 2013-02-28 18:59 ` Josh Boyer 2013-03-05 15:21 ` Josh Boyer 2013-03-05 15:48 ` Alex Deucher
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).