does not display the symptom). Evidently the ifpi2 controller needs to be
massaged more than it was.
Note that this does not close the PR since it was filed against 4.9.
MFC: 5 days
PR: kern/68756
Submitted by: Ari Suutari <ari.suutari@syncrontech.com>
Add two new arguments to bus_dma_tag_create(): lockfunc and lockfuncarg.
Lockfunc allows a driver to provide a function for managing its locking
semantics while using busdma. At the moment, this is used for the
asynchronous busdma_swi and callback mechanism. Two lockfunc implementations
are provided: busdma_lock_mutex() performs standard mutex operations on the
mutex that is specified from lockfuncarg. dftl_lock() is a panic
implementation and is defaulted to when NULL, NULL are passed to
bus_dma_tag_create(). The only time that NULL, NULL should ever be used is
when the driver ensures that bus_dmamap_load() will not be deferred.
Drivers that do not provide their own locking can pass
busdma_lock_mutex,&Giant args in order to preserve the former behaviour.
sparc64 and powerpc do not provide real busdma_swi functions, so this is
largely a noop on those platforms. The busdma_swi on is64 is not properly
locked yet, so warnings will be emitted on this platform when busdma
callback deferrals happen.
If anyone gets panics or warnings from dflt_lock() being called, please
let me know right away.
Reviewed by: tmm, gibbs
The current name is confusing, because it indicates to
the client that a bus_dmamap_sync() operation is not
necessary when the flag is specified, which is wrong.
The main purpose of this flag is to hint the underlying
architecture that DMA memory should be mapped in a coherent
way, but the architecture can ignore it. But if the
architecture does supports coherent mapping of memory, then
it makes bus_dmamap_sync() calls cheap.
This flag is the same as the one in NetBSD's Bus DMA.
Reviewed by: gibbs, scottl, des (implicitly)
Approved by: re@ (jhb)
where physical addresses larger than virtual addresses, such as i386s
with PAE.
- Use this to represent physical addresses in the MI vm system and in the
i386 pmap code. This also changes the paddr parameter to d_mmap_t.
- Fix printf formats to handle physical addresses >4G in the i386 memory
detection code, and due to kvtop returning vm_paddr_t instead of u_long.
Note that this is a name change only; vm_paddr_t is still the same as
vm_offset_t on all currently supported platforms.
Sponsored by: DARPA, Network Associates Laboratories
Discussed with: re, phk (cdevsw change)
i4bq931, i4b, isic, iwic, ifpi, ifpi2, ifpnp, ihfc, and itjc are
no longer count devices. Also remove a few other instances of N<DEVICE>
being used to control compilation of whole files.
Reviewed by: hm
most cases NULL is passed, but in some cases such as network driver locks
(which use the MTX_NETWORK_LOCK macro) and UMA zone locks, a name is used.
Tested on: i386, alpha, sparc64
form L0IFPI2UNIT. This could result in a panic if the user tried to
trace using isdntrace(8). I fixed this locally but forgot to commit it.
Reminded by: "Wittig, Christoph" <wc@medianet-world.de>
- remove all occurances of FLAG_XXX values and replace with CARD_TYPEP_XXX
- remove sc_flag from isic softc and replace it with sc_cardtyp
remove some left over redundant definitions from isic and i4b_l1.h
remove left over cvs id from i4b cvs repository
from Traverse Technology and also the Teles PCI-TJ cards both based on the
chipset combination of the Siemens ISAC and the TJNet Tiger300/320 chips.
The itjc/i4b_hdlc.h file will hopefully soon be merged with the file
/usr/src/sys/i4b/layer1/i4b_hdlc.h.
Submitted by: Sergio de Souza Prallon <prallon@tmp.com.br>
enables the driver to work on current (I have not tested the isa part fully,
but I suppose it should work). The patching from jlemon caused a crash at
probe time. This is probably my fault not having added a comment for
"RESET_SOFT" saying: "this resets all!".
Submitted by: Hans Petter Selasky <hselasky@c2i.net>
avma1pp_attach_avma1pp, since the former may be called multiple
times and we only want to initialize the mutex once.
Submitted by: Thomas Moestl <tmoestl@gmx.net>
