From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Richter Subject: Re: More questions and patches for 835GM/ns2501 DVO Date: Mon, 04 Nov 2013 00:09:46 +0100 Message-ID: <5276D7BA.4090401@math.tu-berlin.de> References: <52768009.7070905@math.tu-berlin.de> <20131103171208.GA4167@phenom.ffwll.local> <19544_1383498802_52768431_19544_2610_1_20131103171348.GB4167@phenom.ffwll.local> <52769D39.5070501@math.tu-berlin.de> <19544_1383513468_5276BD7B_19544_3653_1_20131103211814.GC4167@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from charybdis.rus.uni-stuttgart.de (charybdis.rus.uni-stuttgart.de [129.69.192.2]) by gabe.freedesktop.org (Postfix) with ESMTP id 9C1F6F09E3 for ; Sun, 3 Nov 2013 15:09:52 -0800 (PST) In-Reply-To: <19544_1383513468_5276BD7B_19544_3653_1_20131103211814.GC4167@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Daniel Vetter Cc: intel-gfx List-Id: intel-gfx@lists.freedesktop.org On 03.11.2013 22:18, Daniel Vetter wrote: > > Hm, that would mean that the cursor is somehow stuck in the enabled state, > despite that we've tried to disabled it very hard. Can you please try out > the below patch? If this doesn't work please take not of the different > WARNINGs you're hitting and whether it's always the same one with the same > calltrace or something different. > > I think for now we should try to get the single monitor case working - I > have a few theories for the dual-screen issues, but there's not much point > working on them if the simple case doesn't work yet. > > Also I think I'll merge the two patches if they don't make things worse > for you, imo it's the right approach and at least conceptually should be > able to avoid all these retry loops. Thanks for the patches. Tried quite a bit, and haven't seen the warning yet. Looks like the one-monitor case works quite fine now, except that the boot console is vertically "off", which is just annoying though not problematic. I also tried a lot with the two-monitor case and again went deeply into the DPLL setup logic. The differences I observed before are simply due to the initial resolution (800x600), in the final resolution, the DPLL settings are actually correct. What I get there is: --- Configuration found for regular display 1024x768: Nov 3 23:33:30 tyleet kernel: [ 9.122481] [drm:i9xx_find_best_dpll], clock.m1 = 21 Nov 3 23:33:30 tyleet kernel: [ 9.122483] [drm:i9xx_find_best_dpll], clock.m2 = 13 Nov 3 23:33:30 tyleet kernel: [ 9.122485] [drm:i9xx_find_best_dpll], clock.n = 4 Nov 3 23:33:30 tyleet kernel: [ 9.122488] [drm:i9xx_find_best_dpll], clock.p1 = 4 for 800x600: Nov 3 23:38:41 tyleet kernel: [ 368.725507] [drm:i9xx_find_best_dpll], clock.m1 = 19 Nov 3 23:38:41 tyleet kernel: [ 368.725514] [drm:i9xx_find_best_dpll], clock.m2 = 13 Nov 3 23:38:41 tyleet kernel: [ 368.725521] [drm:i9xx_find_best_dpll], clock.n = 4 Nov 3 23:38:41 tyleet kernel: [ 368.725528] [drm:i9xx_find_best_dpll], clock.p1 = 6 640 x 480: Nov 3 23:40:05 tyleet kernel: [ 452.965855] [drm:i9xx_find_best_dpll], clock.m1 = 20 Nov 3 23:40:05 tyleet kernel: [ 452.965862] [drm:i9xx_find_best_dpll], clock.m2 = 14 Nov 3 23:40:05 tyleet kernel: [ 452.965869] [drm:i9xx_find_best_dpll], clock.n = 3 Nov 3 23:40:05 tyleet kernel: [ 452.965876] [drm:i9xx_find_best_dpll], clock.p1 = 12 And even in the two-monitor case, the DPLL for DPLL_B is setup correctly. Thus, *that* does not seem the cause of the problem. What is different is the DVO setting: bit differences: In the two-monitor case, the internal DVOC register is 0xd000409c, in the one-monitor case it is: 0x90004084 Differences are: DVO bit 30 should be 0 is 1. DVO_PIPE_B_SELECT enabled DVO bit 4 should be 0 is 1. DVO_VSYNC_ACTIVE_HIGH DVO bit 3 should be 0 is 1. DVO_HSYNC_ACTIVE_HIGH Now, the bit 30 is clear, though I wonder why the sync signal is inverted. Anyhow, something else makes we wonder. The DVO-reactivation code *does* work (the DVO-settings do not block, though the DVO blocks afterwards), and the code is just: I915_WRITE(_DPLL_A, 0xd0820000); I915_WRITE(_DPLL_B, 0xd0820000); Thus, while the DPLL_B register is just overwritten by the same value, though DPLL_A changes. The fact that this actually unlocks the DVO means to me that actually bit 30 of the DVOC register *does not* work to re-assign the DVO to pipe B. The way how the system behaves is rather consistent with the hypothesis that the DVO is still assigned to pipe A???? Is there any other bit or setting that controls which DVO goes to which pipe? It looks like the pipe output control does not work correctly. Greetings, Thomas