diff mbox

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

Message ID 513DA74B.7000205@neratec.com (mailing list archive)
State Not Applicable, archived
Headers show

Commit Message

Wojciech Dubowik March 11, 2013, 9:43 a.m. UTC
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

                 if (!ar9003_hw_rtt_restore(ah, chan))

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Felix Fietkau March 15, 2013, 12:01 a.m. UTC | #1
On 2013-03-11 10:43 AM, Wojciech Dubowik wrote:
> 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);
I will do some testing, but I think this will probably be equivalent to
a revert of the patch.

- Felix

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

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) {