Warner Losh wrote:
> That is, I advocate all busses that support sharing to or in
> RF_SHAREABLE when appropriate.  The trouble is that with the current
> interfaces, that precludes one from using fast interrupts.  FAST or
> not fast is a property of bus_setup_intr, not bus_alloc_resource.  sio
> is the only driver in the tree using fast interrupts (although there
> are several not in the tree by third parties that use this) right now,
> and it treats the INTR_FAST bit as a strong hint only.

The problem with this is drivers that can't share
interrupts because there is no way to ask the hardware
which of several devices caused the interrupt.  This
means that it's an attribute of the driver, not the
bus, so having the bus do this automatically would not
be correct.

> [*] Even on ISA systems, one can share interrupts to a limited
> extent.  The two pccards could share interrupts (with the right magic
> programmed on some ISA chipsets).  The pccards could share with the
> CSC interrupt (aka management interupt), but again this requires
> special magic on some bridges, none on others and isn't supported at
> all on still others).  Some pccard bridge chipsets let you HI-Z IRQ 15
> or 14 and thus share them with the IDE controller.  I've disallowed
> all these sharing potentials because you'll notice a fair number of
> weasel words in the previous sentences (some, might, magic).

I've frequently thought that the COM1/COM3 and COM2/COM4
interrupt duality should be permitted, with FreeBSD doing
the interlock based on only permitting one of the pair to
be open at a time: that is, the interrupt gets set up for
one or the other of them based on what's open and what's
not.  Historically, internal modems have liked to be on
COM3 or COM4, yet you are stuck with the internal serial
ports glomming onto the interrupts.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to