summaryrefslogtreecommitdiffstats
path: root/sys/dev
Commit message (Collapse)AuthorAgeFilesLines
* Revert r251023 until a more proper solution is foundhselasky2013-05-282-32/+0
| | | | | | for ATI based USB controllers. MFC after: 1 week
* Workaround for for a problem seen with ATI Technologies EHCIhselasky2013-05-272-0/+32
| | | | | | | | | | | | | | | | controller hardware most likely present on UHCI chipsets aswell. The bug manifests itself when issuing isochronous transfers and bulk transfers towards the same device simultaneously. From time to time it happens that either the completion IRQ was missing or that the completion IRQ was happening before the ITD/SITD was completely written back to memory. The workaround assumes that double buffered isochronous transfers are used, and that a second interrupt is generated at the beginning of the next isochronous transfer to complete the previous one. Possibly skipping the interrupt at the last isochronous frame is possible, but will then break single buffered isochronous transfers. For now we can live with some extra interrupts. MFC after: 1 week
* Fix ONFI chip detection.gber2013-05-272-2/+2
| | | | Submitted by: Alexander Fedorov <alexander.fedorov@rtlservice.com>
* Migrate ath(4) to now use if_transmit instead of the legacy if_startadrian2013-05-264-219/+243
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and if queue mechanism; also fix up (non-11n) TX fragment handling. This may result in a bit of a performance drop for now but I plan on debugging and resolving this at a later stage. Whilst here, fix the transmit path so fragment transmission works. The TX fragmentation handling is a bit more special. In order to correctly transmit TX fragments, there's a bunch of corner cases that need to be handled: * They must be transmitted back to back, in the same order.. * .. ie, you need to hold the TX lock whilst transmitting this set of fragments rather than interleaving it with other MSDUs destined to other nodes; * The length of the next fragment is required when transmitting, in order to correctly set the NAV field in the current frame to the length of the next frame; which requires .. * .. that we know the transmit duration of the next frame, which .. * .. requires us to set the rate of all fragments to the same length, or make the decision up-front, etc. To facilitate this, I've added a new ath_buf field to describe the length of the next fragment. This avoids having to keep the mbuf chain together. This used to work before my 11n TX path work because the ath_tx_start() routine would be handed a single mbuf with m_nextpkt pointing to the next frame, and that would be maintained all the way up to when the duration calculation was done. This doesn't hold true any longer - the actual queuing may occur at any point in the future (think ath_node TID software queuing) so this information needs to be maintained. Right now this does work for non-11n frames but it doesn't at all enforce the same rate control decision for all frames in the fragment. I plan on fixing this in a followup commit. RTS/CTS has the same issue, I'll look at fixing this in a subsequent commit. Finaly, 11n fragment support requires the driver to have fully decided what the rate scenario setup is - including 20/40MHz, short/long GI, STBC, LDPC, number of streams, etc. Right now that decision is (currently) made _after_ the NAV field value is updated. I'll fix all of this in subsequent commits. Tested: * AR5416, STA, transmitting 11abg fragments * AR5416, STA, 11n fragments work but the NAV field is incorrect for the reasons above. TODO: * It would be nice to be able to queue mbufs per-node and per-TID so we can only queue ath_buf entries when it's time to assemble frames to send to the hardware. But honestly, we should just do that level of software queue management in net80211 rather than ath(4), so I'm going to leave this alone for now. * More thorough AP, mesh and adhoc testing. * Ensure that net80211 doesn't hand us fragmented frames when A-MPDU has been negotiated, as we can't do software retransmission of fragments. * .. set CLRDMASK when transmitting fragments, just to ensure.
* Unbreak ia64 tinderbox: 64-bit support was made conditional uponmarcel2013-05-261-13/+4
| | | | | | | __amd64__, and thus limited. Eliminate 2 trivial conditionals by casting the 64-bit integral, holding an address, via (uintptr_t) to (void *) and replace the last remaining check for __amd64__ with a check for __LP64__ instead.
* Fix some statical clang analyzer warnings.hselasky2013-05-253-5/+1
|
* Fix the data corruption on the swap-backed md.kib2013-05-241-1/+7
| | | | | | | | | | | Assign the rv variable a success code if the pager was not asked for the page. Using an error code from the previous processed page caused zeroing of the valid page, when e.g. the previous page was not available in the pager. Reported by: lstewart Sponsored by: The FreeBSD Foundation MFC after: 1 week
* Driver 'aacraid' added. Supports Adaptec by PMC RAID controller families ↵achim2013-05-248-0/+8303
| | | | | | Series 6, 7, 8 and upcoming products. Older Adaptec RAID controller families are supported by the 'aac' driver. Approved by: scottl (mentor)
* Fix typo in the definition of the TWS_DATA_CCB.kib2013-05-231-1/+1
| | | | Submitted by: Andreas Turriff <maillist@turriff.net>
* Correct panic on detach of Xen PV network interfaces.gibbs2013-05-221-3/+7
| | | | | | | | | | | | | | dev/xen/netfront: In netif_free(), properly stop the interface and drain any pending timers prior to disconnecting from the backend device. Remove all media and detach our interface object from the system prior to deleting it. PR: kern/176471 Submitted by: Roger Pau Monne <roger.pau@citrix.com> Reviewed by: gibbs MFC after: 1 week
* Fix NULL-dereference kernel panic in case of mps_attach() failure.mav2013-05-221-2/+2
| | | | MFC after: 1 week
* Implement a separate hardware queue threshold for aggregate and non-aggradrian2013-05-215-12/+65
| | | | | | | | | | | | | | | | traffic. When transmitting non-aggregate traffic, we need to keep the hardware busy whilst transmitting or small bursts in txdone/tx latency will kill us. This restores non-aggregate iperf performance, especially when doing TDMA. Tested: * AR5416<->AR5416, TDMA * AR5416 STA <-> AR9280 AP
* Enable the use of TDMA on an 802.11n channel (with aggregation disabled,adrian2013-05-213-6/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of course.) There's a few things that needed to happen: * In case someone decides to set the beacon transmission rate to be at an MCS rate, use the MCS-aware version of the duration calculation to figure out how long the received beacon frame was. * If TxOP enforcing is available on the hardware and we're doing TDMA, enable it after a reset and set the TDMA guard interval to zero. This seems to behave fine. TODO: * Although I haven't yet seen packet loss, the PHY errors that would be triggered (specifically Transmit-Override-Receive) aren't enabled by the 11n HAL. I'll have to do some work to enable these PHY errors for debugging. What broke: * My recent changes to the TX queue handling has resulted in the driver not keeping the hardware queue properly filled when doing non-aggregate traffic. I have a patch to commit soon which fixes this situation (albeit by reminding me about how my ath driver locking isn't working out, sigh.) So if you want to test this without updating to the next set of patches that I commit, just bump the sysctl dev.ath.X.hwq_limit from 2 to 32. Tested: * AR5416 <-> AR5416, with ampdu disabled, HT40, 5GHz, MCS12+Short-GI. I saw 30mbit/sec in both directions using a bidirectional UDP test.
* Fix build break - the SetCapability calls return HAL_BOOL,adrian2013-05-211-1/+1
| | | | not HAL_STATUS.
* Add new USB quirk.hselasky2013-05-212-0/+2
| | | | | MFC after: 1 week PR: usb/178771
* Extend the TXOP enforce capability to support checking whether it'sadrian2013-05-211-0/+6
| | | | supported.
* Add basic support for FDT to i386 & amd64. This change includes:marcel2013-05-213-98/+226
| | | | | | | | | | | | | | | | | | | | | | 1. Common headers for fdt.h and ofw_machdep.h under x86/include with indirections under i386/include and amd64/include. 2. New modinfo for loader provided FDT blob. 3. Common x86_init_fdt() called from hammer_time() on amd64 and init386() on i386. 4. Split-off FDT specific low-level console functions from FDT bus methods for the uart(4) driver. The low-level console logic has been moved to uart_cpu_fdt.c and is used for arm, mips & powerpc only. The FDT bus methods are shared across all architectures. 5. Add dev/fdt/fdt_x86.c to hold the fdt_fixup_table[] and the fdt_pic_table[] arrays. Both are empty right now. FDT addresses are I/O ports on x86. Since the core FDT code does not handle different address spaces, adding support for both I/O ports and memory addresses requires some thought and discussion. It may be better to use a compile-time option that controls this. Obtained from: Juniper Networks, Inc.
* Merge ACPICA 20130517.jkim2013-05-201-3/+7
|
* - Prefer ACPI_COMPARE_NAME(a, b) macro over strncmp(a, b, ACPI_NAME_SIZE).jkim2013-05-201-9/+8
| | | | | - Make sure the predefined name is a string type. - Return slightly more useful errors.
* Fix white spaces.jkim2013-05-201-33/+31
|
* Make the HT rate duration calculation work for MCS rates > 15.adrian2013-05-201-2/+2
|
* Update snd quirks for T520, T420, X220.sbruno2013-05-191-0/+10
| | | | | | | | | | | | | Group onboard mic and headphone mic jack together. Creates association that will switch between microphone inputs depending on the state of the headphone jack being connected to a live mic. Fixes onboard mic not working at all on T520. Tested on T520, T420. Suspect X220 needs this too, untested on. MFC after: 1 month
* More non-ATH_DEBUG build fixes.adrian2013-05-191-3/+5
|
* Since we're now using the ah pointer, always declare it.adrian2013-05-191-2/+0
| | | | This fixes non-DEBUG builds.
* Added output of device QUIRKS for CAM and AHCI devices during boot.smh2013-05-181-0/+20
| | | | | | Reviewed by: mav Approved by: pjd (mentor) MFC after: 2 weeks
* Be (very) careful about how to add more TX DMA work.adrian2013-05-185-149/+195
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The list-based DMA engine has the following behaviour: * When the DMA engine is in the init state, you can write the first descriptor address to the QCU TxDP register and it will work. * Then when it hits the end of the list (ie, it either hits a NULL link pointer, OR it hits a descriptor with VEOL set) the QCU stops, and the TxDP points to the last descriptor that was transmitted. * Then when you want to transmit a new frame, you can then either: + write the head of the new list into TxDP, or + you write the head of the new list into the link pointer of the last completed descriptor (ie, where TxDP points), then kick TxE to restart transmission on that QCU> * The hardware then will re-read the descriptor to pick up the link pointer and then jump to that. Now, the quirks: * If you write a TxDP when there's been no previous TxDP (ie, it's 0), it works. * If you write a TxDP in any other instance, the TxDP write may actually fail. Thus, when you start transmission, it will re-read the last transmitted descriptor to get the link pointer, NOT just start a new transmission. So the correct thing to do here is: * ALWAYS use the holding descriptor (ie, the last transmitted descriptor that we've kept safe) and use the link pointer in _THAT_ to transmit the next frame. * NEVER write to the TxDP after you've done the initial write. * .. also, don't do this whilst you're also resetting the NIC. With this in mind, the following patch does basically the above. * Since this encapsulates Sam's issues with the QCU behaviour w/ TDMA, kill the TDMA special case and replace it with the above. * Add a new TXQ flag - PUTRUNNING - which indicates that we've started DMA. * Clear that flag when DMA has been shutdown. * Ensure that we're not restarting DMA with PUTRUNNING enabled. * Fix the link pointer logic during TXQ drain - we should always ensure the link pointer does point to something if there's a list of frames. Having it be NULL as an indication that DMA has finished or during a reset causes trouble. Now, given all of this, i want to nuke axq_link from orbit. There's now HAL methods to get and set the link pointer of a descriptor, so what we should do instead is to update the right link pointer. * If there's a holding descriptor and an empty TXQ list, set the link pointer of said holding descriptor to the new frame. * If there's a non-empty TXQ list, set the link pointer of the last descriptor in the list to the new frame. * Nuke axq_link from orbit. Note: * The AR9380 doesn't need this. FIFO TX writes are atomic. As long as we don't append to a list of frames that we've already passed to the hardware, all of the above doesn't apply. The holding descriptor stuff is still needed to ensure the hardware can re-read a completed descriptor to move onto the next one, but we restart DMA by pushing in a new FIFO entry into the TX QCU. That doesn't require any real gymnastics. Tested: * AR5210, AR5211, AR5212, AR5416, AR9380 - STA mode.
* Re-add some code to exclude transmitting if we're in reset.adrian2013-05-181-0/+19
| | | | | This fixes some "transmitting during reset" bugs that crept in after I messed around with this part of the transmit path.
* Don't clear stall at first time use of USB MIDI endpoints.hselasky2013-05-181-5/+4
| | | | | | | | | Most likely some non-USB compliant devices will choke on it sooner or later. Clear stall is strictly speaking not needed. If the first MIDI command sent or transmitted is lost, this is not a big problem for us. MFC after: 1 week
* Fix issue with "Logitech Webcam C525":hselasky2013-05-181-0/+27
| | | | | | | | | | Set a valid alternate interface setting when enumerating USB audio devices else the device mentioned will not work like expected. PR: usb/178722 MFC after: 1 week
* For ARM, MIPS, and PowerPC, default to 32-byte alignment, but allow itimp2013-05-171-0/+4
| | | | to be as small as 8.
* o Retrive the part number (CP2103 etc) from the hardware on attach.gavin2013-05-171-12/+56
| | | | | | | | | o The CP2101 and CP2102 do not support GPIO pin use at all, enforce this. o Support reading the GPIO status on the second port of the CP2105. More work is needed before the CP2105 GPIO pins can be used as outputs. Hardware donated by: Silicon Labs MFC after: 3 weeks
* Add new capability types encodings from HyperTransport I/O Linkkib2013-05-171-0/+4
| | | | | | | Specification revisions 3.00 and 3.10. Submitted by: Dmitry Luhtionov <dmitryluhtionov@gmail.com> MFC after: 1 week
* Add some more debugging printf()s to complain if the ath_buf tx queueadrian2013-05-171-0/+23
| | | | | | | | | | | | | | | doesn't match the actual hardware queue this frame is queued to. I'm trying to ensure that the holding buffers are actually being queued to the same TX queue as the holding buffer that they end up on. I'm pretty sure this is all correct so if this complains, it'll be due to some kind of subtle broken-ness that needs fixing. This is only done for legacy hardware, not EDMA hardware. Tested: * AR5416 STA mode, very lightly
* When reporting the user readable size, round up. Several SD cards notimp2013-05-161-3/+5
| | | | | only use SI units, but also are a couple of percent short. If you need to know the exact size, diskinfo will return exact results.
* Tidy up the debugging - don't bother printing out TID pointers; nowadrian2013-05-161-23/+24
| | | | | that we are printing out the MAC address in these fields, just printing out the TID is enough.
* Limit the number of software queued frames when doing non-aggregation.adrian2013-05-161-2/+6
| | | | | This should prevent the TX queue being filled with non-aggregate frames, causing starvation and non-fair queue behaviour.
* Dump out the holding buffer descriptor contents and addresses stopping DMA.adrian2013-05-161-2/+12
|
* Add dependencies on the firmware, which allows the loading of the cxgbkib2013-05-162-0/+3
| | | | | | | and cxgbe modules. Reviewed and approved by: np MFC after: 1 week
* Implement my first cut at "correct" node power-save andadrian2013-05-157-72/+504
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PS-POLL support. This implements PS-POLL awareness i nthe * Implement frame "leaking", which allows for a software queue to be scheduled even though it's asleep * Track whether a frame has been leaked or not * Leak out a single non-AMPDU frame when transmitting aggregates * Queue BAR frames if the node is asleep * Direct-dispatch the rest of control and management frames. This allows for things like re-association to occur (which involves sending probe req/resp as well as assoc request/response) when the node is asleep and then tries reassociating. * Limit how many frames can set in the software node queue whilst the node is asleep. net80211 is already buffering frames for us so this is mostly just paranoia. * Add a PS-POLL method which leaks out a frame if there's something in the software queue, else it calls net80211's ps-poll routine. Since the ath PS-POLL routine marks the node as having a single frame to leak, either a software queued frame would leak, OR the next queued frame would leak. The next queued frame could be something from the net80211 power save queue, OR it could be a NULL frame from net80211. TODO: * Don't transmit further BAR frames (eg via a timeout) if the node is currently asleep. Otherwise we may end up exhausting management frames due to the lots of queued BAR frames. I may just undo this bit later on and direct-dispatch BAR frames even if the node is asleep. * It would be nice to burst out a single A-MPDU frame if both ends support this. I may end adding a FreeBSD IE soon to negotiate this power save behaviour. * I should make STAs timeout of power save mode if they've been in power save for more than a handful of seconds. This way cards that get "stuck" in power save mode don't stay there for the "inactivity" timeout in net80211. * Move the queue depth check into the driver layer (ath_start / ath_transmit) rather than doing it in the TX path. * There could be some naughty corner cases with ps-poll leaking. Specifically, if net80211 generates a NULL data frame whilst another transmitter sends a normal data frame out net80211 output / transmit, we need to ensure that the NULL data frame goes out first. This is one of those things that should occur inside the VAP/ic TX lock. Grr, more investigations to do.. Tested: * STA: AR5416, AR9280 * AP: AR5416, AR9280, AR9160
* Add Qlogic 10Gigabit Ethernet & CNA Adapter Driver Version 3.10.10 fordavidcs2013-05-1517-0/+11480
| | | | | | | QLogic 8300 Series Adapters Submitted by: David C Somayajulu (davidcs@freebsd.org) QLogic Corporation Approved by: George Neville-Neil (gnn@freebsd.org)
* Add ALQ beacon debugging.adrian2013-05-133-0/+28
|
* Support sending ATH_ALQ messages with no payload.adrian2013-05-131-3/+5
|
* Remove a bogus re-assignment.jkim2013-05-131-2/+0
| | | | MFC after: 3 days
* Deal correctly with 40G ports that don't have any transceiver pluggednp2013-05-131-0/+7
| | | | | | in. Do not claim that they have unknown tranceivers. MFC after: 3 days
* Improve the debugging output - use the MAC address rather than variousadrian2013-05-132-37/+112
| | | | pointer values everywhere.
* Since the node state is 100% back under the TX lock, just kill the useadrian2013-05-132-17/+10
| | | | | | of atomics. I'll re-think this nonsense later.
* Oops, commit the other half of r250606.adrian2013-05-132-27/+135
|
* This lock only protects the rate control state for now, mention this.adrian2013-05-131-1/+1
|
* Begin tidying up the reassociation and node sleep/wakeup paths.adrian2013-05-131-22/+37
| | | | | | | | | | | | | | | | | | * Move the node sleep/wake state under the TX lock rather than the node lock. Let's leave the node lock protecting rate control only for now. * When reassociating, various state needs to be cleared. For example, the aggregate session needs to be torn down, including any pending aggregation negotiation and BAR TX waiting. * .. and we need to do a "cleanup" pass since frames in the hardware TX queue need to be transmitted. Modify ath_tx_tid_cleanup() to be called with the TX lock held and push frames into a completion list. This allows for the cleanup to be done atomically for all TIDs in a node rather than grabbing and releasing the TX lock each time.
* Fix several typoseadler2013-05-124-5/+5
| | | | | | PR: kern/176054 Submitted by: Christoph Mallon <christoph.mallon@gmx.de> MFC after: 3 days
OpenPOWER on IntegriCloud