This builds upon my previous attempts to resolve some jitter problems seen
with the Matrox G450 and G550 -based cards, including odd disparities observed
between x86 and Power -based machines in a somewhat less hackish way (removing
the hacked ifdefs).
Apparently, preference should be given to use the DVI PLL when frequencies
permit, the Standard PLL otherwise. The max pixel clock for the panellink
interface is extracted from the PInS information on the card and used as a
limit to determine which PLL to use.
Signed-off-by: Paul A. Clarke <pc@us.ibm.com>
Acked-by: Petr Vandrovec <petr@vandrovec.name>
Signed-off-by: Antonino Daplas <adaplas@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I wish I was happier about this patch. It'll serve as a placeholder for
the moment. I'm still trying to get a G550 working in order to even
reproduce the problem this patch introduces. I find that the G450 has
jitter even without this patch, so it won't show me what the patch changed.
At this point, I'll continue trying to get the G550 to work, and in
parallel work with the G450 to work out the kinks.
The patch is below.
Set XDVICLKCTRL only on PPC, as doing this apparently introduces jitter on
the G550, at least on x86 architectures.
Signed-off-by: Paul A. Clarke <pc@us.ibm.com>
Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
There has been a longstanding problem with the Matrox G450 and perhaps
other similar cards, with modes "above" 1280x1024-60 on ppc/ppc64 boxes
running Linux. Higher resolutions and/or higher refresh rates resulted in
a very noticably "jittery" display, and sometimes no display, depending on
the physical monitor. This patch fixes that problem on the systems I have
easy access to...
I've tested with SLES9SP3 (2.6.5+ kernel) and 2.6.16-rc6 custom kernels on
an IBM eServer p5 520 w/G450 (a.k.a GXT135P on IBM's ppc64 systems), and a
colleague of mine (Ian Romanick) tested it successfully on an Apple ppc32
box (w/GXT135P). I also tested it on IA32 box I have with a GXT135P to
verify that it didn't obviously break anything. In my testing, I covered
single-card, single and dual-head setups using both HD15 and DVI-D signals,
on both the IA32 and ppc64 boxes. While everything appeared fine on both
boxes, I did encounter one problem: I can't get any signal on the DVI-D
output on the ppc64 box. However, this is also the case without my patch.
I just noticed that screen-blanking only occurs on the primary display as
well.
Signed-off-by: Paul A. Clarke <pc@us.ibm.com>
Signed-off-by: Ian Romanick <idr@us.ibm.com>
Signed-off-by: Petr Vandrovec <petr@vandrovec.name>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Paul A. Clarke