Re: [Intel-gfx] [PATCH] drm/i915: Init important ns2501 registers

2014-06-10 Thread Ville Syrjälä
On Tue, Jun 10, 2014 at 12:29:20AM +0200, Thomas Richter wrote:
 Hi Ville,
 
 thanks for the latest patch. As said, the screen did not come back quite 
 correctly. I checked the register values
 again, and I am sorry to say that I was wrong - register values do 
 differ. Apparently, the code configures now
 the wrong pipe to generate output to the DVO and thus the DVO does not 
 seem to synchronize correctly
 anymore. Please find the two register dumps attached.

Either pipe can drive DVO just fine. Looks like it's using pipe A in
your register dump, and all the registers look fine to me. Well, DPLL B
VCO enable is off since we don't currently have a mechanism to kick pipe
B into action during resume/load. In theory that would need to be enabled
as well.

Can you see if a simple 'intel_reg_write 0x6018 0xc08b' fixes the
problem?

And if not, I'd like to see a diff of register dumps between working and
non working setups.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Init important ns2501 registers

2014-06-10 Thread Thomas Richter

Hi Ville,


Either pipe can drive DVO just fine. Looks like it's using pipe A in
your register dump, and all the registers look fine to me. Well, DPLL B
VCO enable is off since we don't currently have a mechanism to kick pipe
B into action during resume/load. In theory that would need to be enabled
as well.

Can you see if a simple 'intel_reg_write 0x6018 0xc08b' fixes the
problem?


Nope. I created a little script that wrote the previous data back into 
the chipset, but that did not cure the problem. The only register I 
could not write to was CACHEMODE (IIRC, this was the name intel_reg_dump 
gave). The plane pointers and cursor pointers were different, too, but 
that should not be critical.



And if not, I'd like to see a diff of register dumps between working and
non working setups.


I afraid the S6010 is out of reach for the next three weeks, but I 
should have a complete register dump attached to my previous mail from 
yesterday night (or this morning, to be precise).


I can now try on the R31, but I don't remember having seen anything like 
it there. It does *not* look like the flickering of the misaligned 
watermark registers - on the console it really looks like bad HSYNC on a 
TV (tearing across horizontal lines, and massive misalignments of the 
very first lines of the screen). Within X, it causes the screen to jump 
to the right by about 64(?)128(?) pixels. The problem does not disappear 
by using a different resolution or restarting X. It remains permanent 
until the next boot.


Greetings,
Thomas



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: Init important ns2501 registers

2014-06-09 Thread ville . syrjala
From: Ville Syrjälä ville.syrj...@linux.intel.com

In my earlier rewrite I missed a few important registers. Thomas Richter
noticed that they're needed to make his machine resume correctly.

Looks like IEGD does a one time init of these three registers. We don't
have a good one time init place in the ns2501 driver, so let's just
stick them into the .mode_set() hook and see if that helps things along.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/dvo_ns2501.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c 
b/drivers/gpu/drm/i915/dvo_ns2501.c
index 64103cb..4416304 100644
--- a/drivers/gpu/drm/i915/dvo_ns2501.c
+++ b/drivers/gpu/drm/i915/dvo_ns2501.c
@@ -342,6 +342,12 @@ static const struct ns2501_reg regs_1024x768[][86] = {
},
 };
 
