An error occurred fetching the project authors.
- 15 Oct, 2010 2 commits
-
-
Felix Fietkau authored
Set the rate table in the rc module properly based on band and HT capabilities instead, which was already partially done, but not for every mode. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Move them to the same debugfs file that the other rc modules use. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 13 Oct, 2010 1 commit
-
-
Mohammed Shafi Shajakhan authored
This fix updates the documenation in Rate Control Table structure Signed-off-by:
Mohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 11 Oct, 2010 1 commit
-
-
Björn Smedman authored
This patch attempts to ensure that ath9k's built-in rate control algorithm does not rely on the value of the ampdu_len and ampdu_ack_len tx status fields unless the IEEE80211_TX_STAT_AMPDU flag is set. This patch has not been tested. Cc: <stable@kernel.org> Signed-off-by:
Björn Smedman <bjorn.smedman@venatech.se> Acked-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 21 Sep, 2010 1 commit
-
-
Felix Fietkau authored
It is not used anywhere else and can be made static Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 27 Jul, 2010 4 commits
-
-
Senthil Balasubramanian authored
base index is not used anymore and so remove it. Signed-off-by:
Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Senthil Balasubramanian authored
The user ratekbs of MCS15 ShortGI is incorrect and can not be lesser than MCS15 rate. This incorrect rate may affect switching to higher rates as the rate control algorithm always finds MCS15 is better than MCS15 ShortGI and results in lower throughput. Fix this by feeding the correct user ratekbs for MCS15 ShortGI rate. This issue affects 3 stream case very badly as the 3 stream rates are not used at all once we scale down to MCS15 from 3 stream rates. Signed-off-by:
Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Senthil Balasubramanian authored
This patch adds 3 stream rate control support for AR938X family chipsets which supports 3 streams. Signed-off-by:
Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Senthil Balasubramanian authored
replace valid and valid_single_stream in rate table with bit masks and reorganize the code so adding 3x3 rate control would be easier. Signed-off-by:
Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 14 Jun, 2010 1 commit
-
-
Felix Fietkau authored
mac80211 already masks the HT sta capabilities based on hardware support Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 04 Jun, 2010 1 commit
-
-
Vasanthakumar Thiagarajan authored
The following commit added an entry in 11na and 11ng rate table but missed to update its rate count field. This inconsistency between the rate count and the actual number of rates in the table will leave out the final rate entry (mcs15 with half gi in ht40) while forming the valid rate indices. Not having mcs15+shortGI in ht40 will have a performance impact (on max throughput) of about 10% both in nght40 and naht40 mode. Author: Vasanthakumar Thiagarajan <vasanth@atheros.com> Date: Thu May 13 18:42:38 2010 -0700 ath9k: Enable Short GI in 20 Mhz for ar9287 and later chips This patch enables short GI rx at all rates and tx at mcs15 for 20 Mhz channel width also. Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 02 Jun, 2010 1 commit
-
-
Vasanthakumar Thiagarajan authored
This patch enables short GI rx at all rates and tx at mcs15 for 20 Mhz channel width also. Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 20 Apr, 2010 1 commit
-
-
Felix Fietkau authored
Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 16 Apr, 2010 1 commit
-
-
Luis R. Rodriguez authored
LDPC is enabled by the rate control if the its determined that the target peer supports LDPC. We would have already intersected the HT capabilities so if our peer supports LDPC so do we. Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 30 Mar, 2010 1 commit
-
-
Tejun Heo authored
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by:
Tejun Heo <tj@kernel.org> Guess-its-ok-by:
Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
-
- 10 Mar, 2010 1 commit
-
-
Felix Fietkau authored
Currently the rate control tx status update gets called for every subframe of an A-MPDU, and ath9k marks the frame with the relevant status update with an internal flag. This not suitable for rate control algorithms using the standard mac80211 rate control API, so fix this by using IEEE80211_TX_STAT_AMPDU for marking the correct frames that should be processed. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 03 Mar, 2010 1 commit
-
-
Sujith authored
Handling HT configuration changes involved setting the channel with the new HT parameters and then issuing a rate_update() notification to the driver. This behavior changed after the off-channel changes. Now, the channel is not updated with the new HT params in enable_ht() - instead, it is now done when the scan work terminates. This results in the driver depending on stale information, defaulting to non-HT mode always. Fix this by passing the new channel type to the driver. Cc: stable@kernel.org Signed-off-by:
Sujith <Sujith.Manoharan@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 19 Feb, 2010 1 commit
-
-
Felix Fietkau authored
When selecting the tx fallback rate, rc.c used a separate variable 'nrix' for storing the next rate index, however it did not use that as reference for further rate index lowering. Because of that, it ended up reusing the same rate for multiple multi-rate retry stages, thus decreasing delivery probability under changing link conditions. This patch removes the separate (unnecessary) variable and fixes fallback the way it was intended to work. This should result in increased throughput and better link stability. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Cc: stable@kernel.org Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 25 Jan, 2010 1 commit
-
-
Felix Fietkau authored
ath9k currently forces hw->max_rate_tries to 4 to work around rate control inefficiencies. This has some negative side effects, such as rate_control_send_low also using a maximum of 4 tries, which could negatively affect reliability of unicast management frames. This patch pushes the retry limit to the rate control instead, and allows it to use more tries on the last stage to prevent unnecessary packet loss. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 04 Dec, 2009 1 commit
-
-
André Goddard Rosa authored
That is "success", "unknown", "through", "performance", "[re|un]mapping" , "access", "default", "reasonable", "[con]currently", "temperature" , "channel", "[un]used", "application", "example","hierarchy", "therefore" , "[over|under]flow", "contiguous", "threshold", "enough" and others. Signed-off-by:
André Goddard Rosa <andre.goddard@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz>
-
- 28 Nov, 2009 3 commits
-
-
Luis R. Rodriguez authored
Atheros single stream AR9285 and AR9271 have half the PCU TX FIFO buffer size of that of dual stream devices. Dual stream devices have a max PCU TX FIFO size of 8 KB while single stream devices have 4 KB. Single stream devices have an issue though and require hardware only to use half of the amount of its capable PCU TX FIFO size, 2 KB and this requires a change in software. Technically a change would not have been required (except for frame burst considerations of 128 bytes) if these devices would have been able to use the full 4 KB of the PCU TX FIFO size but our systems engineers recommend 2 KB to be used only. We enforce this through software by reducing the max frame triggger level to 2 KB. Fixing the max frame trigger level should then have a few benefits: * The PER will now be adjusted as designed for underruns when the max trigger level is reached. This should help alleviate the bus as the rate control algorithm chooses a slower rate which should ensure frames are transmitted properly under high system bus load. * The poll we use on our TX queues should now trigger and work as designed for single stream devices. The hardware passes data from each TX queue on the PCU TX FIFO queue respecting each queue's priority. The new trigger level ensures this seeding of the PCU TX FIFO queue occurs as designed which could mean avoiding false resets and actually reseting hw correctly when a TX queue is indeed stuck. * Some undocumented / unsupported behaviour could have been triggered when the max trigger level level was being set to 4 KB on single stream devices. Its not clear what this issue was to me yet. Cc: Kyungwan Nam <kyungwan.nam@atheros.com> Cc: Bennyam Malavazi <bennyam.malavazi@atheros.com> Cc: Stephen Chen <stephen.chen@atheros.com> Cc: Shan Palanisamy <shan.palanisamy@atheros.com> Cc: Paul Shaw <paul.shaw@atheros.com> Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
Remove some fields from struct ath_rate_table that are now unused. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
This patch changes ath9k to pass proper MCS indexes and flags between the RC and the rest of the driver code. sc->cur_rate_table remains, as it's used by the RC code internally, but the rest of the driver code no longer uses it, so a potential new RC for ath9k would not have to update it. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 18 Nov, 2009 2 commits
-
-
Johannes Berg authored
The entire aggregation code currently operates on the hw pointer and station addresses, but that needs to change to make stations purely per-vif; As one step preparing for that make the aggregation code callable with the station, or by the combination of virtual interface and station address. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Felix Fietkau authored
This patch removes the need for separately allocated private tx info data in ath9k and brings the driver one small step closer to using the mac80211 rate control API properly. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 30 Oct, 2009 1 commit
-
-
Luis R. Rodriguez authored
The patch e43419f9: ath9k: downgrade assert in rc.c for invalid rate downgraded an ASSERT to a WARN_ON() but also misplaced a semicolon at the end of the second check. What this did was force the rate control code to always return the rate even if we should have warned about it. Since this should not have happened anymore anyway this fix isn't critical as the proper rate would have been returned anyway. Cc: stable@kernel.org Reported-by:
Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 07 Oct, 2009 3 commits
-
-
Luis R. Rodriguez authored
Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
ath9k uses this for now, ath9k_htc is expected to re-use this as well. We lave ath5k as is, but it certainly can also be converted later. The ath9k module parameter and debugfs entry is kept. Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
DPRINTF() is used in hw specific related code, as such ensure we don't rely on the private driver core ath_softc struct when calling it. Drivers can then implement their own DPRINTF() as they see fit. Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 04 Aug, 2009 2 commits
-
-
Vasanthakumar Thiagarajan authored
Monotonicity of packet error rate should be kept when moving from one phy to another (legacy to ht, ht single stream to dual, etc). Current code skips updating per for other phys. Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Vasanthakumar Thiagarajan authored
Now the lowest rate in 11na ht40 mode is 13.5Mbps this shortens the range when compared to 11na ht20 mode where the lowest rate is 6.5Mbps. To improve the range, make 6.5Mbps as the lowest rate in 11na ht40 mode, this improves the range by approximately 2dB. 11ng ht40 does not have this issue as it also has basic rates (1, 2, 5.5 and 11). Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 24 Jul, 2009 9 commits
-
-
Vasanthakumar Thiagarajan authored
Move its only member (u8 per) to struct ath_rate_priv. Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Vasanthakumar Thiagarajan authored
Get rid of rssi reduce interval. Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Vasanthakumar Thiagarajan authored
Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Vasanthakumar Thiagarajan authored
ath9k rate control is based on only PER (packet error rate), remove unused code which was intented to do rssi based rate selection. Signed-off-by:
Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
After the cleanup we just use get_rate as a wrapper, skip the wrapper. Cc: Derek Smithies <derek@indranet.co.nz> Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com> Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
All current rate control algorithms agree to send management and no-ack frames at the lowest rate. They also agree to do this when sta and the private rate control data is NULL. We add a hlper to mac80211 for this and simplify the rate control algorithm code. Developers wishing to make enhancements to rate control algorithms are for broadcast/multicast can opt to not use this in their gate_rate() mac80211 callback. Cc: Zhu Yi <yi.zhu@intel.com> Acked-by:
Reinette Chatre <reinette.chatre@intel.com> Cc: ipw3945-devel@lists.sourceforge.net Cc: Gabor Juhos <juhosg@openwrt.org> Acked-by:
Felix Fietkau <nbd@openwrt.org> Cc: Derek Smithies <derek@indranet.co.nz> Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com> Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
We check for this condition early on in our mac80211 get_rate() callback ath_get_rate(), so remove this check later down the path. Cc: Derek Smithies <derek@indranet.co.nz> Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com> Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
The purpose is to find the highest rate we can use. Cc: Derek Smithies <derek@indranet.co.nz> Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com> Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
This saves us 2733 bytes. text data bss dec hex filename 252265 3628 1584 257477 3edc5 ath9k-has-b-rate.ko 249905 3628 1584 255117 3e48d ath9k.ko Cc: Derek Smithies <derek@indranet.co.nz> Cc: Chittajit Mitra <Chittajit.Mitra@Atheros.com> Siged-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-