| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
frequency.
Obtained from: Linux ath9k
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
something else
* add HAL_DEBUG_GPIO, for some GPIO related debugging I'm tinkering with
at the moment.
|
|
|
|
| |
Expose that functionality to led(4) OR-ing it with regular LED activity.
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Reported and tested by: pho
Reviewed by: ae, phk
MFC after: 1 week
|
|
|
|
|
|
|
| |
* 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.
|
|
|
|
|
| |
Kite doesn't have per-chain control (it has one chain) or antenna control; so
don't try to set those descriptor entries.
|
|
|
|
|
|
| |
FreeBSD.
Warner has pointed out that FreeBSD's bit orders follow byte orders.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Reported by: Huang, Yusheng ( yusheng.huang <> bluecoat com )
|
|
|
|
|
|
| |
checks for readability.
Approved by: thompsa (mentor)
|
|
|
|
|
| |
the AR5212 code. It doesn't exist in ath9k and I've been told it
doesn't exist in the Atheros internal driver.
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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+.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This repairs the behaviour of my AR9280 - both radio chains now seem
to correctly be receiving.
|
|
|
|
|
|
|
|
| |
and this breaks loading miniport drivers from loader.conf
Reported by: Yuri <yuri^rawbw^com>
Submitted by: Paul B Mahol
MFC after: 3 days
|
|
|
|
|
|
|
|
| |
necessary for MIPS based RouterStation Pro board and maybe other MIPS
based boards as well.
Submitted by: Milan Obuch
Approved by: thompsa (mentor)
|
|
|
|
| |
is no change. Thanks to Andrew for the tweak.
|
| |
|
|
|
|
| |
Andrew Boyer.
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
rather than the AR9280 chainmasks (2 chains)
|
|
|
|
|
| |
Submitted by: nagilum
MFC after: 1 day
|
|
|
|
|
| |
Since the AR2427 doesn't allow 802.11n, it shouldn't have them
configured.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
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.
|