Re: [PATCH 3.8 1/3] ath9k_hw: fix calibration issues on chainmask that don't include chain 0

[Wojciech Dubowik <Wojciech.Dubowik@neratec.com>]

On 03/11/2013 07:25 AM, Wojciech Dubowik wrote:
> On 03/08/2013 01:42 PM, Felix Fietkau wrote:
>> On 2013-03-08 10:46 AM, Wojciech Dubowik wrote:
>>> On 03/08/2013 08:44 AM, Wojciech Dubowik wrote:
>>>> On 03/07/2013 04:46 PM, Wojciech Dubowik wrote:
>>>>> On 03/07/2013 03:59 PM, Felix Fietkau wrote:
>>>>>> On 2013-03-07 3:31 PM, Wojciech Dubowik wrote:
>>>>>>> There is a regression introduced by this patch when power save is
>>>>>>> off on
>>>>>>> the station for idle checks.
>>>>>>> I have AR9590 station with rx and tx chain set to 0x1 connected
>>>>>>> to legacy AP (based on Ar9390) with RF cable and 40dB attenuator.
>>>>>>>
>>>>>>> Before this patch in connection polling the station was properly
>>>>>>> sending
>>>>>>> null function to check whether AP is still there. After this patch
>>>>>>> it sends
>>>>>>> broadcast probe request which is anyway wrong or some 16 or so 
>>>>>>> packets
>>>>>>> of random data (rarely). It manifests itself in lost connection
>>>>>>> because
>>>>>>> there
>>>>>>> is no ack from AP which is expected for null function.
>>>>>>>
>>>>>>> I have been following skb's up to the descriptor setting in ath9k
>>>>>>> and it was
>>>>>>> all ok i.e. proper null function with valid addresses.
>>>>>>>
>>>>>>> I have been bisecting it twice because it doesn't make much sense
>>>>>>> but maybe
>>>>>>> it's a HW issue?
>>>>>> You're right, it does not make much sense. I can't figure out how 
>>>>>> this
>>>>>> patch could possibly change the runtime behavior with tx 
>>>>>> chainmask set
>>>>>> to 0x1. Have you tried reverting this patch in a current build to
>>>>>> see if
>>>>>> that fixes the issue?
>>>>> It does fix it. I will check tomorrow whether it's only AR9590 or 
>>>>> also
>>>>> previous revisions. I will also try with different chainmasks. I will
>>>>> have
>>>>> to rescrew my setup...
>>>>>
>>>> I have been doing some tests and it seems to affect both AR9390 and
>>>> AR9590.
>>>> To summarize: sta doesn't send null function but broadcast probe
>>>> request or
>>>> corrupted frames in idle checking routine when power save is off and
>>>> only some
>>>> antennas are selected for transmission.
>>>> So for example when I set antenna mask 7 i.e. all available it works
>>>> ok but with
>>>> mask 1, 3 or 6 not. When I swith power save it's all ok no matter what
>>>> mask I use.
>>>>
>>>> Thing with power save on is that before it goes to idle check it will
>>>> go to sleep since
>>>> there is no traffic anyway, then we get beacon miss, it wakes up and
>>>> it sends null
>>>> function. I guess waking up is reinitializing sth in a chip which
>>>> doesn't occur in my
>>>> scenario.
>>>> HW issue?
>>> It will also work if I set user specified antenna masks instead of hw
>>> capabilities.
>> What do you mean with that? How do you set the rx and tx chainmasks if
>> not via antenna masks? debugfs?
> I do it with iw set antenna.
This could be the solution if you are ok with it.
Wojtek

diff --git a/drivers/net/wireless/ath/ath9k/ar9003_calib.c 
b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
index 4cc1394..58c6256 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
@@ -1023,7 +1023,7 @@ static bool ar9003_hw_init_cal(struct ath_hw *ah,
AR_PHY_AGC_CONTROL_FLTR_CAL   |
AR_PHY_AGC_CONTROL_PKDET_CAL;

-       ar9003_hw_set_chain_masks(ah, ah->caps.rx_chainmask, 
ah->caps.tx_chainmask);
+       ar9003_hw_set_chain_masks(ah, ah->rxchainmask, ah->txchainmask);

         if (rtt) {
                 if (!ar9003_hw_rtt_restore(ah, chan))