[ath9k-devel] ath9k: Deaf QCA9558 when setting rxchainmask

Discussion:

Sven Eckelmann

2013-11-06 15:04:25 UTC

Hi,

I've needed to test some problems with a QCA9558 Rev 0 based 3x3 2.4G device.
During these tests I've wanted to try different antenna configurations to
reduce the complexity of the problem. This was done by setting the
rxchainmask/txchainsmask to settings like 1, 5 and 7. Unfortunatelly, the
setting 5 (antenna 0 and 1) turned the device completely deaf. Here an
overview of the settings (excerpt)

chainmask | ant 0 | ant 1 | ant 2 | Status
1 | 1 | 0 | 0 | works
5 | 1 | 0 | 1 | deaf
7 | 1 | 1 | 1 | works

The antenna setting is used in ath9k at different places but trigger seems to
be the AR_PHY_RX_CHAINMASK register write in ar9003_phy.c in the function
ar9003_hw_set_chain_masks. Forcing it to 7 instead of the requested 5 avoids
this deaf state (but makes the rx chainmask setting useless). Of course, this
is not a valid workaround and quite unexpected.

The test platform was a current trunk OpenWrt build together with compat-
wireless 2013-02-22, compat-wireless 2013-06-27 and backports 2013-10-31. The
settings were configured using the txantenna and rxantenna of the OpenWrt
wireless config system. Both were always set to the same values during the
tests.

The deaf state was identified using 1x1 and 2x2 clients which could receive
the beacons of the device. The QCA9558 device was then unable to receive the
probe request from the clients or any other traffic on the air. This was also
checked by a monitor (flags: control) interface on the same phy.

Maybe someone knows whether this is a known problem with this SoC or what
information can be gathered to debug this problem further.

Kind regards,
Sven

Julius Schulz-Zander

2013-11-09 00:32:25 UTC

Permalink

Hi Sven,

I've asked nbd about this some time ago. It doesn't work if you have gaps in the chain mask! Try chain mask 3 (110) and it should work with 2x2.

Regards,
-Julius

Post by Sven Eckelmann
Hi,
I've needed to test some problems with a QCA9558 Rev 0 based 3x3 2.4G device.
During these tests I've wanted to try different antenna configurations to
reduce the complexity of the problem. This was done by setting the
rxchainmask/txchainsmask to settings like 1, 5 and 7. Unfortunatelly, the
setting 5 (antenna 0 and 1) turned the device completely deaf. Here an
overview of the settings (excerpt)
chainmask | ant 0 | ant 1 | ant 2 | Status
1 | 1 | 0 | 0 | works
5 | 1 | 0 | 1 | deaf
7 | 1 | 1 | 1 | works
The antenna setting is used in ath9k at different places but trigger seems to
be the AR_PHY_RX_CHAINMASK register write in ar9003_phy.c in the function
ar9003_hw_set_chain_masks. Forcing it to 7 instead of the requested 5 avoids
this deaf state (but makes the rx chainmask setting useless). Of course, this
is not a valid workaround and quite unexpected.
The test platform was a current trunk OpenWrt build together with compat-
wireless 2013-02-22, compat-wireless 2013-06-27 and backports 2013-10-31. The
settings were configured using the txantenna and rxantenna of the OpenWrt
wireless config system. Both were always set to the same values during the
tests.
The deaf state was identified using 1x1 and 2x2 clients which could receive
the beacons of the device. The QCA9558 device was then unable to receive the
probe request from the clients or any other traffic on the air. This was also
checked by a monitor (flags: control) interface on the same phy.
Maybe someone knows whether this is a known problem with this SoC or what
information can be gathered to debug this problem further.
Kind regards,
Sven
_______________________________________________
ath9k-devel mailing list
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Adrian Chadd

2013-11-09 02:33:19 UTC

Permalink

Hm, is the 0x5 chainmask triggering the ALT_CHAIN logic?

What are you trying to do? Control the receive antenna config, or the
transmit antenna config?

-a

On 8 November 2013 16:32, Julius Schulz-Zander

