[Intel-gfx] [PATCH] drm/i915: Init important ns2501 registers
From: Ville Syrjälä 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ä --- 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
Am 09.06.2014 21:46, schrieb ville.syrj...@linux.intel.com: From: Ville Syrjälä 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
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·Ø¿dy·) 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, m
Re: [Intel-gfx] [PATCH] drm/i915: Init important ns2501 registers
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
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