| Message ID | CAPX-8+8X_qeMLpgD894t=ha+QvsYJ+NKbLBEVnx97=hFajPWtw@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Aug 22, 2012 at 08:13:37PM +0100, Lespiau, Damien wrote: > On Wed, Aug 22, 2012 at 12:03 PM, Lespiau, Damien > <damien.lespiau@intel.com> wrote: > > On Wed, Aug 22, 2012 at 11:46 AM, Lespiau, Damien > > <damien.lespiau@intel.com> wrote: > >> On Tue, Aug 21, 2012 at 7:11 PM, Daniel Vetter <daniel@ffwll.ch> wrote: > >>>> Smoke-tested the new modeset-rework branch and found a regression on > >>>> my IVB with a pristine f17 userland: > >>>> > >>>> * start with LVDS + VGA > >>>> * unplug VGA > >>>> * LVDS goes black > >>> > >>> Hm, not yet seen this one here. Can you attach a full dmesg with > >>> drm.debug=0xe when this is happening, please? > > Adding more information to track this regression, a diff between the > failure state and bringing back the panel with a off/on cycle (note > the disabled DPLL). Please test the for-damien branch in my personal fdo git repo. I'm rather positive that the patch there should fix this (but in the least it should unearth the real culprit). -Daniel > > $ diff -u vga-out-lvds-fail.dump vga-out-lvds-off-on.dump > --- vga-out-lvds-fail.dump 2012-08-22 14:05:44.732293487 +0100 > +++ vga-out-lvds-off-on.dump 2012-08-22 14:06:21.690275915 +0100 > @@ -28,10 +28,10 @@ > PIPEA_LINK_N1: 0x00041eb0 (val 0x41eb0 270000) > PIPEA_LINK_M2: 0x00000000 (val 0x0 0) > PIPEA_LINK_N2: 0x00000000 (val 0x0 0) > - DSPACNTR: 0x58004400 (disabled) > + DSPACNTR: 0xd8004400 (enabled) > DSPABASE: 0x00000000 > DSPASTRIDE: 0x00001600 (88) > - DSPASURF: 0x041c6008 > + DSPASURF: 0x0155c008 > DSPATILEOFF: 0x00000000 (0, 0) > PIPEBCONF: 0x00000000 (disabled, inactive, > pf-pd, rotate 0, 8bpc) > HTOTAL_B: 0x0897077f (1920 active, 2200 total) > @@ -102,7 +102,7 @@ > 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: 0x08046004 (disable, sdvo high speed > no, mode LVDS, p2 Div 14, FPA0 P1 3, FPA1 P1 3, refclk SSC, sdvo/hdmi > mul 1) > + 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: 0x04020002 (disable, sdvo high speed > no, mode (null), p2 (null), FPA0 P1 2, FPA1 P1 2, refclk default > 120Mhz, sdvo/hdmi mul 1) > PCH_FPA0: 0x00021108 (n = 2, m1 = 17, m2 = 8) > PCH_FPA1: 0x00021108 (n = 2, m1 = 17, m2 = 8)
On Wed, Aug 22, 2012 at 10:21 PM, Daniel Vetter <daniel@ffwll.ch> wrote: > Please test the for-damien branch in my personal fdo git repo. I'm rather > positive that the patch there should fix this (but in the least it should > unearth the real culprit). The branch works, but so does HEAD^ on that branch. After cherry-picking the PLL commit on top of the modeset-rework branch, plugging out the VGA cable still turns off the PLL for LVDS, but now triggers the newly introduced asserts see: http://damien.lespiau.name/files/temp/vga+lvds-unplug-vga-lvds-fail-full-2.dmesg.bz2 I can have a look myself as well, but probably not before Tuesday.
On Thu, Aug 23, 2012 at 01:26:39PM +0100, Lespiau, Damien wrote: > On Wed, Aug 22, 2012 at 10:21 PM, Daniel Vetter <daniel@ffwll.ch> wrote: > > Please test the for-damien branch in my personal fdo git repo. I'm rather > > positive that the patch there should fix this (but in the least it should > > unearth the real culprit). > > The branch works, but so does HEAD^ on that branch. > > After cherry-picking the PLL commit on top of the modeset-rework > branch, plugging out the VGA cable still turns off the PLL for LVDS, > but now triggers the newly introduced asserts see: > http://damien.lespiau.name/files/temp/vga+lvds-unplug-vga-lvds-fail-full-2.dmesg.bz2 Yeah, the pll changes are just something I've noticed that looks strange, the real fix is tip. And that one is a real change wrt what the crtc helper does, so I need to think about it some more. > I can have a look myself as well, but probably not before Tuesday. Hm, if you have that dmesg from the branch I've pushed, we hit the WARN for the case where we grab a fresh pch pll, but somehow think it's still on. I have a feeling there's something fishy going on. But like I've said before, the pll stuff is simply something I've noticed while reading through your dmesg. Thanks for testing, Daniel
On Thu, Aug 23, 2012 at 11:39 PM, Daniel Vetter <daniel@ffwll.ch> wrote: > On Thu, Aug 23, 2012 at 01:26:39PM +0100, Lespiau, Damien wrote: >> On Wed, Aug 22, 2012 at 10:21 PM, Daniel Vetter <daniel@ffwll.ch> wrote: >> > Please test the for-damien branch in my personal fdo git repo. I'm rather >> > positive that the patch there should fix this (but in the least it should >> > unearth the real culprit). After a bit of back and forth and the updated 50/58 patch, does not regress any more here with the testing done on an IVB system. Tested-by: Damien Lespiau <damien.lespiau@intel.com>
I forgot to say that I tested tv out here on 945GME Express and 82945G/GZ and it worked fine as well. No regression. On Wed, Aug 29, 2012 at 9:26 AM, Lespiau, Damien <damien.lespiau@intel.com> wrote: > On Thu, Aug 23, 2012 at 11:39 PM, Daniel Vetter <daniel@ffwll.ch> wrote: >> On Thu, Aug 23, 2012 at 01:26:39PM +0100, Lespiau, Damien wrote: >>> On Wed, Aug 22, 2012 at 10:21 PM, Daniel Vetter <daniel@ffwll.ch> wrote: >>> > Please test the for-damien branch in my personal fdo git repo. I'm rather >>> > positive that the patch there should fix this (but in the least it should >>> > unearth the real culprit). > > After a bit of back and forth and the updated 50/58 patch, does not > regress any more here with the testing done on an IVB system. > > Tested-by: Damien Lespiau <damien.lespiau@intel.com> > > -- > Damien > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--- vga-out-lvds-fail.dump 2012-08-22 14:05:44.732293487 +0100 +++ vga-out-lvds-off-on.dump 2012-08-22 14:06:21.690275915 +0100 @@ -28,10 +28,10 @@ PIPEA_LINK_N1: 0x00041eb0 (val 0x41eb0 270000) PIPEA_LINK_M2: 0x00000000 (val 0x0 0) PIPEA_LINK_N2: 0x00000000 (val 0x0 0) - DSPACNTR: 0x58004400 (disabled) + DSPACNTR: 0xd8004400 (enabled) DSPABASE: 0x00000000 DSPASTRIDE: 0x00001600 (88) - DSPASURF: 0x041c6008 + DSPASURF: 0x0155c008 DSPATILEOFF: 0x00000000 (0, 0) PIPEBCONF: 0x00000000 (disabled, inactive, pf-pd, rotate 0, 8bpc)