summaryrefslogtreecommitdiffstats
path: root/sys/dev
Commit message (Collapse)AuthorAgeFilesLines
* (Mostly) teach ath_rate_sample about MCS rates.adrian2011-01-282-94/+246
| | | | | | | | | | | | | | This is just the bare minimum needed to teach ath_rate_sample to try and handle MCS rates. It doesn't at all attempt to find the best rate by any means - it doesn't know anything about the MCS rate relations, TX aggregation or any of the much sexier 11n stuff that's out there. It's just enough to transmit 11n frames and handle TX completion. It shouldn't affect legacy (11abg) behaviour. Obtained from: rpaulo@
* Make space for the extended 802.11n MCS rate tables.adrian2011-01-281-1/+1
|
* Bring in some 802.11n packet duration calculation functions from a mix of ↵adrian2011-01-282-1/+86
| | | | | | | | | Sam/Rui and linux ath9k . This will eventually be used by rate control modules and by the TX code for calculating packet duration when handling rts/cts protection. Obtained from: sam@, rpaulo@, linux ath9k
* Add support for BIO_DELETE on swap-backed md(4). In the case of BIO_DELETEkib2011-01-271-6/+10
| | | | | | | | | | | covering the whole page, free the page. Otherwise, clear the region and mark it clean. Not marking the page dirty could reinstantiate cleared data, but it is allowed by BIO_DELETE specification and saves unneeded write to swap. Reviewed by: alc Tested by: pho MFC after: 2 weeks
* Initialise the chainmask from the EEPROM rather than the hard-coded defaults.adrian2011-01-271-0/+30
| | | | | | | | | | | | | The defaults enabled three chains on the AR5416 even if the card has two chains. This restores that and ensures that only the correct TX/RX chainmasks are used. When HT modes are enabled, all TX chains will be correctly enabled. This should now enable analog chain swapping with 2-chain cards. I'm not sure if this is needed for just the AR5416 or whether it also applies to AR9160, AR9280 and AR9287 (later on); I'll have to get clarification.
* Add missing getCapability call for AR5416.adrian2011-01-271-4/+4
|
* Make a note to re-check whether that particular check is needed.adrian2011-01-271-0/+2
|
* Writing to the analog registers on the AR9220 (Merlin PCI) seems to require ↵adrian2011-01-271-0/+9
| | | | | | | | | | | a delay. This, along with an initval change which will appear in a subsequent commit, fixes bus panics that I have been seing with the AR9220 on a Routerstation Pro (AR7161 MIPS board.) Obtained from: Linux ath9k PR: kern/154220
* Explicitly wire the user buffer rather than doing it implicitly inmdf2011-01-271-2/+9
| | | | | | | | sbuf_new_for_sysctl(9). This allows using an sbuf with a SYSCTL_OUT drain for extremely large amounts of data where the caller knows that appropriate references are held, and sleeping is not an issue. Inspired by: rwatson
* Add support for RTL8105E PCIe Fast Ethernet controller. It seemsyongari2011-01-261-1/+7
| | | | | | | | | | | | | | the controller has a kind of embedded controller/memory and vendor applies a large set of magic code via undocumented PHY registers in device initialization stage. I guess it's a firmware image for the embedded controller in RTL8105E since the code is too big compared to other DSP fixups. However I have no idea what that magic code does and what's purpose of the embedded controller. Fortunately driver seems to still work without loading the firmware. While I'm here change device description of RTL810xE controller. H/W donated by: Realtek Semiconductor Corp.
* Add Realtek RTL8201E 10/100 PHY found in RTL8105E controller. Theyongari2011-01-262-0/+2
| | | | | | exact model name is not clear yet. All previous RTL8201 10/100 PHYs used 0x8201 in MII_PHYIDR2 which in turn makes model number 0x20 but this PHY used new model number 0x08.
* Do not use interrupt taskqueue on controllers with MSI/MSI-Xyongari2011-01-261-32/+175
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | capability. One of reason using interrupt taskqueue in re(4) was to reduce number of TX/RX interrupts under load because re(4) controllers have no good TX/RX interrupt moderation mechanism. Basic TX interrupt moderation is done by hardware for most controllers but RX interrupt moderation through undocumented register showed poor RX performance so it was disabled in r215025. Using taskqueue to handle RX interrupt greatly reduced number of interrupts but re(4) consumed all available CPU cycles to run the taskqueue under high TX/RX network load. This can happen even with RTL810x fast ethernet controller and I believe this is not acceptable for most systems. To mitigate the issue, use one-shot timer register to moderate RX interrupts. The timer register provides programmable one-shot timer and can be used to suppress interrupt generation. The timer runs at 125MHZ on PCIe controllers so the minimum time allowed for the timer is 8ns. Data sheet says the register is 32 bits but experimentation shows only lower 13 bits are valid so maximum time that can be programmed is 65.528us. This yields theoretical maximum number of RX interrupts that could be generated per second is about 15260. Combined with TX completion interrupts re(4) shall generate less than 20k interrupts. This number is still slightly high compared to other intelligent ethernet controllers but system is very responsive even under high network load. Introduce sysctl variable dev.re.%d.int_rx_mod that controls amount of time to delay RX interrupt processing in units of us. Value 0 completely disables RX interrupt moderation. To provide old behavior for controllers that have MSI/MSI-X capability, introduce a new tunable hw.re.intr_filter. If the tunable is set to non-zero value, driver will use interrupt taskqueue. The default value of the tunable is 0. This tunable has no effect on controllers that has no MSI/MSI-X capability or if MSI/MSI-X is explicitly disabled by administrator. While I'm here cleanup interrupt setup/teardown since re(4) uses single MSI/MSI-X message at this moment.
* Add missing part of r217877.mav2011-01-261-0/+1
|
* Add ar5416RestoreChainMask() which will undo any AR5416 specific chainmaskadrian2011-01-262-0/+15
| | | | | | | overriding after calibration. This will get set for other two chain radios, such as AR9280 and later on, AR9287. It should however be a nul operation.
* Add an AR5416 workaround - force a different bias based on 2.4ghz channel ↵adrian2011-01-262-0/+67
| | | | | | frequency. Obtained from: Linux ath9k
* Break out the chainmask init code into a new function - ar5416InitChainMasks() .adrian2011-01-262-8/+18
| | | | | | | | | | | ath9k does a few different things here during config - if it's an early AR5416 with two chains, it enables all three chains for calibration and then restores the chainmask to the original values after initial calibration has completed. The reason behind this commit is to begin breaking out the chainmask configuration for this specific reason; follow-up commits will add the chainmask restore in the ar5416Reset() routine.
* * fix HAL_DEBUG_INTERRUPT to be a separate bit, it was overlapping withadrian2011-01-261-1/+2
| | | | | | something else * add HAL_DEBUG_GPIO, for some GPIO related debugging I'm tinkering with at the moment.
* Hardware supported by siis(4) allows software control over activity LEDs.mav2011-01-261-0/+19
| | | | Expose that functionality to led(4) OR-ing it with regular LED activity.
* Remove TX taskqueue and directly invoke re_start in interrupt task.yongari2011-01-251-20/+13
|
* Prefer MSI-X to MSI on controllers that support MSI-X. Allyongari2011-01-251-11/+52
| | | | | | | recent PCIe controllers(RTL8102E or later and RTL8168/8111C or later) supports either 2 or 4 MSI-X messages. Unfortunately vendor did not publicly release RSS related information yet. However switching to MSI-X is one-step forward to support RSS.
* Disable TSO for all Realtek controllers. Experimentation showedyongari2011-01-251-7/+5
| | | | | | | | RTL8111C generated corrupted frames where TCP option header was broken. All other sample controllers I have did not show such problem so it could be RTL8111C specific issue. Because there are too many variants it's hard to tell how many controllers have such issue. Just disable TSO by default but have user override it.
* Bio shall not be accessed after g_io_deliver(9).kib2011-01-251-1/+1
| | | | | | Reported and tested by: pho Reviewed by: ae, phk MFC after: 1 week
* * Re-format the v4k header to be consistentadrian2011-01-251-25/+29
| | | | | | | * Re-do the structure size/component math to make sure the struct matches the expected size * Just to be clear that we care about bitmask ordering, revert my previous change and instead define that macro if we're on big-endian.
* Bring over a fix from ath9k - zero some of the TX descriptors for Kite/AR9285.adrian2011-01-251-0/+14
| | | | | Kite doesn't have per-chain control (it has one chain) or antenna control; so don't try to set those descriptor entries.
* Rename this linux-ism __BIG_ENDIAN_BITFIELD macro to something suitable for ↵adrian2011-01-251-3/+3
| | | | | | FreeBSD. Warner has pointed out that FreeBSD's bit orders follow byte orders.
* Commit updated AR9285 (Kite) v2 initvals from ath9k.adrian2011-01-251-14/+103
|
* Fix the Atheros V4K EEPROM definitions to match those in ath9k.adrian2011-01-252-23/+38
| | | | | | | | | | | | | It turns out that the V4K eeprom definitions (used by the AR9285 and its derivatives) is wrong. These values are at least causing issues on my AR2427. With this fix (and initvals in a subsequent commit), the AR2427 behaves a lot better. Note - there's still significant drift between the ath9k v4k eeprom init code (again, used by AR9285 and derivatives) and what's in this tree. That needs to be investigated and resolved.
* In uart_tty_outwakeup(), check CTS/RTS flow control settings andmarcel2011-01-241-5/+10
| | | | | | | | | | | prevent sending data when CTS is de-asserted. In uart_tty_intr(), call uart_tty_outwakeup() when the CTS signal changed, knowing that uart_tty_outwakeup() will do the right thing for flow control. This avoids redundant conditionals. PR: kern/148644 Submitted by: John Wehle <john@feith.com> MFC after: 3 days
* Reinitialize driver when MTU is changed and driver is running.yongari2011-01-241-1/+3
| | | | Reported by: Huang, Yusheng ( yusheng.huang <> bluecoat com )
* Add more sanity checks for USB_HOST_ALIGN input values. Re-factor existinghselasky2011-01-241-3/+6
| | | | | | checks for readability. Approved by: thompsa (mentor)
* Remove an invalid register setup; this is likely a holdover fromadrian2011-01-241-3/+0
| | | | | the AR5212 code. It doesn't exist in ath9k and I've been told it doesn't exist in the Atheros internal driver.
* ICH7 SATA controller in legacy mode can provide access to SATA registersmav2011-01-241-14/+104
| | | | | | | | via AHCI-like memory resource at BAR(5). Use it if BIOS was so kind to allocate memory for that BAR. This allows hot-plug support and connection speed reporting. MFC after: 2 weeks
* Apply TX interrupt moderation to all RTL810xE PCIe Fast Ethernetyongari2011-01-241-14/+2
| | | | | | | | controllers. Experimentation with RTL8102E, RTL8103E and RTL8105E showed dramatic decrement of TX completion interrupts under high TX load(e.g. from 147k interrupts/second to 10k interrupts/second) With this change, TX interrupt moderation is applied to all controllers except RTL8139C+.
* Enable the 11n PHY by default whether or not 11n is configured.adrian2011-01-231-4/+10
| | | | | | | | | The linux ath9k driver and (from what I've been told) the atheros reference driver does this; it then leaves discarding 11n frames to the 802.11 layer. Whilst I'm here, merge in a fix from ath9k which maintains a turbo register setting when enabling the 11n register; and remove an un-needed (duplicate) flag setting.
* Update the AR9280v2 inivals to match what is in Linux ath9k.adrian2011-01-231-152/+140
| | | | | This repairs the behaviour of my AR9280 - both radio chains now seem to correctly be receiving.
* Revert the ndis part of r212122, windrv_stub.c already adds a MODULE_VERSIONthompsa2011-01-221-1/+0
| | | | | | | | and this breaks loading miniport drivers from loader.conf Reported by: Yuri <yuri^rawbw^com> Submitted by: Paul B Mahol MFC after: 3 days
* Allow USB_HOST_ALIGN to be configured at compile time. This patch ishselasky2011-01-221-0/+5
| | | | | | | | necessary for MIPS based RouterStation Pro board and maybe other MIPS based boards as well. Submitted by: Milan Obuch Approved by: thompsa (mentor)
* Don't bother to run the flowcontrol code if therejfv2011-01-221-1/+5
| | | | is no change. Thanks to Andrew for the tweak.
* Missing case for 82598DA type adapter, thanks Andrew.jfv2011-01-221-0/+3
|
* Leftover bogus TX UNLOCK removed. Thanks tojfv2011-01-211-1/+0
| | | | Andrew Boyer.
* Fix some typos.adrian2011-01-211-3/+3
|
* Add missing getCapability call for AR5416.adrian2011-01-211-0/+1
|
* Modify the v14/v4k eeprom diag interface to return the whole eeprom.adrian2011-01-212-4/+4
| | | | | | The v1 and v3 interfaces returned the whole EEPROM but the v14/v4k interfaces just returned the base header. There's extra information outside of that which would also be nice to get access to.
* ANI changes #1 - split out the ANI polling from the RxMonitor hook.adrian2011-01-2117-31/+111
| | | | | | | | | | The rxmonitor hook is called on each received packet. This can get very, very busy as the tx/rx/chanbusy registers are thus read each time a packet is received. Instead, shuffle out the true per-packet processing which is needed and move the rest of the ANI processing into a periodic event which runs every 100ms by default.
* Correct wrong definition of PM timer mask and adjust L1/PM timeryongari2011-01-202-4/+16
| | | | | | | | | value. While I'm here enable all clocks before initializing controller. This change should fix lockup issue seen on AR8152 v1.1 PCIe Fast Ethernet controller. PR: kern/154076 MFC after: 3 days
* ar9280SetAntennaSwitch() was using the AR5416 chainmasks (3 chains)adrian2011-01-201-2/+2
| | | | rather than the AR9280 chainmasks (2 chains)
* Add another ID for the ZTE MF190 Surf Stickn_hibma2011-01-202-0/+2
| | | | | Submitted by: nagilum MFC after: 1 day
* Only enable 11n modes if the chipset suports 11n.adrian2011-01-201-2/+6
| | | | | Since the AR2427 doesn't allow 802.11n, it shouldn't have them configured.
* Include the device ids for the AR2427.adrian2011-01-202-0/+8
| | | | | | | | This is apparently an AR9285 with the 802.11n specific bits disabled. This code is completely untested; I'm doing this in response to users who wish to test the functionality out. It's likely as buggy as the AR9285 support is in FreeBSD at the moment.
* Push the non-AR5416 related stuff into chipset specific directories.adrian2011-01-2013-13/+13
| | | | | | | | | | sys/dev/ath/ath_hal/ar5416/ is getting very crowded and further commits will make it even more crowded. Now is a good time to shuffle these files out before any more extensive work is done on them. Create an ar9003 directory whilst I'm here; ar9003 specific chipset code will eventually live there.
OpenPOWER on IntegriCloud