RE: Violation PCI spec again

[Lame Brooks-G14738 <Brooks_Lame@mdcexchsrv1.mry.mcd.mot.com>]

Well, Maartin, I can think of three ways you _might_ be able to tackle your
problem: 
	1) Make your device a true multifunction device with four sets of
BARs and four INTn# connections (the private config space may be mirrored,
but the headers may not).  Then when your driver runs, have it check the
interrupt sharing situation an use the function with the interrupt
assignment it prefers.  This way you are compliant and get your pick of the
four different interrupts.  You may even report an appropriate message to
the user if you need a certain device removed (disabled) from using a
certain interrupt as most on-system-board PCI peripherals should have a
mechanism to be disabled.  
	2) Use CPCI legacy interrupts INTP and/or INTS if your system slot
board supports them.  See CPCI Spec section 3.2.7.4.  This option is not
exclusive of  #1 above.  
	3) If you are not going to sell your board as a CPCI compliant
board, consider that you have an embedded application and you can do
whatever you want so long as you don't make the OS barf.  
-- BrooksL

> -----Original Message-----
> From: maarten.ghijsen@philips.com [mailto:maarten.ghijsen@philips.com]
> Sent: Thursday, 23 December, 1999 00:47
> To: Mailing List Recipients
> Subject: Violation PCI spec again
> 
> 
> Hi,
..snip doesn't want to share interrupts..
> 
> Regards from Maarten Ghijsen