Re: machfb (sort of) working on Mach64 GX

[Michael <macallan%netbsd.org@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Apr 28, 2011, at 3:32 PM, David Riley wrote:

> I'm combining replies to two of yours here, apologies.
>
>
> On Apr 28, 2011, at 3:24 PM, Michael wrote:
>
> > It shouldn't do anything on a Rage II or Pro. The problem with the  
> > GX and similar old mach64 chips is that they have only one BAR -  
> > the aperture, which contains both VRAM and registers. Until now  
> > machfb depends on mapping the registers through one of the  
> > additional BARs found in newer chips ( which contain only registers  
> > and the last few generations have them both IO and memory mapped ).  
> > All the patch does is to make machfb attach with those old chip,  
> > use the registers in the aperture instead of depending on the  
> > additional BARs and give the correct memory type for older mach64.  
> > Both the Rage II and the Pro have at least one additional BAR so  
> > they should do exactly what they did before.
>
> Actually, interestingly enough, that wasn't a problem.  The machfb  
> code was already using the linear aperture register access mode.   
> What was a problem, however, is that a) the PCI product ids for the  
> GX/CX cards weren't in the list, and b) their internal chip ID  
> register has a chip ID that doesn't match the PCI product ID  
> (presumably because they were very early chips developed during the  
> ISA/PCI transition).

It does fix up the sc_regs pointer though ;)
Either way, the Xorg driver also has trouble with these chips.

> > > The other possibility is (as mentioned) the CRT handling being  
> > > buggy, since the iMac had some interesting restrictions on modes.   
> > > I wish my parents' old Rev B iMac was still alive and well...  
> > > maybe they still have it.  I'll check.
> >
> > There is one way to find out if the mode setting code is the  
> > culprit ( it probably is ).
> > In mach4_attach() look for this:
> > if (setmode)
> >         mach64_modeswitch(sc, sc->sc_my_mode);
> >
> > and comment it out.
> > The idea was to use the monitor's EDID data to pick a better mode  
> > than OpenFirmware does ( as in, higher refresh rate if the monitor  
> > allows it since OF is rather restrictive in which modes it  
> > allows ), which may or my not work correctly on an iMac's built-in  
> > screen.
>
> I'd say that's a good guess.

I hope so, since that would be easy to fix.

> > So, someone with an iMac please try the above, build a kernel with  
> > options MACHFB_DEBUG and send me the kernel output ( it should  
> > contain a dump of the monitor's EDID block ). With that I should be  
> > able to tell wether the logic that picks a video mode is faulty  
> > ( it probably is, since the iMac's CRTs require a fixed horizontal  
> > frequency which is rather unusual ).
>
> DIAGNOSTIC is another useful define which dumps more registers than  
> MACHFB_DEBUG.  I'd define it straight in the .c file, though, so you  
> don't get flooded with diagnostics from other drivers which also  
> catch that one.

Well, I only wanted the EDID block and MACHFB_DEBUG is already rather  
spammy ;)

have fun
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBTbnHzcpnzkX8Yg2nAQLK/wf/VXEj1p3qj6Z49cY//ZILNz0eKf9Xbovz
v7+QACVYEg94KyQD20qXWUkBsgDneM8b6GNmojDnoXcEJPvY2P8Hqjw8XcLZ/bRt
40nIsvTPRl+EYzkKQgr5bjONq4CA6VtL4tZGdx4cxeLahRSQLSHgN/FlV91z6SJu
0ToDw2Tua1fw/vjLaVSCrRFicOl7fJqx6DnsTtaqQuA9UR/WnY7ZSwwVI9E/P+e9
L95QfA7lBz4fHqbH26lXQ5bEv9B+BFL0Tuwlt8HILHbL+7FBgI71tg9gIk495N4w
OMiUHHNevRf2xIJmXaRMhiIHzyq3l+NyMLmCuAvjyL5QdyDorXAPdQ==
=vCrC
-----END PGP SIGNATURE-----