Post by Julius Schulz-Zander
Hi Sven,
I've asked nbd about this some time ago. It doesn't work if you have gaps in the chain mask! Try chain mask 3 (110) and it should work with 2x2.
Regards,
-Julius

_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Alex Hacker

2013-11-11 08:33:04 UTC

Permalink

Hello,
Some combinations of masks is restricted for AR92xx series.
See the ar9003_hw_set_chain_masks(), it allows any value for rx/tx chain masks
for AR93xx chips. It is claimed the QCA9558 should support it at least at HW
level.
Alex.

Sven Eckelmann

2013-11-11 09:36:52 UTC

Permalink

Post by Adrian Chadd
Hm, is the 0x5 chainmask triggering the ALT_CHAIN logic?

You are talking about ar9003_phy.c -> ar9003_hw_set_chain_masks? No, the
device is 3x3 and ah->caps.tx_chainmask & ah->caps.rx_chainmask are 7 and not
5. The AR_PHY_ANALOG_SWAP := AR_PHY_SWAP_ALT_CHAIN is only done when one of
them would be 5. But I am not really sure what this register setting is really
doing. Maybe you can explain it when you think it could be related. Thanks

Post by Adrian Chadd
What are you trying to do? Control the receive antenna config, or the
transmit antenna config?

I have a device which is using a QCA9558 3x3 and a AR93XX 3x3 device. Both are
working fine with the proprietary atheros driver and a 2x2 device as client
(Intel and Atheros). The used driver is a a binary blob of 9.5.3.15
(Atheros/multi-bss). But the download rate (AP -> Client) is relative low when
using ath9k and the QCA9558 for tx. It is quite good when using the AR93XX.

The bad TX seems to be related to the low ewma prop for MCS14/15 in an 1-4.5m
test (HT20). One idea was to test the different antennas to check whether
there is some kind of antenna (selection) related problem. Unfortunatelly,
this test only caused the problem mentioned in this thread.

Kind regards,
Sven

Sujith Manoharan

2013-11-11 13:58:40 UTC

Permalink

Post by Sven Eckelmann
You are talking about ar9003_phy.c -> ar9003_hw_set_chain_masks? No, the
device is 3x3 and ah->caps.tx_chainmask & ah->caps.rx_chainmask are 7 and not
5. The AR_PHY_ANALOG_SWAP := AR_PHY_SWAP_ALT_CHAIN is only done when one of
them would be 5. But I am not really sure what this register setting is really
doing. Maybe you can explain it when you think it could be related. Thanks

"0x5" chainmask is an invalid mask for AR9300 - for all revisions, including AR9580.

If a 2-stream card is required based on AR9300 for custom designs, the only
way is to use Chain 0 and Chain 2, since there are HW limitations with Chain 1.
In this case, a chainmask of 0x7 has to be used and the middle chain disabled in the
driver. This is done by a few vendors who use the 5Ghz AR9580 radio but want 2x2
instead of the usual 3x3.

Sujith

Alex Hacker

2013-11-12 07:12:32 UTC

Permalink

Thank you Sujith. Probably I understood the following patch in a wrong way.
Felix removed all chain masks checking. If the mask 5 is invalid, how about
the mask 4 and 6?
Regards,
Alex

commit 24171dd92096fc370b195f3f6bdc0798855dc3f9
Author: Felix Fietkau <***@openwrt.org>
Date: Sun Jan 20 21:55:21 2013 +0100

ath9k_hw: fix chain swap setting when setting rx chainmask to 5

Chain swapping should only be enabled when the EEPROM chainmask is set to 5,
regardless of what the runtime chainmask is.

Cc: ***@vger.kernel.org
Signed-off-by: Felix Fietkau <***@openwrt.org>
Signed-off-by: John W. Linville <***@tuxdriver.com>

diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index 8290edd..3afc24b 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -588,30 +588,17 @@ static void ar9003_hw_init_bb(struct ath_hw *ah,

void ar9003_hw_set_chain_masks(struct ath_hw *ah, u8 rx, u8 tx)
{
- switch (rx) {
- case 0x5:
+ if (ah->caps.tx_chainmask == 5 || ah->caps.rx_chainmask == 5)
REG_SET_BIT(ah, AR_PHY_ANALOG_SWAP,
AR_PHY_SWAP_ALT_CHAIN);
- case 0x3:
- case 0x1:
- case 0x2:
- case 0x7:
- REG_WRITE(ah, AR_PHY_RX_CHAINMASK, rx);
- REG_WRITE(ah, AR_PHY_CAL_CHAINMASK, rx);
- break;
- default:
- break;
- }
+
+ REG_WRITE(ah, AR_PHY_RX_CHAINMASK, rx);
+ REG_WRITE(ah, AR_PHY_CAL_CHAINMASK, rx);

if ((ah->caps.hw_caps & ATH9K_HW_CAP_APM) && (tx == 0x7))
- REG_WRITE(ah, AR_SELFGEN_MASK, 0x3);
- else
- REG_WRITE(ah, AR_SELFGEN_MASK, tx);
+ tx = 3;

- if (tx == 0x5) {
- REG_SET_BIT(ah, AR_PHY_ANALOG_SWAP,
- AR_PHY_SWAP_ALT_CHAIN);
- }
+ REG_WRITE(ah, AR_SELFGEN_MASK, tx);
}

/*

Sujith Manoharan

2013-11-14 08:39:31 UTC

Permalink

Post by Alex Hacker
Thank you Sujith. Probably I understood the following patch in a wrong way.
Felix removed all chain masks checking. If the mask 5 is invalid, how about
the mask 4 and 6?

The patch is correct. For calibration, the mask that is calibrated in
the EEPROM has to be used. Even if you change the mask config dynamically,
either using the antenna API or ath9k's debugs, it will be disregarded
when calibration is done.

Sujith

Matthias May

2013-11-18 13:00:41 UTC

Permalink

Post by Sujith Manoharan

"0x5" chainmask is an invalid mask for AR9300 - for all revisions, including AR9580.
If a 2-stream card is required based on AR9300 for custom designs, the only
way is to use Chain 0 and Chain 2, since there are HW limitations with Chain 1.
In this case, a chainmask of 0x7 has to be used and the middle chain disabled in the
driver. This is done by a few vendors who use the 5Ghz AR9580 radio but want 2x2
instead of the usual 3x3.
Sujith
_______________________________________________
ath9k-devel mailing list
https://lists.ath9k.org/mailman/listinfo/ath9k-devel

Hi Sujith
I'm in the position where i want to use a 9390 as 2x2 instead of 3x3.
I use backports-3.12-1.
I've set the rx and tx mask in eeprom to 0x5.
Every 30 seconds there is a short disconnect.
Enabling some logging in
echo "0x0000050C" > /sys/kernel/debug/ieee80211/phy0/ath9k/debug
shows that something seems to go wrong during noise calibration. (See
attached log).
What seems odd to me, that for IQ cal it tries to calibrate chain 1
instead of chain 2.

Best regards
Matthias May
--
Matthias May
Software Engineer

Neratec Solutions AG
Postfach 83, CH-8608 Bubikon, Switzerland
Direct: +41 55 253 2074
Office: +41 55 253 2000
Fax: +41 55 253 2070
email: ***@neratec.com
Web: www.neratec.com

Sujith Manoharan

2013-11-18 13:12:41 UTC

Permalink

Post by Matthias May
I'm in the position where i want to use a 9390 as 2x2 instead of 3x3.
I use backports-3.12-1.
I've set the rx and tx mask in eeprom to 0x5.
Every 30 seconds there is a short disconnect.
Enabling some logging in
echo "0x0000050C" > /sys/kernel/debug/ieee80211/phy0/ath9k/debug
shows that something seems to go wrong during noise calibration. (See
attached log).
What seems odd to me, that for IQ cal it tries to calibrate chain 1
instead of chain 2.

What is the value of 0x40d8 register ?

echo 0x40d8 > /sys/kernel/debug/ieee80211/phy0/ath9k/regidx
cat /sys/kernel/debug/ieee80211/phy0/ath9k/regval

Sujith

Matthias May

2013-11-18 13:36:42 UTC

Permalink

Post by Sujith Manoharan

What is the value of 0x40d8 register ?
echo 0x40d8 > /sys/kernel/debug/ieee80211/phy0/ath9k/regidx
cat /sys/kernel/debug/ieee80211/phy0/ath9k/regval
Sujith

***@CHD500279:/# echo 0x40d8 >
/sys/kernel/debug/ieee80211/phy6/ath9k/regidx
***@CHD500279:/# cat /sys/kernel/debug/ieee80211/phy6/ath9k/regval
0x00000004

On another device showing the same behaviour (but with various other
patches and based on compat-wireless-2013-06-27) 0x04000004.

Best regards
Matthias May
--
Matthias May
Software Engineer

Neratec Solutions AG
Postfach 83, CH-8608 Bubikon, Switzerland
Direct: +41 55 253 2074
Office: +41 55 253 2000
Fax: +41 55 253 2070
email: ***@neratec.com
Web: www.neratec.com

Sujith Manoharan

2013-11-18 15:05:38 UTC

Permalink

Post by Matthias May
/sys/kernel/debug/ieee80211/phy6/ath9k/regidx
0x00000004
On another device showing the same behaviour (but with various other
patches and based on compat-wireless-2013-06-27) 0x04000004.

This commit removed code from the driver which handled
a quirk that is probably required for the enterprise variants.

Felix, we do require the code that handles AR_ENT_OTP_CHAIN2_DISABLE, right ?

commit 56266bff6df685d9c26d08904ae1d43bad162539
Author: Rajkumar Manoharan <***@qca.qualcomm.com>
Date: Sat Aug 13 10:28:13 2011 +0530

ath9k_hw: Remove unnecessary chainmask configuration

The chainmasks were already configured at process_ini
before doing init calibration.

Sujith

Sujith Manoharan

2013-11-18 14:52:45 UTC

Permalink

Post by Matthias May
I'm in the position where i want to use a 9390 as 2x2 instead of 3x3.
I use backports-3.12-1.
I've set the rx and tx mask in eeprom to 0x5.

0x5 is not a valid chainmask on AR9390. The official statement is:

"We intentionally didn’t productize the chain mask of 0x5 on AR9380/AR9580
because of the complexities of register addressing and getting through the ASIC
self-calibrations in this configuration."

I think for 2x2 operation, 0x3 is the only option. The problem with Chain-1
(which was mentioned in http://www.spinics.net/lists/linux-wireless/msg114607.html)
is probably for a specific board. So maybe you can just set 0x3 using iw and
see if things are okay.

Post by Matthias May
Nov 18 13:39:45 CHD500279 kernel: [16510.563694] ath: phy11: NF calibrated [ctl] [chain 0] is -105
Nov 18 13:39:45 CHD500279 kernel: [16510.563698] ath: phy11: NF calibrated [ctl] [chain 2] is -50
Nov 18 13:39:45 CHD500279 kernel: [16510.563701] ath: phy11: NF[2] (-50) > MAX (-100), correcting to MAX
Nov 18 13:39:45 CHD500279 kernel: [16510.563705] ath: phy11: NF calibrated [ext] [chain 0] is -105
Nov 18 13:39:45 CHD500279 kernel: [16510.563708] ath: phy11: NF calibrated [ext] [chain 2] is -50
Nov 18 13:39:45 CHD500279 kernel: [16510.563712] ath: phy11: NF[5] (-50) > MAX (-100), correcting to MAX

Again, this is the side effect of using the unsupported mask, 0x5.

But, this is also a bug in ath9k. Right now the CCA registers assigned
in ar9003_hw_attach_phy_ops() are used in a sequential manner.

But, as per our systems engineers:

AR_PHY_CCA_0 - for 1st active chain, (value always valid).
AR_PHY_CCA_1 - for 2nd active chain, (value should be ignored except for chain mask 3,5,7).
AR_PHY_CCA_2 - for 3rd active chain, (value should be ignored except for chain mask 7).

So, if 0x5 is used, AR_PHY_CCA_0 and AR_PHY_CCA_1 should be used.
But, ath9k currently uses AR_PHY_CCA_0 and AR_PHY_CCA_2 for 0x5
(in ar9003_hw_do_getnf).

In any case, I don't think this needs to be fixed, since 0x5 is invalid.

Sujith