Commit Graph

4 Commits

Author SHA1 Message Date
jon
e3a6e9b497 * Better kld support in pccbb/cardbus
- pccbb no longer needs to remember whether a card is inserted.
  - pccbb reissues insertion on load of cardbus/pccard modules.
  - got rid of unnecessary delays in power functions.
  - Cardbus children are no longer deleted if probe/attach fails.
  - non-attached child devices are reprobed at driver_added.

* CARD interface to read CIS
  - added card_cis_read/card_cis_free interface to read arbitrary CIS
    data.  This currently is only implemented in cardbus.

* pccard begins to work
  - pccard can now use higher memory space (and uses it by default).
  - set_memory_offset interface changed.
  - fixed ccr access, which was broken at multiple locations.
  - implement an interrupt handler - pccard can now share interrupts.
  - resource alloc/release/activate/deactivate functions gutted: some
    resources are allocated by the bridge before the child device is
    probed or attached.  Thus the resource "belongs" to the bridge, and
    the pccard_*_resource functions need to fudge the owner/rid.
  - changed some error conditions to panics to speed debugging.

* Mutex fix - Giant is entered at the beginning of thread
2001-01-06 18:04:55 +00:00
jon
b8d4cd34d2 This fixes several problems with CIS as suggested by Justin Gibbs:
4) The cardbus CIS code treats the CIS_PTR as a mapping register if
   it is mentioned in the CIS.  I don't have a spec handy to understand
   why the CIS_PTR is mentioned in the CIS, but allocating a memory range
   for it is certainly bogus.  My patch ignores bar #6 to prevent the
   mapping.
   [The pccard spec says that BAR 0 and 7 (-1 and 6 in thic case since we
    did a minus one) is "reserved".  The off by 1 error has been fixed.
    also bar=5 is invalid for IO maps, so we check it.]

5) The CIS code allocated duplicate resources to those already found
   by cardbus_add_resources().  The fix is to pass in the bar computed
   from the CIS instead of the particular resource ID for that bar,
   so bus_generic_alloc_resource succeeds in finding the old resource.
   [fixed, also removed superfluous (and incorrect) writing back to the
    PCI config space.]

7) The CIS code seems to use the wrong bit to determine rather a particular
   register mapping is for I/O or memory space.  From looking at the
   two cards I have, it seems TPL_BAR_REG_AS should be 0x10 instead
   of 0x08.  Otherwise, all registers that should be I/O mapped gain
   a second mapping in memory space.
   [Oops, the spec does say 0x10..., fixed]

Submitted by: Justin Gibbs
2000-11-29 19:38:25 +00:00
jon
d0008768df Oops, broke CIS reading from ROM on my last commit.
This should fix it.
2000-11-29 16:08:01 +00:00
jon
2ea68e4cbc Initial commit of NEWCARD cardbus side (that actually compiles and works)
Files:
	dev/cardbus/cardbus.c
	dev/cardbus/cardbusreg.h
	dev/cardbus/cardbusvar.h
	dev/cardbus/cardbus_cis.c
	dev/cardbus/cardbus_cis.h
	dev/pccbb/pccbb.c
	dev/pccbb/pccbbreg.h
	dev/pccbb/pccbbvar.h
	dev/pccbb/pccbb_if.m

This should support:
  - cardbus controllers:
    * TI 113X
    * TI 12XX
    * TI 14XX
    * Ricoh 47X
    * Ricoh 46X
    * ToPIC 95
    * ToPIC 97
    * ToPIC 100
    * Cirrus Logic CLPD683x
  - cardbus cards
    * 3c575BT
    * 3c575CT
    * Xircom X3201 (includes IBM, Xircom and, Intel cards)
    [ 3com support already in kernel, Xircom will be committed real soon now]

This doesn't work with 16bit pccards under NEWCARD.

Enable in your config by having "device pccbb" and "device cardbus".
(A "device pccard" will attach a pccard bus, but it means you system have
a high chance of panicing when a 16bit card is inserted)

It should be fairly simple to make a driver attach to cardbus under
NEWCARD -- simply add an entry for attaching to cardbus on a new
DRIVER_MODULE and add new device IDs as necessary.  You should also make
sure the card can be detached nicely without the interrupt routine doing
something weird, like going into an infinite loop.  Usually that should
entail adding an additional check when a pci register or the bus space is
read to check if it equals 0xffffffff.

Any problems, please let me know.

Reviewed by: imp
2000-10-18 03:25:13 +00:00