o Use pf more consistantly for pccard_function.
o Make sure we quote the strings properly (maybe this function belongs in
subr_bus.c)
o Tweak a comment to be more accurate after code changed.
scan the CIS for interesting tuples. 95% of what can be obtained from
the CIS is harvested by the pccard layer and presented to the user in
standard function calls. However, there are special needs at times
where the standard stuff doesn't suffice. This is for those special
cases.
CARD_SCAN_CIS(device_get_parent(dev), function, argp)
scans the CIS of the card, passing each tuple to function with
the tuple and argp as its arguments. Returning 0 continues the scan,
while returning 1 terminates the scan. The value of the last
invocation of function is returned from this function.
int (*pccard_scan_t)(struct pccard_tuple *tuple, void *argp)
function called for each tuple. Elements of the CIS tuple can be
read with pccard_tuple_read_{1,2,3,4,n}(). You are reading
the actual tuple memory each time, in case your card has
registers in the CIS.
# I suppose these things should be documented in pccard(4) or something like
# that.
# I plan on unifying cardbus CIS support in a similar way.
Approved by: re (scottl)
Provide a backwards compatible way to have the extra macro by defining
PCCARD_API_LEVEL 5 before including pccarddevs for driver writers that
want/need to have the same driver on 5 and 6 with pccard attachments.
Approved by: re (dwhite)
problems here, it became clear we were being too complex.
o Don't keep track of resources in two places
o Use resource_list_purge instead of rolling our own
o Just reassign the ownership of the resource, rather than freeing it
and reallocating it.
o Fix compile problems when sizeof(u_long) != sizeof(int)
this code:
o rid is stored in the resource, so don't bother keeping track of it here.
o Implement memory space
o Don't try to activate 'memory card' CFEs. This is type memory, as opposed
to the memory resource.
o Fix MFC cards. We were bogusly setting CCR_IOBASE[01] and CCR_IOLIMIT.
now when we activate the resource, we adjust these for MFC cards, per the
spec.
o Change type of pf_mfc_* to be bus_addr_t, which is more correct than
long.
This makes my 3C362D/3C363D and 3CXEM556 cards work! Woo Hoo!
routine of its own, and allows us to move the indentation back two
layers making the code more readable.
delete a prototype that should have been killed years ago in pccardvar.h.
# adding quirks here is way harder than it needs to be. :-(
o Use 32-bit unsigned types for things that really are 32-bit quantities,
not bus_addr_t. These are not the same as a bus_addr_t, so don't use
that here. Harmless on i386, introduced problems on sparc64.
Submitted by: jhb
in the .h file. Make it static __inline to make sure that it doesn't
wind up defined in any files.
Also, fix a typo that said null_do_attach instead of null_do_probe.
pccard layer and rename them PCMCIA_CARD and PCMCIA_CARD2 respectively
(note, this is being done with an eye towards NetBSD integreation so
it is easier to keep lists of cards between us and them in sync).
Use this in the an and wi drivers.
Briefly, the significant changes include:
* Way better resource management in pccbb, pccard and cardbus.
* pccard hot-removal now appears to work.
* support pre-fetchable memory in cardbus.
* update cardbus to support new pci bus interface functions.
* Fix CIS reading to no longer use rman_get_virtual().
What's not there, but in the works:
* pccard needs to do interrupt properly and not read the ISR on single
function cards.
* real resource management for pccard
* a complete implementation of CIS parsing
* need to look into how to correctly use mutex in pccbb
pccard in the kernel for those drivers with pccard attachments. This
makes the compat layer a little larger by introducing some inlines,
but should almost make it possible to have independent attachments.
The pccard_match function are the only one left, which I will take
care of shortly.
- 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
before the attach. Things aren't completely working, but this is a good
checkpoint.
Also, initialize the dev member of the function as soon as we add it
to the parent.
o initialize ivars with bzero.
o remove interrupt function pointer. netbsd needs it, but we don't.
o add lots of comments about bogus things that I've been kludging to try
to make the simple cases work.
o add new ivar accessor for cis4 to match cis3. likely neither will be
needed, but it doesn't hurt to have it.
pcmciavar.h 1.9->1.12
1.12, enami, minor coding nits
1.11, augustss, (pcmcia_devinfo NRFB)
1.10, cgd, add generic lookup routines
pcmcia.c 1.14->1.23
1.23, drochner, (probe code printing, NRFB)
1.22, augustss, KNF
1.21, uch, (hpcmips tweaks NRFB)
1.20, chopps, remove bogus debug
1.19, enami, minor coding nits
1.18, augustss, (pcmcia_devinfo NRFB)
1.17, nathanw, LP64 printf fixes
1.16, cgd, add generic lookup routines
1.15, aymeric, printf fixes
NRFB == not relevant to freebsd
o Expand the pccard matching routines to include the ability to match
against the CIS strings since our current driver database is based on
that.
o Add lots more ivars to get the information necessary to snag these values.
possible to have different probe/attach semantics between the two
systems and yet still use the same driver for both.
Compatibility methods for OLDCARD drivers. We use these routines to make
it possible to call the OLDCARD driver's probe routine in the context that
it expects. For OLDCARD these are implemented as pass throughs to the
device_{probe,attach} routines. For NEWCARD they are implemented such
such that probe becomes strictly a matching routine and attach does both
the old probe and old attach.
compat devices should use the following:
/* Device interface */
DEVMETHOD(device_probe), pccard_compat_probe),
DEVMETHOD(device_attach), pccard_compat_attach),
/* Card interface */
DEVMETHOD(card_compat_match, foo_match), /* newly written */
DEVMETHOD(card_compat_probe, foo_probe), /* old probe */
DEVMETHOD(card_compat_attach, foo_attach), /* old attach */
This will allow a single driver binary image to be used for both
OLDCARD and NEWCARD.
Drivers wishing to not retain OLDCARD compatibility needn't do this.
ep driver minorly updated.
sn driver updated more than minorly. Add module dependencies to allow
module to load. Also change name to if_sn. Add some debugging code.
attempt to fix the cannot allocate memory problem I'd been seeing.
Minor formatting nits.
that it looks for an acceptible one. Once it finds it, it should set
the resources for the device. I say "should" because I've not written
that. Also set an ivar for the child of pccard. Minor fix to the
attach message printed, we lose the slot number, which I'll have to
restore later. Adjust the pccard ivar so that we can save the
function that corresponds to this driver so we can enable and disable
it more easily. Save a pointer to the function so we know what we're
dealing with.
There should be some way for the driver to specify which cfg it wants
to activate. For now the pccard_function_init function just picks
one, but we'll have to revisit this going forward. I'm not doing it
now because I'd need some way to activate the card many times and I'm
not sure that is desirable or even safe with some cards.
