- Obsolete redundant inst_name and unit members of struct sym_hcb.
- Fix three more NULL vs. 0 confusions.
- Use device_set_softc(9) to tell the bus layer that this driver
allocates a instance of struct sym_hcb itself.
in order to get rid of bus space handle and tag in struct sym_hcb.
- Remove unused members related to bus addresses in struct sym_hcb.
- sym(4) takes care of allocating an instance of struct sym_hcb
itself so don't let newbus allocate it as an unused softc also.
- Add basic MPSAFE locking. This includes changing the sym(4) CCBs
to be allocated up-front instead of on demand as needed. Besides
making these allocations more likely to succeed, this also solves
the problem of calling bus_dmamap_create(9) with the SIM mutex
held.
Reviewed by: scottl
MFC after: 1 month
- Remove superfluous returns in functions returning void.
- In sym_alloc_lcb_tags() return directly instead of jumping
to a label which just returns.
- Fix some spelling in comments.
- Remove trailing whitespace.
4KB pages as i386, data structures that just fit in one page on i386 (and
on 64 bit architectures with 8KB pages) can be distributed over two pages
on amd64. This is a porblem in the case of the Symbios driver, since the
SCRIPTS engine in the SCSI chip operates on physical addresses and needs
physically contiguous memory. Earlier patches used contigmalloc on amd64,
but this version replaces part of a structure by a pointer to that data.
In order to not introduce an extra indirection for other architectures,
the change has been made conditional on __amd64__.
Earlier attempts to repair this problem are removed (i.e. the macros that
made amd64 use contigmalloc). The fix was submitted by Jan Mikkelsen and
modified by me to only affect amd64.
PR: 89550
Submitted by: janm at transactionware dot com (Jan Mikkelsen)
Approved by: re (Hiroki Sato)
MFC after: 2 weeks
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.
sparc64 GENERIC and the sound device drivers known working on sparc64
to use bus_get_dma_tag() to obtain the parent DMA tag so we can get rid
of the sparc64_root_dma_tag kludge eventually. Except for ath(4), sk(4),
stge(4) and ti(4) these changes are runtime tested (unless I booted up
the wrong kernels again...).
function provided by the driver limits allocations to the page size,
i.e. 4KB on i385 and 8KB on typical 64 bit processors. Since amd64
has 64 bit pointers, but only 4KB pages, an array of pointers that
just fits into one page on all the other processors, does require
2 pages on amd64.
In order to make this driver useful on amd64, the allocation unit
has been increased to 2 pages on amd64 and contigmalloc() is used
instead of malloc(). All other processor types are unaffected by
this change. This modification has only been compile-tested on
amd64, yet, but should just work (FLW).
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
Devices below may experience a change in geometry.
* Due to a bug, aic(4) never used extended geometry. Changes all drives
>1G to now use extended translation.
* sbp(4) drives exactly 1 GB in size now no longer use extended geometry.
* umass(4) drives exactly 1 GB in size now no longer use extended geometry.
For all other controllers in this commit, this should be a no-op.
Looked over by: scottl
MFC after:3 days
- Add memory barrier definition for sparc64.
Patch sent by David E. O'Brien, approved by maintainer.
- Fix an endianization error of a bus physical address used from SCRIPTS
that made the driver fail on big endian machines as sparc64.
MFC after: 5 days
- Mask GPCNTL against 0x1c (was 0xfc) for the reading of the NVRAM.
This ensures LEDC bit will not be set on 896 and later chips.
Submitted by Chip Salzenberg <chip@perlsupport.com>.
- Add probe for Tekram 390 U2B/U2W SCSI (53C895) LED handling.
Submitted by Chip Salzenberg <chip@valinux.com>
possible for some systems where the device is there, but the BIOS
hasn't allocated memory resources for it), we don't panic.
Submitted by: Gerard Roudier
- Missing cpu_to_scr() added (endian-ness).
Improvement (fix|workaroung??):
- Blindly firing a PPR can lead to some messy situations due to
various causes or misfeatures, for example:
* The 53C1010-[33|66] supports offset 62 in DT mode, but only
offset 31 in ST mode. As a result, a PPR(DT, offset 62)
responded with PPR(ST, any offset > 31) must be rejected.
* A device that doesn't know about PPR should reject it, but
may also be confused by this message.
When a PPR encounters problems, the driver now patches the goal
transfer settings for legacy negotiations to be performed later
with the offending target. This give a chance for bad situations
to be fixed automagically.
- When used on a 33MHz PCI BUS, the 53C1010-66 revision 0
requires extra clocks to be inserted in data out phase.
Revision 1 is fixed.
- The 53C1010-33 revision 1 requires internal cycles to be
disabled due to possible contentions on IO registers.
Revision 2 is fixed.
Fix:
- The probing of HVD from GPIO3 bit by the driver was reversed.
The driver could misprobe the bus mode of a 825 or 875 chip
that was not previously initialized (no BIOS for example).
