Index: [thread] [date] [subject] [author]
  From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Tue, 11 May 1999 21:05:58 +0200 (MEST)

Re: Multiple ATI Video Cards

Hi 

> Using field definitions from linux/drivers/pci/pci.h, the only relevant
> differences between the first & second video cards was in COMMAND (bytes 4
> & 5) which was 0087 on active card 0:b.0 and 0082 on idle card 0:c.0.  

Yep. That's what the other post said as well.

0x87 means: 0x01 Enable response in I/O space
	    0x02 Enable response in Memory space
            0x04 Enable bus mastering
	    0x80 Enable address/data stepping

while 0x82 mean IO disabled as well as busmaster.

> But with cards' command register contents swapped by means of 
> "setpci -s 0:b.0 command=82" and  "setpci -s 0:c.0 command=87", 
> (confirmed by "lspci -vvx", which showed 0:b.0 disabled and 0:c.0 enabled)
> GGI's "demo" still ran beautifully on card 0:b.0, but displayed trash on 
> card 0:c.0 (after "export FRAMEBUFFER=/dev/fb1).

I don't know about the ATI programming model, but as long as you don't set
up a mode or call the accelerator, you shouldn't need to access the IO region
anyway.

What you see is still the preset mode and LibGGI changig the framebuffer
that already is mapped on both cards.

You could try to change the mode on fb0. If it fails, my assumption is true,
that the IO space is required for mode setup.

> Should driver init procedures aty_init and atyfb_init be run again? 

Yes. Probably. wait ... yes. Looks that way.

> And if so, how?  Modify fbset?

I'd either write a usermode "lookalike" that just does what atyfb would do
in its init procedure or copy the init function somewhere in the driver, 
where you can call it with an ioctl or similar at driver runtime.

However I only know how to do that for a KGI driver, so ...

CU, Andy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =

Index: [thread] [date] [subject] [author]