+static const struct ns2501_reg regs_init[] = {
+   [0] = { .offset = 0x35, .value = 0xff, },
+   [1] = { .offset = 0x34, .value = 0x00, },
+   [2] = { .offset = 0x08, .value = 0x30, },
+};
+
 struct ns2501_priv {
bool quiet;
const struct ns2501_reg *regs;
@@ -544,6 +550,10 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,
else
return;
 
+   /* Hopefully doing it every time won't hurt... */
+   for (i = 0; i  ARRAY_SIZE(regs_init); i++)
+   ns2501_writeb(dvo, regs_init[i].offset, regs_init[i].value);
+
ns-regs = regs_1024x768[mode_idx];
 
for (i = 0; i  84; i++)
-- 
1.8.5.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Init important ns2501 registers

2014-06-09 Thread Thomas Richter

Am 09.06.2014 21:46, schrieb ville.syrj...@linux.intel.com:

From: Ville Syrjäläville.syrj...@linux.intel.com

In my earlier rewrite I missed a few important registers. Thomas Richter
noticed that they're needed to make his machine resume correctly.
Thanks, this *almost* works, much better than before. Now I only need to 
switch the console
forth and back to get a display. However, I get a pretty unstable 
display on the console, and
a *sometimes* unstable display on the X display. From the way it looks, 
I would guess that
the synchronization between the display and the PLL is not quite right. 
Which is stunning since

the 830M seems to be configured correctly.

Greetings,
Thomas

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Init important ns2501 registers

2014-06-09 Thread Thomas Richter

Hi Ville,

thanks for the latest patch. As said, the screen did not come back quite 
correctly. I checked the register values
again, and I am sorry to say that I was wrong - register values do 
differ. Apparently, the code configures now
the wrong pipe to generate output to the DVO and thus the DVO does not 
seem to synchronize correctly

anymore. Please find the two register dumps attached.

Greetings,
Thomas





reg.org
Description: Binary data
 DCC: 0x (`7v·ô‚ƒ¿bFx·ä‚ƒ¿ô‡r·Ø‚ƒ¿dŠy·)
   CHDECMISC: 0x (none, ch2 enh disabled, ch1 enh disabled, ch0 
enh disabled, flex disabled, ep not present)
  C0DRB0: 0x (0x)
  C0DRB1: 0x (0x)
  C0DRB2: 0x (0x)
  C0DRB3: 0x (0x)
  C1DRB0: 0x (0x)
  C1DRB1: 0x (0x)
  C1DRB2: 0x (0x)
  C1DRB3: 0x (0x)
 C0DRA01: 0x (0x)
 C0DRA23: 0x (0x)
 C1DRA01: 0x (0x)
 C1DRA23: 0x (0x)
  PGETBL_CTL: 0x3ff60001
   VCLK_DIVISOR_VGA0: 0x00021207 (n = 2, m1 = 18, m2 = 7)
   VCLK_DIVISOR_VGA1: 0x00031406 (n = 3, m1 = 20, m2 = 6)
   VCLK_POST_DIV: 0x888b (vga0 p1 = 13, p2 = 4, vga1 p1 = 10, p2 = 4)
   DPLL_TEST: 0x (, DPLLA input buffer disabled, DPLLB input 
buffer disabled)
CACHE_MODE_0: 0x001f
 D_STATE: 0x
   DSPCLK_GATE_D: 0x0008 (clock gates disabled: OVRUNIT)
  RENCLK_GATE_D1: 0x
  RENCLK_GATE_D2: 0x
   SDVOB: 0x90004084 (enabled, pipe A, stall disabled, detected)
   SDVOC: 0x (disabled, pipe A, stall disabled, not 
detected)
 SDVOUDI: 0x
  DSPARB: 0x00017e5f
  DSPFW1: 0x
  DSPFW2: 0x
  DSPFW3: 0x
ADPA: 0x0c00 (disabled, pipe A, -hsync, -vsync)
LVDS: 0x (disabled, pipe A, 18 bit, 1 channel)
DVOA: 0x (disabled, pipe A, no stall, -hsync, -vsync)
DVOB: 0x90004084 (enabled, pipe A, stall, -hsync, -vsync)
DVOC: 0x (disabled, pipe A, no stall, -hsync, -vsync)
 DVOA_SRCDIM: 0x
 DVOB_SRCDIM: 0x
 DVOC_SRCDIM: 0x
  PP_CONTROL: 0x (power target: off)
   PP_STATUS: 0x (off, not ready, sequencing idle)
PP_ON_DELAYS: 0x
   PP_OFF_DELAYS: 0x
  PP_DIVISOR: 0x
PFIT_CONTROL: 0x
 PFIT_PGM_RATIOS: 0x
 PORT_HOTPLUG_EN: 0x
   PORT_HOTPLUG_STAT: 0x
DSPACNTR: 0xd800 (enabled, pipe A)
  DSPASTRIDE: 0x2000 (8192 bytes)
 DSPAPOS: 0x (0, 0)
DSPASIZE: 0x02ff03ff (1024, 768)
DSPABASE: 0x0200
DSPASURF: 0x
 DSPATILEOFF: 0x
   PIPEACONF: 0x8000 (enabled, single-wide)
PIPEASRC: 0x03ff02ff (1024, 768)
   PIPEASTAT: 0x1207 (status: CRC_DONE_ENABLE VSYNC_INT_STATUS 
SVBLANK_INT_STATUS VBLANK_INT_STATUS OREG_UPDATE_STATUS)
   PIPEA_GMCH_DATA_M: 0x
   PIPEA_GMCH_DATA_N: 0x
 PIPEA_DP_LINK_M: 0x
 PIPEA_DP_LINK_N: 0x
   CURSOR_A_BASE: 0x3524c000
CURSOR_A_CONTROL: 0x0427
   CURSOR_A_POSITION: 0x00d50133
FPA0: 0x0004150d (n = 4, m1 = 21, m2 = 13)
FPA1: 0x0004150d (n = 4, m1 = 21, m2 = 13)
  DPLL_A: 0xd082 (enabled, dvo, default clock, DAC/serial mode, 
p1 = 4, p2 = 4)
   DPLL_A_MD: 0x
HTOTAL_A: 0x053f03ff (1024 active, 1344 total)
HBLANK_A: 0x053f03ff (1024 start, 1344 end)
 HSYNC_A: 0x049f0417 (1048 start, 1184 end)
VTOTAL_A: 0x032502ff (768 active, 806 total)
VBLANK_A: 0x032502ff (768 start, 806 end)
 VSYNC_A: 0x03080302 (771 start, 777 end)
   BCLRPAT_A: 0x
VSYNCSHIFT_A: 0x
DSPBCNTR: 0x (disabled, pipe A)
  DSPBSTRIDE: 0x (0 bytes)
 DSPBPOS: 0x (0, 0)
DSPBSIZE: 0x (1, 1)
DSPBBASE: 0x
DSPBSURF: 0x
 DSPBTILEOFF: 0x
   PIPEBCONF: 0x (disabled, single-wide)
PIPEBSRC: 0x (1, 1)
   PIPEBSTAT: 0x1004 (status: CRC_DONE_ENABLE SVBLANK_INT_STATUS)
   PIPEB_GMCH_DATA_M: 0x
   PIPEB_GMCH_DATA_N: 0x
 PIPEB_DP_LINK_M: 0x
 PIPEB_DP_LINK_N: 0x
   CURSOR_B_BASE: 0x
CURSOR_B_CONTROL: 0x
   CURSOR_B_POSITION: 0x
FPB0: 0x00021207 (n = 2, m1 = 18, m2 = 7)
FPB1: 0x00021207 (n = 2, m1 = 18,