Subject: Question about iomask and iospace for PCMCIA devices
To: None <tech-kern@netbsd.org>
From: Sverre Froyen <sverre@viewmark.com>
List: tech-kern
Date: 03/20/2006 11:33:30
Hi,

In kern/32938 I submitted a patch that modifies how I/O space is mapped for 
PCMCIA cards.  This patch assumes that if the card's CIS config table entry 
specifies an iospace starting at zero, the I/O space may be mapped to another 
address (set in the IOBASE registers), otherwise it must match exactly the 
config table entry.

Looking through a book on PCCARD and CARDBUS, however, I notice that it is 
iomask that is supposed to determine whether or not mapping is allowed.  The 
book appears to imply:

1) iomask == 0:  iospace addresses must be used as provided, no mapping 
allowed.
2) iomask > 0 && iomask != 0xa: iospace may be remapped (using IOBASE).
3) iomask == 0xa: card follows ISA standard (address space < 1024).

(3) seems to imply that no mapping is allowed when iomask == 0xa

Can anyone confirm or correct this interpretation?

A search of the NetBSD mail archives provides these examples:

pcmcia1: function 0, config table entry 3: I/O card; irq mask ffb8; iomask 0, 
iospace 0-1f; memspace 20000-28fff; ...

No mapping allowed because iomask is zero.  Card must be accessed via I/O 
addresses 0-1f

pcmcia0: function 0, config table entry 5: I/O card; irq mask 86b8; iomask 3, 
iospace 0-7; ...
pcmcia0: function 0, config table entry 3: I/O card; irq mask ffff; iomask 4, 
iospace 0-f; ...
pcmcia0: function 0, config table entry 1: I/O card; irq mask ffff; iomask 7, 
iospace 0-47; memspace 0-3ff; ...

I/O addresses may be mapped to another range, although it would seem that the 
iomask in the first entry would limit the range to 0-7.

pcmcia0: function 0, config table entry 1: I/O card; irq mask 86b8; iomask a, 
iospace 3f8-3ff; ...
pcmcia0: function 0, config table entry 3: I/O card; irq mask 86b8; iomask a, 
iospace 2f8-2ff; ...

I/O addresses must be used as provided (although if the card only decodes the 
first 10 address lines, adding a multiple of 1024 would be OK too).

Comments?

Thanks,

Sverre