In message <[EMAIL PROTECTED]> Terry Lambert writes:
: 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.
Give me an example of hardware that does this. I know of no devices
in the tree that do this....
: > [*] 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.
That's a different problem.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message