src-test2/sys/dev/aac, branch release/8.0.0_cvs

Create release/8.0.0 for the 8.0-RELEASE.

2009-11-21T06:13:29Z

Approved by: re (implicit) This commit was manufactured to restore the state of the 8.0-RELEASE image.

MFC 196403: Temporarily revert the new-bus locking for 8.0 release.

2009-08-20T20:23:28Z

Approved by: re (kib)

Make the newbus subsystem Giant free by adding the new newbus sxlock.

2009-08-02T14:28:40Z

The newbus lock is responsible for protecting newbus internIal structures, device states and devclass flags. It is necessary to hold it when all such datas are accessed. For the other operations, softc locking should ensure enough protection to avoid races. Newbus lock is automatically held when virtual operations on the device and bus are invoked when loading the driver or when the suspend/resume take place. For other 'spourious' operations trying to access/modify the newbus topology, newbus lock needs to be automatically acquired and dropped. For the moment Giant is also acquired in some key point (modules subsystem) in order to avoid problems before the 8.0 release as module handlers could make assumptions about it. This Giant locking should go just after the release happens. Please keep in mind that the public interface can be expanded in order to provide more support, if there are really necessities at some point and also some bugs could arise as long as the patch needs a bit of further testing. Bump __FreeBSD_version in order to reflect the newbus lock introduction. Reviewed by: ed, hps, jhb, imp, mav, scottl No answer by: ariff, thompsa, yongari Tested by: pho, G. Trematerra , Brandon Gooch Sponsored by: Yahoo! Incorporated Approved by: re (ksmith)

Get correct maxio from the controller and drop the tunable.

2009-07-11T08:10:18Z

The default (64K) is too pessimistic for "new comm" hardware. Also, this is bad because multiple controllers get limited by the global tunable. Reviewed by: scottl Approved by: re (kensmith)

We no longer need to use d_thread_t, migrate to struct thread *.

2009-05-20T17:29:21Z

SVN rev 188743 modified aac_rx_get_fwstatus to use the AAC_RX_OMR0

2009-02-23T18:22:06Z

register instead of AAC_RX_FWSTATUS, as that is the way it's done in Adaptec's vendor driver and in the Linux drivers. (The same applies to aac_rkt_get_fwstatus as well.) However, a concern has been raised about the compatibility of this change and old hardware / firmware versions. In the absense of specific information, revert to the original behaviour if the firmware does not support the "New comm." interface. Users of old cards or firmware haven't reported the problems that are potentially solved by switching to OMR0.

Sync with the official Adaptec vendor driver:

2009-02-21T15:40:03Z

[1] Add the support for the NARK controller which seems a variant of the i960Rx. [2] Split up memory regions and other resources in 2 different parts as long as NARK uses them separately (it is not clear to me why though as long as there are no more informations available on this controller). Please note that in all the other cases, the regions overlaps leaving the default behaviour for all the other controllers. [3] Implement a clock daemon responsible for maintain updated the wall clock time of the controller (run any 30 minutes)*. Submitted by: Adaptec (driver build 15317 [1, 2] and 15727 [3]) Reviewed by: emaste Tested by: emaste Sponsored by: Sandvine Incorporated * Please note that originally, in the Adaptec driver, the clock daemon is not implemented with callouts as in our in-tree driver.

Use outbound message register 0 instead of mailbox 7 in

2009-02-18T01:36:20Z

aac_{rx,rkt}_get_fwstatus, as done in Adaptec's vendor driver as well as the Linux drivers. Submitted by: jkim, from Adaptec's driver

Remove duplicate 2610SA entry.

2008-11-27T20:26:02Z

Submitted by: jkim

Whitespace cleanup.

2008-09-12T18:15:12Z