Here are some minor updates for EEPROM, mostly documentation and some small
fixes which have no effect at the moment.
- fixed_bias is not available for B mode.
- AR5K_EEPROM_[RT]X_CHAIN_DIS is 3 bit. this is MIMO and will not be used in
ath5k, but just to be correct.
- AR5K_EEPROM_JAP_MID_EN a
according to the HAL sources the calculation of the Q value is slightly
different for AR5211 chips.
i couldn't test this since IQ calibration never finishes on older parts. this
is a different problem...
Signed-off-by: Bruno Randolf
---
drivers/net/wireless/ath/ath5k/phy.c | 11 +--
1
we read the IQ correction values (i_cal and q_cal) for G mode from a wrong
location (the same shifts as for A mode is applied which is incorrect). use
correct locations, matching the docs and HAL sources.
also we should write IQ correction only when we have that information in the
EEPROM, starting
I/Q calibration was completely broken, resulting in a high number of CRC errors
on received packets. before i could see around 10% to 20% CRC errors, with this
patch they are between 0% and 3%.
1.) the removal of the mask in commit "ath5k: Fix I/Q calibration
(f1cf2dbd0f798b71b1590e7aca6647f2caef1
add a debugfs file to see different RX and TX errors as reported in our status
descriptors. this can help to diagnose driver problems.
statistics can be cleared by writing 'clear' into the frameerrors file.
example:
# cat /sys/kernel/debug/ath5k/phy0/frameerrors
RX
-
CRC
it's never used and we have a newer implementation in gpio.c.
Signed-off-by: Bruno Randolf
---
drivers/net/wireless/ath/ath5k/ath5k.h |2 --
drivers/net/wireless/ath/ath5k/caps.c |3 ---
2 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.
it's not used, and we have ah_mac_srev.
Signed-off-by: Bruno Randolf
---
drivers/net/wireless/ath/ath5k/ath5k.h |1 -
drivers/net/wireless/ath/ath5k/attach.c |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h
b/drivers/net/wirele
it's never used. probably a leftover from the old OpenHAL days...
Signed-off-by: Bruno Randolf
---
drivers/net/wireless/ath/ath5k/ath5k.h |1 -
drivers/net/wireless/ath/ath5k/desc.c |6 --
drivers/net/wireless/ath/ath5k/eeprom.h |3 ---
3 files changed, 0 insertions(+), 10 del
opmode (operating mode) was defined in struct ath5k_hw and struct ath5k_softc.
remove it from ath5k_hw and use only from ath5k_softc (sc->opmode).
(btw: what's the meaning of opmode when we have multiple interfaces?)
Signed-off-by: Bruno Randolf
---
drivers/net/wireless/ath/ath5k/ath5k.h |
keep statistics about which antenna was used for TX and RX. this is used only
for debugging right now, but might have other applications later.
add a new file 'antenna' in debugfs (/sys/kernel/debug/ath5k/phy0/antenna) to
show
antenna use statistics and antenna diversity related register values.
to reset the TSF, AR5K_BEACON_RESET_TSF has to be 1, not 0. also we have a
function for that so use it.
Signed-off-by: Bruno Randolf
---
drivers/net/wireless/ath/ath5k/reset.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/reset.c
b
save antenna settings and preserve across resets.
Signed-off-by: Bruno Randolf
---
drivers/net/wireless/ath/ath5k/attach.c |1 +
drivers/net/wireless/ath/ath5k/base.c |2 +-
drivers/net/wireless/ath/ath5k/phy.c|1 +
3 files changed, 3 insertions(+), 1 deletions(-)
diff --git a
since it must be difficult for john to track all the different revisions of my
patches i send them here again as a clean series.
two of them are new:
ath5k: add debugfs file frameerrors
ath5k: Minor EEPROM documentation updates
others may be slightly updated.
greetings,
bruno
---
Bruno Ran
when using a fixed antenna we should use the antenna number in all tx
descriptors, otherwise the hardware will sometimes send the frame out on the
other antenna. it seems like the hardware does not always respect the default
antenna and diversity settings (esp. AR5K_STA_ID1_DEFAULT_ANTENNA).
also
On Tuesday 09 March 2010 15:45:58 Bob Copeland wrote:
> On Tue, Mar 9, 2010 at 12:56 AM, Bruno Randolf wrote:
> > On Tuesday 09 March 2010 12:32:33 Luis R. Rodriguez wrote:
> >> Perhaps a little more elaboration on the commit log on the impact and
> >> how this helps and how much would help.
> >
On Tue, Mar 9, 2010 at 12:56 AM, Bruno Randolf wrote:
> On Tuesday 09 March 2010 12:32:33 Luis R. Rodriguez wrote:
>> Perhaps a little more elaboration on the commit log on the impact and
>> how this helps and how much would help.
>
> ok. to stop the confusion, i'll add cc: stable.
:) thanks!
FW
I/Q calibration was completely broken, resulting in a high number of CRC errors
on received packets. before i could see around 10% to 20% CRC errors, with this
patch they are between 0% and 3%.
1.) the removal of the mask in commit "ath5k: Fix I/Q calibration
(f1cf2dbd0f798b71b1590e7aca6647f2caef1
On Tuesday 09 March 2010 12:32:33 Luis R. Rodriguez wrote:
> On Mon, Mar 8, 2010 at 7:10 PM, Bob Copeland wrote:
> > On Mon, Mar 8, 2010 at 8:21 PM, Luis R. Rodriguez
wrote:
> >> On Mon, Mar 8, 2010 at 4:50 PM, Bruno Randolf wrote:
> > as i said, in my point of view ath5k has several probl
On Mon, Mar 8, 2010 at 7:10 PM, Bob Copeland wrote:
> On Mon, Mar 8, 2010 at 8:21 PM, Luis R. Rodriguez wrote:
>> On Mon, Mar 8, 2010 at 4:50 PM, Bruno Randolf wrote:
>
> as i said, in my point of view ath5k has several problems right now
> (performace and stability), and i guess nobod
On Mon, Mar 8, 2010 at 8:21 PM, Luis R. Rodriguez wrote:
> On Mon, Mar 8, 2010 at 4:50 PM, Bruno Randolf wrote:
>>> > as i said, in my point of view ath5k has several problems right now
>>> > (performace and stability), and i guess nobody will be using it seriously
>>> > in actual production use
On Mon, Mar 8, 2010 at 4:50 PM, Bruno Randolf wrote:
> On Tuesday 09 March 2010 09:47:09 Luis R. Rodriguez wrote:
>> On Mon, Mar 8, 2010 at 4:34 PM, Bruno Randolf wrote:
>> > On Tuesday 09 March 2010 01:24:48 Luis R. Rodriguez wrote:
>> >> >> Thanks Bruno, are these stable fixes?
>> >> >
>> >> >
On Mon, Mar 8, 2010 at 4:34 PM, Bruno Randolf wrote:
> On Tuesday 09 March 2010 01:24:48 Luis R. Rodriguez wrote:
>> >> Thanks Bruno, are these stable fixes?
>> >
>> > hi luis!
>> >
>> > i think so. the behaviour before was completely broken, now it's better.
>> >
>> > but i'm not sure about that
On Tuesday 09 March 2010 09:47:09 Luis R. Rodriguez wrote:
> On Mon, Mar 8, 2010 at 4:34 PM, Bruno Randolf wrote:
> > On Tuesday 09 March 2010 01:24:48 Luis R. Rodriguez wrote:
> >> >> Thanks Bruno, are these stable fixes?
> >> >
> >> > hi luis!
> >> >
> >> > i think so. the behaviour before was
El 09/03/2010 1:24, Bruno Randolf escribió:
> On Monday 08 March 2010 21:45:55 Jorge Boncompte [DTI2] wrote:
>> El 08/03/2010 3:59, Bruno Randolf escribió:
>>> 4.) we can't use ENABLE_BITS when we want to write a number (the number
>>> can contain zeros). also always write the correction values fir
On Tuesday 09 March 2010 01:24:48 Luis R. Rodriguez wrote:
> >> Thanks Bruno, are these stable fixes?
> >
> > hi luis!
> >
> > i think so. the behaviour before was completely broken, now it's better.
> >
> > but i'm not sure about that whole Cc: sta...@kernel.org thing... (sorry
> > i've been aw
On Monday 08 March 2010 21:45:55 Jorge Boncompte [DTI2] wrote:
> El 08/03/2010 3:59, Bruno Randolf escribió:
> > 4.) we can't use ENABLE_BITS when we want to write a number (the number
> > can contain zeros). also always write the correction values first and
> > set ENABLE bit last, like the HAL do
Johannes Berg a écrit :
> On Sun, 2010-02-28 at 23:08 +0100, Benoit Papillault wrote:
>
>
>> -u64 tsf = ath5k_hw_reg_read(ah, AR5K_TSF_U32);
>> +u32 tsf_lower, tsf_upper;
>> +
>> +/*
>> + * While reading TSF upper and then lower part, the clock is still
>> + * counting so the
On 03/08/2010 12:30 AM, Holger Schurig wrote:
>> i don't know where "Rx invalid nwid", etc. went unfortunately...
>
> To limbo, as it's kind of useless. When you have SSID "BLAH" and receive a
> beacon for SSID "MURPS", it's increasing.
>
> As this doesn't say much that, I don't cry now it's gon
On Sun, Mar 7, 2010 at 8:17 PM, Bruno Randolf wrote:
> On Monday 08 March 2010 12:56:52 Luis R. Rodriguez wrote:
>> On Sun, Mar 7, 2010 at 6:59 PM, Bruno Randolf wrote:
>> > I/Q calibration was completely broken, resulting in a high number of CRC
>> > errors on received packets. before i could se
El 08/03/2010 3:59, Bruno Randolf escribió:
>
> 4.) we can't use ENABLE_BITS when we want to write a number (the number can
> contain zeros). also always write the correction values first and set ENABLE
> bit last, like the HAL does.
>
Hi Bruno,
does not ath5k_hw_commit_eeprom_se
On Sun, 2010-02-28 at 23:08 +0100, Benoit Papillault wrote:
> - u64 tsf = ath5k_hw_reg_read(ah, AR5K_TSF_U32);
> + u32 tsf_lower, tsf_upper;
> +
> + /*
> + * While reading TSF upper and then lower part, the clock is still
> + * counting so the lower part can rollover just aft
> i don't know where "Rx invalid nwid", etc. went unfortunately...
To limbo, as it's kind of useless. When you have SSID "BLAH" and receive a
beacon for SSID "MURPS", it's increasing.
As this doesn't say much that, I don't cry now it's gone. If I really want to
know about beacons, I'm using wir
32 matches
Mail list logo
