summaryrefslogtreecommitdiffstats
path: root/sys/dev/isp/isp_pci.c
Commit message (Collapse)AuthorAgeFilesLines
* MFC, r310338:ken2016-12-231-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------------------ r310338 | ken | 2016-12-20 14:17:07 -0700 (Tue, 20 Dec 2016) | 37 lines Turn on FC-Tape by default in the isp(4) driver. FC-Tape provides additional link level error recovery, and is highly recommended for tape devices. It will only be turned on for a given target if the target supports it. Without this setting, we default to whatever FC-Tape setting is in NVRAM on the card. This can be overridden by setting the following loader tunable, for example for isp0: hint.isp.0.nofctape=1 sys/conf/options: Add a new kernel config option, ISP_FCTAPE_OFF, that defaults the FC-Tape configuration to off. sys/dev/isp/isp_pci.c: If ISP_FCTAPE_OFF is defined, turn off FC-Tape. Otherwise, turn it on if the card supports it. share/man/man4/isp.4: Add a description of FC-Tape to the isp(4) man page. Add descriptions of the fctape and nofctape options, as well as the ISP_FCTAPE_OFF kernel configuration option. Add the ispfw module and kernel drivers to the suggested configurations at the top of the man page so that users are less likely to leave it out. The driver works well with the included firmware, but may not work at all with whatever firmware the user has flashed on their card. Sponsored by: Spectra Logic ------------------------------------------------------------------------ Sponsored by: Spectra Logic
* MFC r297858: Allocate separate DMA area for synchronous IOCB execution.mav2016-05-031-2/+21
| | | | | | | | Usually IOCBs should be put on queue for asynchronous processing and should not require additional DMA memory. But there are some cases like aborts and resets that for external reasons has to be synchronous. Give those cases separate 2*64 byte DMA area to decouple them from other DMA scratch area users, using it for asynchronous requests.
* MFC r292764: Split DMA buffers for request, response and ATIO queues.mav2015-12-301-109/+131
|
* MFC r292745: Use single DMA tag for scratch areas of all virtual ports.mav2015-12-301-21/+25
|
* MFC r292725: Unify handles allocation for initiator and target IOCBs.mav2015-12-301-24/+0
| | | | | | I am not sure why this was split long ago, but I see no reason for it. At this point this unification just slightly reduces memory usage, but as next step I plan to reuse shared handle space for other IOCB types.
* MFC r291654, r291727, r291821, r291872, r292034, r292041, r292249, r292042:mav2015-12-221-89/+205
| | | | Add initial support for 16Gbps FC QLogic chips.
* MFC r291365, r291369: One more round of port scanner rewrite.mav2015-11-301-10/+0
| | | | | | | - Make scan aborted by event restart immediately and infinitely. - Improve handling of some loop events from firmware. - Remove loop down timer, adding its functionality to scanner thread. - Some more unification and simplification.
* MFC r291221: Remove "disable" hint, which duplicates system-wide "disabled".mav2015-11-301-20/+0
|
* MFC r291209: Fix target mode support for Qlogic 2200 FC adapters.mav2015-11-301-3/+3
| | | | | Now target mode works for all supported FC adapters except ancient 2100, which is not tested.
* MFC r291188: Rip off target mode support for parallel SCSI QLogic adapters.mav2015-11-301-23/+3
| | | | | | | Hacks to enable target mode there complicated code, while didn't really work. And for outdated hardware fixing it is not really interesting. Initiator mode tested with Qlogic 1080 adapter is still working fine.
* MFC r291147: Increase maximal value of vports tunable to 254.mav2015-11-301-1/+1
| | | | | I am not sure this value is really viable yet, but that is what chips officially support in NPIV mode (in loop mode maximum is 125).
* MFC r289930: Formalize/unify chip (re-)inits.mav2015-11-131-6/+1
|
* MFC r289817: Disable full bus scan by CAM for FC adapters.mav2015-11-131-3/+0
| | | | | | FC port database code already notifies CAM about all devices. Additional full scan is just a waste of time, that by definition won't find anything that is not present in port database.
* MFC r289812, r289852: Some polishing and unification in ISR code.mav2015-11-131-39/+33
|
* MFC r289626: Update firmware images for Qlogic 24xx/25xx from 5.5.0 to 7.3.0.mav2015-11-131-3/+0
| | | | | This also removes separate "_multi" images, since this funcationality is now in base, and there is simply no new images without it for years.
* MFC r284727: Add dev.isp.X.role sysctl in addition to tunable.mav2015-06-281-13/+40
| | | | | | | It (mostly) allows to enable/disable initiator mode in run time. Target mode control is blocked here to force coordination with CTL. While there, add separate tunables/sysctls for virtual channels.
* MFC r257932:mav2014-01-051-0/+9
| | | | | | Use relaxed (write-only) memory barriers when writing some of queue index registers (for now on ISP2400+). We never read those registers back and AFAIK their semantics does not require any immediate reaction on write.
* Update PCI drivers to no longer look at the MEMIO-enabled bit in the PCIscottl2013-08-121-7/+5
| | | | | | | | | | | | | | | | | command register. The lazy BAR allocation code in FreeBSD sometimes disables this bit when it detects a range conflict, and will re-enable it on demand when a driver allocates the BAR. Thus, the bit is no longer a reliable indication of capability, and should not be checked. This results in the elimination of a lot of code from drivers, and also gives the opportunity to simplify a lot of drivers to use a helper API to set the busmaster enable bit. This changes fixes some recent reports of disk controllers and their associated drives/enclosures disappearing during boot. Submitted by: jhb Reviewed by: jfv, marius, achadd, achim MFC after: 1 day
* 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.
OpenPOWER on IntegriCloud