Re: More questions and patches for 835GM/ns2501 DVO

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 04, 2013 at 12:57:20PM +0100, Thomas Richter wrote:
> Hi Daniel,
> >>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:
> >I suspect that due to the pipe A quirk logic we actually get the setup
> >sequence for the DPLLs completely wrong. This will require a bit more
> >magic to make it work correctly ... But I have some ideas.
> >-Daniel
> Well,  maybe. The register contents that are listed in my mail are
> read out from the hardware exactly when the
> DVO gets stuck, actually right before it. From what I can see from
> there is that the PLL setup and DVO setup
> look actually ok (from what I can tell). What is also remarkable is
> that the DVO-reenable logic does succeed by
> writing the same value to the DPLL_A and DPLL_B registers, which is
> the proper value for a 1024x768 screen. However,
> the DPLL_B register value is correct, whereas the DPLL_A register
> contains values that are likely useful for the VGA
> output.
> 
> Now, here is the miracle: The DVOC register indicates that the DVO
> gets its input from pipe B. However, writing the
> correct value into DPLL_A (!) (remember, DPLL_B is already set
> correctly) revives the DVO.
> 
> Thus, I wonder how this can be. The only explanation I have is that
> the DVO is still fed by pipe A, and not by pipe B.
> Maybe there is something else that needs to be done to switch the
> DVO to pipe B.

That's actually my suspicion. Most of these registers here are
double-buffered and only take effect if preconditions are right. Due to
our pipe A quirk we never shut down pipe A, so the pll updates might not
actually take effect at all (but the registers have the new values
already). There's unfortunately no registers to get at the actual hw
state, and only later hw generations have added at least a few bits to
indicate whether the large transitions (on/off) have actually happened.

The problem is that I don't yet have a clear idea how to do the pipe A
quirk correctly :(
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux