On Wed, 8 Nov 2000, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> "Matthew N.
>Dodd" writes:
> : On Wed, 8 Nov 2000, Warner Losh wrote:
> : > The cardbus code, for example, will or in the RF_SHAREABLE bit when
> : > appropriate.
> :
> : Right, but the drivers that are consumers of the PCI or CARDBUS bus
> : interface shouldn't have to deal with RF_SHAREABLE; the bus driver should
> : do that. I grant you that this isn't the case at the moment but it should
> : be.
>
> We are in violent agreement. The cardbus bridge code is the one that
> adds RF_SHAREABLE in the right places.
We currently have about 146 calls to bus_alloc_resource() for SYS_RES_IRQ.
Most seem to get this wrong. E.g.:
- pci drivers "know" that pci interrupts are shareable and force
RF_SHAREABLE. Is this required by the pci spec?
- the isa compatibility code and pcvt force RF_SHAREABLE although isa
irqs are rarely shareable.
- sio forces !RF_SHAREABLE, but it is possible for sio interrupts to be
shared if they aren't fast.
- the pci compatibility code forces RF_SHAREABLE, except for fast interrupts
it forces !RF_SHAREABLE. This overloads RF_SHAREABLE to mean that the
device driver supports sharing. Perhaps this is what RF_SHAREABLE as
supplied by drivers should mean. The bus level can match it with
shareability actually available and maybe reprogram that shareability
to match what the driver prefers. This seems to require more flags for
requires/prefer/no_preference/cant_do. Non-shared resources should
degrade gracefully to shared ones if a driver that requires shared is
attached after a driver that prefers non-shared.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
