On Thu, 2 Sep 1999, Gerard Roudier wrote:
[SNIPPED]
>
> In PCI, INTERRUPT ARE NOT SYNCHRONISATION EVENTS! Synchronisation
> events are PCI TRANSACTIONS in the context of ordering rules defined by
> the specs,....
This sounds like something written by a lawyer. In plan language, any
hardware interrupt is a hardware request for some software to do
something. The interrupt event, itself, does not convey any
knowledge about the reason why the interrupt occurred. Software has
to inspect the hardware to determine the reason for the interrupt.
With shared interrupts, it is mandatory that the software that handles
an interrupt event (the ISR), not complain if it finds that it got
control and, upon inspecting the hardware, finds there is nothing to
do.
How the PCI controller, raises the maskable interrupt pin on the
CPU make no difference at all. One doesn't care if it's a 'PCI
TRANSACTION' or a 'PYROSYNCHROGEM'. If it happened fast enough so
the event isn't stale, nobody cares --and if the software cares,
it's broken.
>
> G?rard.
>
Cheers,
Dick Johnson
**** FILE SYSTEM WAS MODIFIED ****
Penguin : Linux version 2.3.13 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
On Fri, 3 Sep 1999, Richard B. Johnson wrote:
> On Thu, 2 Sep 1999, Gerard Roudier wrote:
> [SNIPPED]
>
> >
> > In PCI, INTERRUPT ARE NOT SYNCHRONISATION EVENTS! Synchronisation
> > events are PCI TRANSACTIONS in the context of ordering rules defined by
> > the specs,....
>
> This sounds like something written by a lawyer. In plan language, any
The specifications _are_ the laws conformant hardwares and softwares shall
follow, and nothing else. People that use them as toilet paper are not
doing the right thing, in my opinion. ;-)
> hardware interrupt is a hardware request for some software to do
> something. The interrupt event, itself, does not convey any
> knowledge about the reason why the interrupt occurred. Software has
> to inspect the hardware to determine the reason for the interrupt.
The piece of software that inspects the device status registers (or
memory) that tell about things to do must not care about the reason for
which it has been called, and must do proper things to synchronyze
correctly with the device, since INTERRUPTS ARE NOT SYNCHRONISATIONS
EVENTS in PCI.
> With shared interrupts, it is mandatory that the software that handles
> an interrupt event (the ISR), not complain if it finds that it got
> control and, upon inspecting the hardware, finds there is nothing to
> do.
NOT A SYNCHRONISATION EVENT as I wrote.
> How the PCI controller, raises the maskable interrupt pin on the
> CPU make no difference at all. One doesn't care if it's a 'PCI
> TRANSACTION' or a 'PYROSYNCHROGEM'. If it happened fast enough so
> the event isn't stale, nobody cares --and if the software cares,
> it's broken.
Donnot know what a PYROSYNCHROGEM is, but the prefix PYRO may let think
you wanted to flame somebody. ;-)
Indeed a software based in "fast enough" sorts of considerations is way
broken and is just race-based. It must base its behaviour on ordering
rules.
The order in which the PCI controller deals with data and raises the
interrupt, and the way both the PCI device and the C code access shared
memory or IO registers makes a GREAT difference, especially when posted
transactions are used.
Obviously, the PCI device must make available the data to the CPU prior
to raising the interrupt. But both the PCI device and the C code must
behave correctly in order not to stall and not to see inconsistent data.
G?rard.