In message <199811021526.KAA19521@doppelganger.old-oak.net>  Rafal Boni wrote:
> In message <199811020726.QAA25609@hannya.spa.is.uec.ac.jp>, msaitoh writes: 
> -> 
> -> 	When the IRQ bit is set, it indecates that an interrupt description
> -> 	follows the I/O address bytes, if any. The interrupt request levels
> -> 	specfied by the Configuration Table Entry Tuple describe the
> -> 	preferred routing for the card's IREQ# line. Routing of the IREQ#
> -> 	interrupts is performed by the host system which actually determines
> -> 	the system interrupt level used. A client which is the sole consumer
> -> 	of the card's IREQ# interrupt may elect to route the IREQ# line to a
> -> 	level not specified by the Configuration Table Entry Tuple.
> -> 	A generic card configuration utility which is not the ultimate
> -> 	consumer of the card's IREQ# interrupt should only route to the
> -> 	specified interrupt levels. ...
> 
> Given that the standard says a card should be able to use any interrupt even
> though the IRQMASK says otherwise, I can see why the code works the way it
> does now... However, are there good reasons *NOT* to use the card's IRQMASK 
> from the CTE-tuple (as opposed to reasons we *DON'T* use it?).
> 
> My gut feeling (knowning very little about PCMCIA), would be to always use
> the IRQMASK presented by the card unless that masks out all available IRQs
> and then fall back to allocating from all available ones irrespective of the
> IRQMASK in the CTE tuple.  Is this bad for some reason I'm not aware of?

Using the card's IRQ mask makes IRQ allocation for your system a lot harder
as it doesn't matter for any PCMCIA-card which IRQ it uses, becauses this is 
routed in the PCIC chip. PCMCIA has only one IRQ line (pin 16, aka READY).

Your problem is more likely that on your system the interrupt or IO-address
assigned by NetBSD to the PCMCIA-card is allocated by a device not probed 
(yet) by NetBSD. The config PCIC_ISA_INTR_ALLOC_MASK option is the  way to 
fight that, as it may change with your machine not with your card.

> 
> If the above is acceptable, I'll whip up a patch to do just that.  If there
> are reasons it's not, I'd like to hear them... In that case, maybe a PCMCIA
> quirk that forces use of the IRQMASK on some cards should be created, and
> cards like mine should be entered into the quirk table with said quirk.

It can't be the card it knows nothing about the IRQ-level ...

> 
> [I'm interested in this for the ISA PCIC case on x86... I'm not sure how
>  this would impact the other PCIC attachments, and welcome any insight
>  on that as well...]

Hmmm, make sure the interrupt NetBSD picks is set to ISA-legacy in the 
BIOS so the system doesn't pick it for PCI or PnP.

> 
> Comments, other ideas?
> --rafal

Stefan

> 
> ----
> Rafal Boni                                                  rafal@mediaone.net

--
Stefan Grefen                                Tandem Computers Europe Inc.
grefen@hprc.tandem.com                       High Performance Research Center
 --- Hacking's just another word for nothing left to kludge. ---