summaryrefslogtreecommitdiffstats
path: root/sys/dev/isp/isp_pci.c
Commit message (Collapse)AuthorAgeFilesLines
* Reform the busdma API so that new types may be added without modifyingkib2013-02-121-62/+10
| | | | | | | | | | | | | | | | | | | | | 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>)
* Don't allow for more than one segment for the control space sincemjacob2012-11-021-3/+2
| | | | | | we're not set up to deal with that. MFC after: 1 week
* Remove useless extra test.mjacob2012-09-071-4/+2
| | | | | Pointed out by: Sascha of DragonFly BSD MFC after: 2 weeks
* Remove dependence on MAXPHYS.mjacob2012-08-211-2/+7
| | | | MFC after: 1 month
* Fix an oops where we wiped out DMA maps. Don't allocate extendedmjacob2012-08-121-10/+12
| | | | | | | command space for anything less than a 2300. MFC after: 1 month X-MFC: 238869
* Oops. We only do allocate room for extended commandsmjacob2012-08-031-10/+12
| | | | | | | | | and responses for 2300 cards are newer. Sponsored by: Spectralogic Noticed by: Our Friend Manfred MFC after: 1 month X-MFC: 238869
* -----------mjacob2012-07-281-14/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MISC CHANGES Add a new async event- ISP_TARGET_NOTIFY_ACK, that will guarantee eventual delivery of a NOTIFY ACK. This is tons better than just ignoring the return from isp_notify_ack and hoping for the best. Clean up the lower level lun enable code to be a bit more sensible. Fix a botch in isp_endcmd which was messing up the sense data. Fix notify ack for SRR to use a sensible error code in the case of a reject. Clean up and make clear what kind of firmware we've loaded and what capabilities it has. ----------- FULL (252 byte) SENSE DATA In CTIOs for the ISP, there's only a limimted amount of space to load SENSE DATA for associated CHECK CONDITIONS (24 or 26 bytes). This makes it difficult to send full SENSE DATA that can be up to 252 bytes. Implement MODE 2 responses which have us build the FCP Response in system memory which the ISP will put onto the wire directly. On the initiator side, the same problem occurs in that a command status response only has a limited amount of space for SENSE DATA. This data is supplemented by status continuation responses that the ISP pushes onto the response queue after the status response. We now pull them all together so that full sense data can be returned to the periph driver. This is supported on 23XX, 24XX and 25XX cards. This is also preparation for doing >16 byte CDBs. ----------- FC TAPE Implement full FC-TAPE on both initiator and target mode side. This capability is driven by firmware loaded, board type, board NVRAM settings, or hint configuration options to enable or disable. This is supported for 23XX, 24XX and 25XX cards. On the initiator side, we pretty much just have to generate a command reference number for each command we send out. This is FCP-4 compliant in that we do this per ITL nexus to generate the allowed 1 thru 255 CRN. In order to support the target side of FC-TAPE, we now pay attention to more of the PRLI word 3 parameters which will tell us whether an initiator wants confirmed responses. While we're at it, we'll pay attention to the initiator view too and report it. On sending back CTIOs, we will notice whether the initiator wants confirmed responses and we'll set up flags to do so. If a response or data frame is lost the initiator sends us an SRR (Sequence Retransmit Request) ELS which shows up as an SRR notify and all outstanding CTIOs are nuked with SRR Received status. The SRR notify contains the offset that the initiator wants us to restart the data transfer from or to retransmit the response frame. If the ISP driver still has the CCB around for which the data segment or response applies, it will retransmit. However, we typically don't know about a lost data frame until we send the FCP Response and the initiator totes up counters for data moved and notices missing segments. In this case we've already completed the data CCBs already and sent themn back up to the periph driver. Because there's no really clean mechanism yet in CAM to handle this, a hack has been put into place to complete the CTIO CCB with the CAM_MESSAGE_RECV status which will have a MODIFY DATA POINTER extended message in it. The internal ISP target groks this and ctl(8) will be modified to deal with this as well. At any rate, the data is retransmitted and an an FCP response is sent. The whole point here is to successfully complete a command so that you don't have to depend on ULP (SCSI) to have to recover, which in the case of tape is not really possible (hence the name FC-TAPE). Sponsored by: Spectralogic MFC after: 1 month
* Clean up multi-id mode so it's driven by the f/w loaded,mjacob2012-06-241-14/+8
| | | | | | | | | | | | not by some hint setting. Do more preparations for FC-Tape. Clean up resource counting for 24XX or later chipsets so we find out after EXEC_FIRMWARE what is actually supported. Set target mode exchange count based upon whether or not we are supporting simultaneous target/initiator mode. Clean up some old (pre-24XX) xfwoption and zfwoption issues. Sponsored by: Spectralogic MFC after: 3 days
* Prepare for FC-Tape support. This involved doing a lot of little cleanupsmjacob2012-06-171-10/+5
| | | | | | | | | | | | | | | | | | | | and crosschecks against firmware documentation. We now check and report FC firmware attributes and at least are now prepared for the upper 48 bits of f/w attributes (which are probably for the 8100 or later cards). This involed changing how inbits and outbits are calculated for varios commands, hopefully clearer and cleaner. This also caused me to clean up the actual mailbox register usage. Finally, we are now unconditionally using a CRN for initiator mode. A longstanding issue with the 2400/2500 is that they do *not* support a "Prefer PTP followed by loop", which explains why enabling that caused the f/w to crash. A slightly more invasive change is to let the firmware load entirely drive whether multi_id support is enabled or not. Sponsored by: Spectralogic MFC after: 1 week
* If debug values were set, the default from tval floatedmjacob2012-06-151-0/+1
| | | | | | | down and triggered an attempt to set multiple virtual ports whether you wanted them or not. MFC after: 3 days
* Adding missing dependancies for loading hptiop(4), hptmv(4) and isp(4) as ↵eadler2012-06-011-0/+2
| | | | | | | | | | | | modules. PR: kern/166239 Submitted by: Pavel Timofeev <timp87@gmail.com> Discussed on: -stable, -scsi Reviewed by: scottl No objection from: mjacob Approved by: cperciva MFC after: 3 days
* Was chasing down a failure to load f/w on a 2400. It turns out that the cardmjacob2011-11-161-0/+2
| | | | | | is actually broken, or needs a BIOS upgrade for 64 bit loads, but this uncovered a couple of misplaced opcode definitions and some missing continual mbox command cases, so might as well update them here.
* Most of these changes to isp are to allow for isp.ko unloading.mjacob2011-08-131-28/+52
| | | | | | | | | | | We also revive loop down freezes. We also externaliz within isp isp_prt_endcmd so something outside the core module can print something about a command completing. Also some work in progress to assist in handling timed out commands better. Partially Sponsored by: Panasas Approved by: re (kib) MFC after: 1 month
* Add support QLE220 card- an 2500 lookalike.mjacob2011-03-101-0/+15
| | | | | Obtained mostly from: Roman && Konstantin MFC after: 1 week
* - Use the correct DMA tag/map pair for synchronize the FC scratch area.marius2011-02-141-16/+16
| | | | | | | | | | | - Allocate coherent DMA memory for the request/response queue area and and the FC scratch area. These changes allow isp(4) to work properly on sparc64 with usage of the IOMMU streaming buffers enabled. Approved by: mjacob MFC after: 2 weeks
* Various minor and not so minor fixes suggested by Coverity.mjacob2010-06-021-13/+13
| | | | | | | In at least one case, it's amazing that target mode worked at all. Found by: Coverity. MFC after: 2 weeks
* On sparc64 obtain the initiator ID from the Open Firmware device treemarius2010-05-031-0/+9
| | | | | | in order to match what the PROM built-in driver uses. Approved by: mjacob
* Put gone device timer into a structure tag that can hold more than 32 ↵mjacob2010-03-171-3/+3
| | | | | | | | | | seconds. Oops. Untangle some of the confusion about what role means when it's in the FCPARAM/SDPARAM or isp_fc/isp_spi structures. This fixed a problem about seeing targets appear if you've turned off autologin and find them, or rather don't, via camcontrol rescan. MFC after: 1 month
* Revamp the pieces of some of the stuff I forgot to do when shifting tomjacob2010-02-271-12/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | 32 bit handles. The RIO (reduced interrupt operation) and fast posting for the parallel SCSI cards were all 16 bit handles. Furthermore, target mode parallel SCSI only can have 16 bit handles. Use part of a supplied patch to switch over to using 32 bit handles. Be a bit more conservative here and only do this for parallel SCSI for the 12160 (Ultra3) cards. There were a lot of marginal Ultra2 cards, and, frankly, few are findable now for testing. Fix the target handle routine to only do 16 bit handles for parallel SCSI cards. This is okay because the upper sixteen bits of the new 32 bit handles is a sequence number to help protect against duplicate completions. This would be very unlikely to happen with parallel SCSI target mode, and wasn't present before, so we're no worse off than we used to be. While we're at it, finally split the async mailbox completion handlers into FC and parallel SCSI functions. This makes it much cleaner and easier to figure out what is or isn't a legal async mailbox completion code for different card classes. PR: kern/144250 Submitted partially by: Charles D MFC after: 1 week
* Fix misallocation error in target mode.mjacob2010-02-271-1/+1
| | | | MFC after: 1 day
* Redo how commands handles are created and managed and implement sequencemjacob2010-02-031-4/+12
| | | | | | | | | | | | numbers and handle types in rational way. This will better protect from (unwittingly) dealing with stale handles/commands. Fix the watchdog timeout code to better protect itself from mistakes. If we run an abort on a putatively timed out command, the command may in fact get completed, so check to make sure the command we're timing it out is still around. If the abort succeeds, btw, the command should get returned via a different path.
* Add 8Gb support (isp_2500). Fix a fair number of configuration andmjacob2009-08-011-1457/+488
| | | | | | | | | | | | | | | | | | | | | firmware loading bugs. Target mode support has received some serious attention to make it more usable and stable. Some backward compatible additions to CAM have been made that make target mode async events easier to deal with have also been put into place. Further refinement and better support for NP-IV (N-port Virtualization) is now in place. Code for release prior to RELENG_7 has been stripped away for code clarity. Sponsored by: Copan Systems Reviewed by: scottl, ken, jung-uk kim Approved by: re
* Pointy hat to me. Committed with building.mjacob2007-06-261-1/+1
| | | | Approved by: re (ken, implicit)
* Extension of previous commit- when we have 2k login firmware, we need tomjacob2007-06-261-1/+7
| | | | | | | | put out a ispreqt2e_t structure onto the request queue- not a ispreqt2_t structure. I forgot that the 23XX can use a t2 structure. Approved by: re (ken, implicitly) MFC after: 3 days
* Yet another bug- when we have 2k login firmware, we needmjacob2007-06-251-1/+7
| | | | | | | | | to put out a ispreqt3e_t structure onto the request queue- not a ispreqt3_t structure. We weren't. This turns out only to really matter for big endian machines. Approved by: re (ken) MFC after: 3 days
* Only try and set a segment lim size to 1 << 32 iff bus_size_t > 4.mjacob2007-06-111-2/+6
|
* Fix pointy-hat problem with BUS_DMA_ROOTARG macro that caused problems for ↵mjacob2007-05-111-3/+3
| | | | | | | | sparc64. Candidate for immediate MFC. Noticed by: Everyone-maxim contacted.
* Make this an MP safe driver but also still be multi-release.mjacob2007-05-051-135/+99
| | | | | | | | Seems to work on RELENG_4 through -current and also on sparc64 now. There may still be some issues with the auto attach/detach code to sort out. MFC after: 3 days
* Temporarily desupport simultaneous target and initiator mode.mjacob2007-04-021-6/+8
| | | | | | | | | | | | | | | | | | | | | | | When the linux port changes were imported which split the target command list to be separate from the initiator command list and the handle format changed to encode a type in the handle the implications to the function isp_handle_index (which only the NetBSD/OpenBSD/FreeBSD ports use) were overlooked. The fault is twofold: first, the index into the DMA maps in isp_pci is wrong because a target command handle with the type bit left in place caused a bad index (and panic) into dma map. Secondly, the assumption of the array of DMA maps in either PCS or SBUS attachment structures is that there is a linear mapping between handle index and DMA map index. This can no longer be true if there are overlapping index spaces for initiator mode and target mode commands. These changes bandaid around the problem by forcing us to not have simultaneous dual roles and doing the appropriate masking to make sure things are indexed correctly. A longer term fix is being devloped.
* MFP4: a) Some constification from NetBSD (gcc 4.1.2)mjacob2007-03-221-6/+1
| | | | | | | b) Split default param fetching/setting into scsi and fibre functions and retry the fibre fetch more than once. MFC after: 1 week
* Move bus_space_tag and bus_space_handle register accessmjacob2007-03-131-78/+64
| | | | | | | | | | tokens into the common isp_osinfo structure instead of being in bus specific structures. This allows us to implement a SYNC_REG MEMORYBARRIER call (using bus_space_barrier) and also reduce the amount of bus specific wrapper structure usages in isp_pci && isp_sbus. MFC after: 3 days
* Fix compilation issues found in RELENG_4 port and merge themjacob2007-03-121-1/+3
| | | | diffs back to -current to keep versions identical.
* Fix some stupid copyright mistakes that have been there for quite some time.mjacob2007-03-101-2/+0
|
* Redo previous newbus related change to be kinder tomjacob2007-02-231-1/+2
| | | | multi-release support.
* o break newbus api: add a new argument of type driver_filter_t topiso2007-02-231-1/+1
| | | | | | | | | | | | | 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@
* There is a problem in setting/getting 'options'- if we check thingsmjacob2007-02-231-111/+133
| | | | | | | | | | | early, we haven't set board type, so we can't correctly check for some options. Fix this by splitting option setting/getting into generic, pci and then later board specific, option setting/getting. This was noticed when setting 'iid' (or 'hard loop id') didn't work all of a sudden. Noticed by: Mike Drangula (thanks!) via Jung-uk Kim (thanks!)
* add a missing piece for 2432mjacob2007-02-101-0/+1
|
* Putative untested 2432 (PCI-E) support.mjacob2007-02-101-1/+12
|
* Clean up some of the various platform and release specific dma tagmjacob2007-01-231-25/+10
| | | | | | | stuff so it is centralized in isp_freebsd.h. Take out PCI posting flushed in qla2100/2200 register reads except for 2100s.
* error print cleanup && turn off ints if RISC is pausedmjacob2007-01-051-1/+2
|
* Restore revision 1.126 that got accidentally nuked.mjacob2006-12-181-0/+6
|
* Implement ISP_RESET0 for PCI and SBUS attachments- isp_reset hasmjacob2006-12-161-7/+14
| | | | | been modified to call ISP_RESET0 if it fails to do a reset. This gives us a chance to disable interrupts.
* Remove dependency on ispfw and firmware as modules.mjacob2006-12-101-4/+1
| | | | | | | | | | | | | | | | | Either they're there early and the ispfw sets have registered themselves, or they're not. The module dependency stuff isn't quite what we want anyway. If the user doesn't want the load placed on system memory by loading the firmware, they don't specify it to be loaded (either by being linked in or via being a module to be loaded and then hooked in with firmware(9)). It doesn't then make sense to then override what they want by pulling it in anyway. This might be able to work if we were able to pull in just exactly what we needed for the card we have- but that's an optimization left for the future.
* Make the SAN login/logout stuff more common between different chipsetsmjacob2006-11-181-6/+0
| | | | | | and provied an isp_control entry point so that the outer layers can do PLOGI/LOGO explicitly. Add MS IOCB support. This completes the cycle for base support for SMI-S.
* Disable code to set max read byte count on the 2400.mjacob2006-11-171-0/+6
| | | | | | | It caused a panic in writing the config register on a system. Turn it off until we take the time to understand it. Reported by and Testing by: Anton
* Push things closer to path failover by implementing loop down andmjacob2006-11-141-3/+25
| | | | | | | | | | | | | | | | | | | | | | | | | gone device timers and zombie state entries. There are tunables that can be used to select a number of parameters. loop_down_limit - how long to wait for loop to come back up before declaring all devices dead (default 300 seconds) gone_device_time- how long to wait for a device that has appeared to leave the loop or fabric to reappear (default 30 seconds) Internal tunables include (which should be externalized): quick_boot_time- how long to wait when booting for loop to come up change_is_bad- whether or not to accept devices with the same WWNN/WWPN that reappear at a different PortID as being the 'same' device. Keen students of some of the subtle issues here will ask how one can keep devices from being re-accepted at all (the answer is to set a gone_device_time to zero- that effectively would be the same thing).
* Add 4Gb (24XX) support and lay the foundation for a lot of new stuff.mjacob2006-11-021-60/+458
|
* Restore multi-version cleanliness.mjacob2006-09-031-3/+11
|
* add a newbus method for obtaining the bus's bus_dma_tag_t... This isjmg2006-09-031-2/+3
| | | | | | | | | | | | | required by arches like sparc64 (not yet implemented) and sun4v where there are seperate IOMMU's for each PCI bus... For all other arches, it will end up returning NULL, which makes it a no-op... Convert a few drivers (the ones we've been working w/ on sun4v) to the new convection... Eventually all drivers will need to replace the parent tag of NULL, w/ bus_get_dma_tag(dev), though dev is usually different for each driver, and will require hand inspection... Reviewed by: scottl (earlier version)
* More ispfwfunc definitions funnies which break pre-7.0 builds.mjacob2006-09-011-1/+0
|
OpenPOWER on IntegriCloud