Re: machfb (sort of) working on Mach64 GX

[David Riley <fraveydank%gmail.com@localhost>]

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).

>> 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.

> 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.


- Dave