| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
In some cases limits are just not needed, in others -- DFLTPHYS is the
right constant to use instead.
MFC after: 1 month
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, any timeout value for which (timeout * hz) will overflow the
signed integer, will give weird results, since callout(9) routines will
convert negative values of ticks to '1'. For unsigned integer overflow we
will get sufficiently smaller timeout values than expected.
Switch from callout_reset, which requires conversion to int based ticks
to callout_reset_sbt to avoid this.
Also correct isci to correctly resolve ccb timeout.
This was based on the original work done by Eygene Ryabinkin
<rea@freebsd.org> back in 5 Aug 2011 which used a macro to help avoid
the overlow.
Differential Revision: https://reviews.freebsd.org/D1157
Reviewed by: mav, davide
MFC after: 1 month
Sponsored by: Multiplay
|
|
|
|
| |
map created by bus_dmamem_alloc().
|
| |
|
|
|
|
| |
Coverity CID: 1109817
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
every architecture's busdma_machdep.c. It is done by unifying the
bus_dmamap_load_buffer() routines so that they may be called from MI
code. The MD busdma is then given a chance to do any final processing
in the complete() callback.
The cam changes unify the bus_dmamap_load* handling in cam drivers.
The arm and mips implementations are updated to track virtual
addresses for sync(). Previously this was done in a type specific
way. Now it is done in a generic way by recording the list of
virtuals in the map.
Submitted by: jeff (sponsored by EMC/Isilon)
Reviewed by: kan (previous version), scottl,
mjacob (isp(4), no objections for target mode changes)
Discussed with: ian (arm changes)
Tested by: marius (sparc64), mips (jmallet), isci(4) on x86 (jharris),
amd64 (Fabian Keil <freebsd-listen@fabiankeil.de>)
|
| |
|
|
|
|
| |
Submitted by: delphij
|
|
|
|
|
|
| |
- Remove use of explicit bus space handles and tags.
Tested by: no one
|
|
|
|
| |
rather than NULL.
|
| |
|
|
|
|
|
|
|
| |
now takes a device_t to be the parent of the bus that is being created.
Most SIMs have been updated with a reasonable argument, but a few exceptions
just pass NULL for now. This argument isn't used yet and the newbus
integration likely won't be ready until after 7.0-RELEASE.
|
|
|
|
|
|
|
|
|
|
|
| |
use to synchornize and protect all data objects that are used for that
SIM. Drivers that are not yet MPSAFE register Giant and operate as
usual. RIght now, no drivers are MPSAFE, though a few will be changed
in the coming week as this work settles down.
The driver API has changed, so all CAM drivers will need to be recompiled.
The userland API has not changed, so tools like camcontrol do not need to
be recompiled.
|
|
|
|
|
|
|
|
|
|
|
|
| |
bus_setup_intr()
o add an int return code to all fast handlers
o retire INTR_FAST/IH_FAST
For more info: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=465712+0+current/freebsd-current
Approved by: re (implicit?)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bus_setup_intr()
o add an int return code to all fast handlers
o retire INTR_FAST/IH_FAST
For more info: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=465712+0+current/freebsd-current
Reviewed by: many
Approved by: re@
|
|
|
|
|
| |
PR: 106543
MFC after: 3 days
|
|
|
|
|
| |
Reviewed by: cognet and imp
Approved by: cognet and imp
|
|
|
|
|
|
| |
as the default.
Reviewed by multitudes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the CAM_NEW_TRAN_CODE that has been in the tree for some years now.
This first step consists solely of adding to or correcting
CAM_NEW_TRAN_CODE pieces in the kernel source tree such
that a both a GENERIC (at least on i386) and a LINT build
with CAM_NEW_TRAN_CODE as an option will compile correctly
and run (at least with some the h/w I have).
After a short settle time, the other pieces (making
CAM_NEW_TRAN_CODE the default and updating libcam
and camcontrol) will be brought in.
This will be an incompatible change in that the size of structures
related to XPT_PATH_INQ and XPT_{GET,SET}_TRAN_SETTINGS change
in both size and content. However, basic system operation and
basic system utilities work well enough with this change.
Reviewed by: freebsd-scsi and specific stakeholders
|
|
|
|
|
|
|
|
| |
cam.ko are modules so that aha.ko's undefined symbols can be satisfied by
cam.ko.
Sumitted by: nork
Reviewed by: scottl
|
|
|
|
|
|
| |
and amd64. The optimization is a trivial on recent machines.
Reviewed by: -arch (imp, marcel, dfr)
|
|
|
|
| |
error cases.
|
| |
|
| |
|
|
|
|
|
|
|
| |
have the card and no way to reproduce problems. We do this by
applying the workaround to firmware revsion 0.
PR: 14334
|
| |
|
|
|
|
| |
Noticed by: njl
|
| |
|
| |
|
|
|
|
|
| |
Submitted by: Mark Santcroos <marks@ripe.net>
Reviewed by: imp, dfr, bde
|
|
|
|
|
|
| |
Use this in preference to aha_name.
Remove aha_name function and #define it to device_get_unitname()
Minor indentation tweaks resulting therefrom
|
| |
|
|
|
|
| |
properly belongs.
|
|
|
|
| |
Also some minor whitespace nits.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
o When we're resetting the board, make sure that we error out the pending
CCBs first. Otherwise the aha_cmd won't accept further commands, such
as those that are used to reset the card (AOP_INITIALIZE_MBOX). This
appears to cause a cascade failure where no more commands are possible
to the card.
o Reduce from 10s down to 1s the amount of time we're willing to tolerate
the card being awol. This helps the above case.
o Add some error checking to two commands issued in the probe.
I have a dim memory of gibbs@ trying to tell me about this problem a
few years ago, so pointy hat to imp@ for sitting on it so long.
|
| |
|
| |
|
|
|
|
| |
Also some minor style cleanups.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
BUS_DMASYNC_ definitions remain as before. The does not change the ABI,
and reverts the API to be a bit more compatible and flexible. This has
survived a full 'make universe'.
Approved by: re (bmah)
|
|
|
|
| |
to bus_dmasync_op_t in my last commit.
|
| |
|
|
|
|
| |
Submitted by: Hiten Pandya <hiten@unixdaemons.com>
|
|
|
|
| |
especially in troff files.
|
|
|
|
|
| |
pointer arithmetic. Detour via uintptr_t, since we're generating an
offset not dereferencing them.
|
|
|
|
|
| |
'int nsegments' argument to bus_dma_tag_create(). ~0ul does not fit in
an int on machines with 64 bit longs.
|
|
|
|
| |
again.
|
|
|
|
|
|
|
| |
I could find. I have no doubt missed a couple.
Interrupt entropy harvesting is still conditional on the
kern.random.sys.harvest_interrupt sysctl.
|