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.


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

Reply via email to