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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
