Re: Questions on display pipes on 835GM

[Thomas Richter <thor@math.tu-berlin.de>]

Hi Ville, hi Daniel,

>> Thus, here my questions:
>> *) Can I, within the dvo driver code, somehow detect to which display
>> pipe the DVO and thus the TFT is actually connected
>> to?
>
> Something like this:
> intel_dvo = container_of(dvo,  struct intel_dvo, dev);
> pipe = to_intel_ctrc(intel_dvo.base.base.crtc)->pipe
>
> But currectly it looks like struct intel_dvo isn't visible
> outside intel_dvo.c which would need changing, or the hacks
> need to be moved into intel_dvoc.

What I currently did is that I'm assuming that the intel_encoder struct 
is right in front of the dvo structure, and thus I can get the pipe this 
way. Yuck!

However, while I get the proper pipe back, apparently there is a 
discrepancy of what the i915 believes the DVO is attached to, and which 
pipe it is actually attached to. That is, if I boot up without an 
external monitor, everything is fine and my pipe code returns pipe 0, 
and "unlocks" the DVO correctly. If an external monitor is connected, 
the DVO locks up again during bootstrap.

>> *) Can I somehow prohibit that the DVO is driven by *anything but* the
>> 60Hz signal it likes, thus to prevent the lock-up
>> and disable the weird hack I'm currently using?
>
> I think currently it should be driven at the correct rate or not at all.

True enough, but how to ensure this?

> The CRT port can only be driven by pipe A, so I think that explains why
> your hacks may go bad when a CRT monitor is used.

Understood, this makes sense. Thus, DVO would then be at pipe B. How is 
this switch made, and where? There need to be a register somewhere that 
tells the i835 which signal goes where.

> I see several problems with the ns2501 code.
> - it assumes DVOC. While that may be true always, getting the correct
>    register from .dvo_reg is trivial

This is actually no longer required. I experimented a bit with it and 
all that is necessary to keep the DVO active is the proper timing in the 
PLL register, either A or B, whatever the DVO is attached to.

> - assumes pipe A, which as stated isn't always true. During modesetting
>    operations you can get the correct crtc via intel_dvo.base.base.crtc,
>    from which you can get the pipe.

True enough, but this information does not seem to be up to date, or 
seems to be incorrect if an external monitor is attached. If I'm 
resetting pipes A and B, then I don't see a problem and my little hack 
can activate the DVO just fine. However, some part of the i915 driver 
seem to have loaded an incorrect value into the pipe B PLL, then again 
creating a lock-up on the internal display.

It seems to me that if "mirroring" is enabled, both displays seem to be 
driven by the same PLL, hence by the same frequency, hence locking up 
the display. The DVO is awakened by the hack if required, but the TFT is 
dead anyhow.

> - the hack doesn't set up all the DPLL registers, but I suppose we
>    could try to eliminate the hack. One thing that would need maybe
>    fixing is the get_hw_state function. We could perhaps just change
>    intel_dvo.c not to call the connector get_hw_state func if the
>    encoder says the dvo port isn't active.

Not necessary, actually. If the PLL registers are set correctly, the DVO 
is operational.

Concerning the get_hw_state(), I also added the hack here to re-enable 
the DVO if it's stuck, but it doesn't make a difference.

Greetings,
	Thomas