RE: Interrupt Disable bit

["O'Shea, David J" <david.j.oshea@intel.com>]

Yes, the new bit is required, in a required register (the Command register).

The register was defined such that 0 (the resevered bit value fro Command
register bits) means IRQ enabled.   And the power-up state is 0, IRQ
generation
enabled.  In that sense its partly backward compatible.  (An OS or BIOS
written
not to take advantage will still work).

However, the bit is required in 2.3, so if you don't implement it, you are
not
creating a 2.3 compliant device.

IRQ interance problems are very common.  And devices which generate IRQ's,
but
which don't install handlers are very, very common.  The most common case is
the
instance where a device has an interrupt for use by its OS driver, but has
no
BIOS opROM at all.    (Say a LAN network device).   The LAN device can
generate
interrupt on packet receipt, but no handler installed.  (This is just an
example
of the issue).

I didn't have anything to do with the specification change- but I must say
I'm
all for it.   Its long overdo.  This should have been done long ago- it
appears
it finally got done because of the work in MSI and MSI-X interrupt delivery.

-David O'Shea

-----Original Message-----
From: Matt Kaufman [mailto:mek@sco.com]
Sent: Thursday, November 14, 2002 12:17 PM
To: O'Shea, David J
Cc: 'Jim Lindeman'; pci-sig@znyx.com
Subject: Re: Interrupt Disable bit


O'Shea, David J wrote:
> The configuration software (BIOS or OS) would disable the generation of
> interrupts,
> unless a driver or opROM enables them in an OS or BIOS POST.
>  
> e.g.  Device interrupt generation is disabled, an opROM loads and the
device
> opROM
> enables interrupts via the command register.
>  
> e.g.  Device interrupt generation is disabled by BIOS in POST, and an OS
> loads.  The
> OS loads a device driver for the for the device, and in finding an
> appropriate device driver,
> either enables the interrupt for the PCI device on driver load, or enables
> the interrupt for
> PCI device when the driver uses the OS IRQ handler registration mechanism.

Sigh. Is this register mandatory? Sorry don't have PCI 2.3 handy.
>  
> The intent is to prevent devices from generating IRQ's until they have a
> device driver
> loaded that can handle them, since IRQ's are shared.    Otherwise, a
device
> may not
> be using its IRQ, but since the IRQ is generated - and shared- with other
> devices,
> those device see unnecessary calls to their IRQ handlers, as the software
> system searches
> for the owner of the IRQ event.   (But there wasn't one, becuase no driver
> is loaded,
> or the driver isn't using the IRQ....)

Not sure the gain's really worth it; sharing interrupts is never great, but
this seems like a corner enough case not to have warranted a spec change.
>  
> Allowing the software subsystem to disable IRQ generation in the device
> solves the issue-
> and that is the point of the Interrupt Disable bit in the command
register.
>  
> -David O'Shea
> Enterprise Products and Services Division, Intel Corp.
> 
> -----Original Message-----
> From: Jim Lindeman [mailto:JLindeman@JNI.com]
> Sent: Thursday, November 14, 2002 11:43 AM
> To: pci-sig@znyx.com
> Subject: Interrupt Disable bit
> 
> 
> Hi,
>  
> Does anyone know how the Interrupt Disable bit in the Command register,
> introduced in PCI 2.3 is intended to be used?
>  
>  
> Thanks,
>  
> Jim Lindeman
> Principal Engineer, ASICs
> JNI Corporation
> 45365 Northport Loop West
> Fremont, CA 94538-6417  
> direct +1.510.360.4714
> fax +1.510.252.0123
> jlindeman@jni.com <mailto:jlindeman@jni.com> 
> www.jni.com <http://www.jni.com> 
>       
> 

-- 
Matt Kaufman
mek@caldera.com
Manager, Device Interfaces Group
The SCO Group, Inc., Murray Hill, NJ   VOX: 908 790 2297    FAX: 908 790
2426