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
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
On 06.11.2013, at 16:04, Sven Eckelmann <[email protected]> wrote:
> 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
> [email protected]
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
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 <[email protected]>
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: [email protected]
Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
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);
}
/*
Alex Hacker wrote:
> 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 wrote:
> root@CHD500279:/# echo 0x40d8 >
> /sys/kernel/debug/ieee80211/phy6/ath9k/regidx
> root@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.
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 <[email protected]>
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
On 11/11/13 14:58, Sujith Manoharan wrote:
> Sven Eckelmann wrote:
>> 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
> _______________________________________________
> ath9k-devel mailing list
> [email protected]
> 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: [email protected]
Web: http://www.neratec.com
Matthias May wrote:
> 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.
> 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
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
<[email protected]> wrote:
> 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
>
> On 06.11.2013, at 16:04, Sven Eckelmann <[email protected]> wrote:
>
>> 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
>> [email protected]
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> _______________________________________________
> openwrt-devel mailing list
> [email protected]
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
On 18/11/13 14:12, Sujith Manoharan wrote:
> Matthias May wrote:
>> 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
root@CHD500279:/# echo 0x40d8 >
/sys/kernel/debug/ieee80211/phy6/ath9k/regidx
root@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: [email protected]
Web: http://www.neratec.com
Matthias May wrote:
> 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
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.
On Friday 08 November 2013 18:33:19 Adrian Chadd wrote:
> 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
> 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
Sven Eckelmann wrote:
> 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