The interrupt is no longer handling it. While it shouldn't fire (wraparound
is highly unlikely), the consequences would be fatal (interrupt storm).
Disable the interrupt to prevent that from happening.
Signed-off-by: Felix Fietkau <[email protected]>
---
drivers/net/wireless/ath/ath9k/hw.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 60b6a9d..d95474e 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -978,9 +978,6 @@ static void ath9k_hw_init_interrupt_masks(struct ath_hw *ah,
else
imr_reg |= AR_IMR_TXOK;
- if (opmode == NL80211_IFTYPE_AP)
- imr_reg |= AR_IMR_MIB;
-
ENABLE_REGWRITE_BUFFER(ah);
REG_WRITE(ah, AR_IMR, imr_reg);
--
1.7.9.6 (Apple Git-31.1)
Hi Felix,
On Wed, Aug 8, 2012 at 8:42 PM, Felix Fietkau <[email protected]> wrote:
> On 2012-08-08 4:55 PM, Rajkumar Manoharan wrote:
>> On Tue, Aug 07, 2012 at 03:06:12PM +0200, Felix Fietkau wrote:
>>> This feature had been disabled in ath9k because the code to support
>>> it was incomplete, but now the code is in sync with the internal QCA
>>> codebase, so it's time to enable it.
>>>
>>> On many newer devices, the calibration is assumed to be done with PA
>>> linearization enabled.
>>>
>>> Tests with a particular AR933x device showed that the signal emitted
>>> at full power was highly distorted and unreliable with PA linearization
>>> disabled. With this patch, the signal becomes clear and stability
>>> is improved.
>>>
>> We faced stability issues with 938x chipsets when paprd is enabled. The commit
>> 6f4810101a629b31b5427872a09ea092cfc5c4bd states one of the issue. Even if it
>> helps for AR933x, let us enable it only for that chip alone.
> That was in January 2011, lots of bugs have been fixed since then,
> initvals have been updated, EEPROM code has changed, ...
>
> The internal QCA codebase enables PAPRD for all AR93xx devices that
> support it, meaning non-PAPRD tx receives much less test coverage there.
>
> While this issue has only been visible on a particular AR933x device, I
> believe this is not the only one that's going to be affected, as the
> EEPROM of any new device is calibrated for PAPRD-enabled operation.
>
> If you don't want to enable it now, when do you think would be the right
> time to enable it? Before I sent this patch, I did a detailed code
> review to make sure that any obvious code discrepancies in PAPRD between
> the internal codebase and ath9k are dealt with.
>
> What else is needed to get this issue sorted out?
>
i was working on PAPRD for sometime to ensure that it provides a
consistent throughput improvement in all the rates.
After some amount of testing where i was able to show it gave a
considerable throughput improvement in particular
MCS rates/particular attenuation only(in the shielded box, varying
the attenuation) and i thought/asked for enabling
PAPRD. With the open air and with other even in the shielded
environment I could not show any consistent improvement in all
attenuation. Infact there are some cases where it proved detrimental
to the actual throughput, because of some bugs i suppose. Even with
our internal code base i saw there are few work arounds to disable it
if the PAPRD fails(PAPRD curve ?) and few more issues cropped up
because of this feature. We throw in the towel and stopped tracking
the changes. But i am not sure of its current status and its effects
in our internal code base. As Raj had suggested we can validate the
bug in commit id
6f4810101a629b31b5427872a09ea092cfc5c4bd. thanks!
--
thanks,
shafi
On Wed, Aug 08, 2012 at 05:12:25PM +0200, Felix Fietkau wrote:
> On 2012-08-08 4:55 PM, Rajkumar Manoharan wrote:
> > On Tue, Aug 07, 2012 at 03:06:12PM +0200, Felix Fietkau wrote:
> >> This feature had been disabled in ath9k because the code to support
> >> it was incomplete, but now the code is in sync with the internal QCA
> >> codebase, so it's time to enable it.
> >>
> >> On many newer devices, the calibration is assumed to be done with PA
> >> linearization enabled.
> >>
> >> Tests with a particular AR933x device showed that the signal emitted
> >> at full power was highly distorted and unreliable with PA linearization
> >> disabled. With this patch, the signal becomes clear and stability
> >> is improved.
> >>
> > We faced stability issues with 938x chipsets when paprd is enabled. The commit
> > 6f4810101a629b31b5427872a09ea092cfc5c4bd states one of the issue. Even if it
> > helps for AR933x, let us enable it only for that chip alone.
> That was in January 2011, lots of bugs have been fixed since then,
> initvals have been updated, EEPROM code has changed, ...
>
> The internal QCA codebase enables PAPRD for all AR93xx devices that
> support it, meaning non-PAPRD tx receives much less test coverage there.
>
> While this issue has only been visible on a particular AR933x device, I
> believe this is not the only one that's going to be affected, as the
> EEPROM of any new device is calibrated for PAPRD-enabled operation.
>
> If you don't want to enable it now, when do you think would be the right
> time to enable it? Before I sent this patch, I did a detailed code
> review to make sure that any obvious code discrepancies in PAPRD between
> the internal codebase and ath9k are dealt with.
>
> What else is needed to get this issue sorted out?
>
Yes. it was disabled a long time back. Im completely fine with enabling the
feature. I want to make sure that we should not endup again with the same issues.
Atleast we should validite the one mentioned in the commit
6f4810101a629b31b5427872a09ea092cfc5c4bd
-Rajkumar
On 2012-08-08 4:55 PM, Rajkumar Manoharan wrote:
> On Tue, Aug 07, 2012 at 03:06:12PM +0200, Felix Fietkau wrote:
>> This feature had been disabled in ath9k because the code to support
>> it was incomplete, but now the code is in sync with the internal QCA
>> codebase, so it's time to enable it.
>>
>> On many newer devices, the calibration is assumed to be done with PA
>> linearization enabled.
>>
>> Tests with a particular AR933x device showed that the signal emitted
>> at full power was highly distorted and unreliable with PA linearization
>> disabled. With this patch, the signal becomes clear and stability
>> is improved.
>>
> We faced stability issues with 938x chipsets when paprd is enabled. The commit
> 6f4810101a629b31b5427872a09ea092cfc5c4bd states one of the issue. Even if it
> helps for AR933x, let us enable it only for that chip alone.
That was in January 2011, lots of bugs have been fixed since then,
initvals have been updated, EEPROM code has changed, ...
The internal QCA codebase enables PAPRD for all AR93xx devices that
support it, meaning non-PAPRD tx receives much less test coverage there.
While this issue has only been visible on a particular AR933x device, I
believe this is not the only one that's going to be affected, as the
EEPROM of any new device is calibrated for PAPRD-enabled operation.
If you don't want to enable it now, when do you think would be the right
time to enable it? Before I sent this patch, I did a detailed code
review to make sure that any obvious code discrepancies in PAPRD between
the internal codebase and ath9k are dealt with.
What else is needed to get this issue sorted out?
- Felix
On Tue, Aug 07, 2012 at 03:06:12PM +0200, Felix Fietkau wrote:
> This feature had been disabled in ath9k because the code to support
> it was incomplete, but now the code is in sync with the internal QCA
> codebase, so it's time to enable it.
>
> On many newer devices, the calibration is assumed to be done with PA
> linearization enabled.
>
> Tests with a particular AR933x device showed that the signal emitted
> at full power was highly distorted and unreliable with PA linearization
> disabled. With this patch, the signal becomes clear and stability
> is improved.
>
We faced stability issues with 938x chipsets when paprd is enabled. The commit
6f4810101a629b31b5427872a09ea092cfc5c4bd states one of the issue. Even if it
helps for AR933x, let us enable it only for that chip alone.
-Rajkumar
That predistortion type is not supported
Signed-off-by: Felix Fietkau <[email protected]>
---
drivers/net/wireless/ath/ath9k/ar9003_paprd.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_paprd.c b/drivers/net/wireless/ath/ath9k/ar9003_paprd.c
index 2c9f7d7..2173bd7 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_paprd.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_paprd.c
@@ -142,6 +142,7 @@ static int ar9003_paprd_setup_single_table(struct ath_hw *ah)
};
int training_power;
int i, val;
+ u32 am2pm_mask = ah->paprd_ratemask;
if (IS_CHAN_2GHZ(ah->curchan))
training_power = ar9003_get_training_power_2g(ah);
@@ -158,10 +159,13 @@ static int ar9003_paprd_setup_single_table(struct ath_hw *ah)
}
ah->paprd_training_power = training_power;
+ if (AR_SREV_9330(ah))
+ am2pm_mask = 0;
+
REG_RMW_FIELD(ah, AR_PHY_PAPRD_AM2AM, AR_PHY_PAPRD_AM2AM_MASK,
ah->paprd_ratemask);
REG_RMW_FIELD(ah, AR_PHY_PAPRD_AM2PM, AR_PHY_PAPRD_AM2PM_MASK,
- ah->paprd_ratemask);
+ am2pm_mask);
REG_RMW_FIELD(ah, AR_PHY_PAPRD_HT40, AR_PHY_PAPRD_HT40_MASK,
ah->paprd_ratemask_ht40);
--
1.7.9.6 (Apple Git-31.1)
Felix Fietkau wrote:
> This feature had been disabled in ath9k because the code to support
> it was incomplete, but now the code is in sync with the internal QCA
> codebase, so it's time to enable it.
>
> On many newer devices, the calibration is assumed to be done with PA
> linearization enabled.
>
> Tests with a particular AR933x device showed that the signal emitted
> at full power was highly distorted and unreliable with PA linearization
> disabled. With this patch, the signal becomes clear and stability
> is improved.
PAPRD for AR9462 requires changes to the HW code, can you leave out
AR9462 until I come up with the necessary patches ?
Sujith
On Wed, Aug 08, 2012 at 08:59:15PM +0530, Rajkumar Manoharan wrote:
> On Wed, Aug 08, 2012 at 05:12:25PM +0200, Felix Fietkau wrote:
> > On 2012-08-08 4:55 PM, Rajkumar Manoharan wrote:
> > > On Tue, Aug 07, 2012 at 03:06:12PM +0200, Felix Fietkau wrote:
> > >> This feature had been disabled in ath9k because the code to support
> > >> it was incomplete, but now the code is in sync with the internal QCA
> > >> codebase, so it's time to enable it.
> > >>
> > >> On many newer devices, the calibration is assumed to be done with PA
> > >> linearization enabled.
> > >>
> > >> Tests with a particular AR933x device showed that the signal emitted
> > >> at full power was highly distorted and unreliable with PA linearization
> > >> disabled. With this patch, the signal becomes clear and stability
> > >> is improved.
> > >>
> > > We faced stability issues with 938x chipsets when paprd is enabled. The commit
> > > 6f4810101a629b31b5427872a09ea092cfc5c4bd states one of the issue. Even if it
> > > helps for AR933x, let us enable it only for that chip alone.
> > That was in January 2011, lots of bugs have been fixed since then,
> > initvals have been updated, EEPROM code has changed, ...
> >
> > The internal QCA codebase enables PAPRD for all AR93xx devices that
> > support it, meaning non-PAPRD tx receives much less test coverage there.
> >
> > While this issue has only been visible on a particular AR933x device, I
> > believe this is not the only one that's going to be affected, as the
> > EEPROM of any new device is calibrated for PAPRD-enabled operation.
> >
> > If you don't want to enable it now, when do you think would be the right
> > time to enable it? Before I sent this patch, I did a detailed code
> > review to make sure that any obvious code discrepancies in PAPRD between
> > the internal codebase and ath9k are dealt with.
> >
> > What else is needed to get this issue sorted out?
> >
> Yes. it was disabled a long time back. Im completely fine with enabling the
> feature. I want to make sure that we should not endup again with the same issues.
> Atleast we should validite the one mentioned in the commit
> 6f4810101a629b31b5427872a09ea092cfc5c4bd
Any word on this validation?
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
This feature had been disabled in ath9k because the code to support
it was incomplete, but now the code is in sync with the internal QCA
codebase, so it's time to enable it.
On many newer devices, the calibration is assumed to be done with PA
linearization enabled.
Tests with a particular AR933x device showed that the signal emitted
at full power was highly distorted and unreliable with PA linearization
disabled. With this patch, the signal becomes clear and stability
is improved.
Signed-off-by: Felix Fietkau <[email protected]>
---
drivers/net/wireless/ath/ath9k/hw.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index d95474e..bea864f 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -463,9 +463,6 @@ static void ath9k_hw_init_config(struct ath_hw *ah)
ah->config.spurchans[i][1] = AR_NO_SPUR;
}
- /* PAPRD needs some more work to be enabled */
- ah->config.paprd_disable = 1;
-
ah->config.rx_intr_mitigation = true;
ah->config.pcieSerDesWrite = true;
--
1.7.9.6 (Apple Git-31.1)
Hi Felix!
On Tue, Aug 7, 2012 at 6:36 PM, Felix Fietkau <[email protected]> wrote:
> This feature had been disabled in ath9k because the code to support
> it was incomplete, but now the code is in sync with the internal QCA
> codebase, so it's time to enable it.
is it enabled for all AR9300 based chipsets ?
>
> On many newer devices, the calibration is assumed to be done with PA
> linearization enabled.
>
> Tests with a particular AR933x device showed that the signal emitted
> at full power was highly distorted and unreliable with PA linearization
> disabled. With this patch, the signal becomes clear and stability
> is improved.
>
> Signed-off-by: Felix Fietkau <[email protected]>
> ---
> drivers/net/wireless/ath/ath9k/hw.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
> index d95474e..bea864f 100644
> --- a/drivers/net/wireless/ath/ath9k/hw.c
> +++ b/drivers/net/wireless/ath/ath9k/hw.c
> @@ -463,9 +463,6 @@ static void ath9k_hw_init_config(struct ath_hw *ah)
> ah->config.spurchans[i][1] = AR_NO_SPUR;
> }
>
> - /* PAPRD needs some more work to be enabled */
> - ah->config.paprd_disable = 1;
> -
> ah->config.rx_intr_mitigation = true;
> ah->config.pcieSerDesWrite = true;
>
> --
> 1.7.9.6 (Apple Git-31.1)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
thanks,
shafi
Re-train if the calibrated PA linearization curve is out of bounds
(affects AR933x and AR9485).
Signed-off-by: Felix Fietkau <[email protected]>
---
drivers/net/wireless/ath/ath9k/ar9003_paprd.c | 99 +++++++++++++++++++++++++
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 4 +
drivers/net/wireless/ath/ath9k/link.c | 9 ++-
3 files changed, 111 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_paprd.c b/drivers/net/wireless/ath/ath9k/ar9003_paprd.c
index 2173bd7..0ed3846 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_paprd.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_paprd.c
@@ -786,6 +786,102 @@ int ar9003_paprd_setup_gain_table(struct ath_hw *ah, int chain)
}
EXPORT_SYMBOL(ar9003_paprd_setup_gain_table);
+static bool ar9003_paprd_retrain_pa_in(struct ath_hw *ah,
+ struct ath9k_hw_cal_data *caldata,
+ int chain)
+{
+ u32 *pa_in = caldata->pa_table[chain];
+ int capdiv_offset, quick_drop_offset;
+ int capdiv2g, quick_drop;
+ int count = 0;
+ int i;
+
+ if (!AR_SREV_9485(ah) && !AR_SREV_9330(ah))
+ return false;
+
+ capdiv2g = REG_READ_FIELD(ah, AR_PHY_65NM_CH0_TXRF3,
+ AR_PHY_65NM_CH0_TXRF3_CAPDIV2G);
+
+ quick_drop = REG_READ_FIELD(ah, AR_PHY_PAPRD_TRAINER_CNTL3,
+ AR_PHY_PAPRD_TRAINER_CNTL3_CF_PAPRD_QUICK_DROP);
+
+ if (quick_drop)
+ quick_drop -= 0x40;
+
+ for (i = 0; i < NUM_BIN + 1; i++) {
+ if (pa_in[i] == 1400)
+ count++;
+ }
+
+ if (AR_SREV_9485(ah)) {
+ if (pa_in[23] < 800) {
+ capdiv_offset = (int)((1000 - pa_in[23] + 75) / 150);
+ capdiv2g += capdiv_offset;
+ if (capdiv2g > 7) {
+ capdiv2g = 7;
+ if (pa_in[23] < 600) {
+ quick_drop++;
+ if (quick_drop > 0)
+ quick_drop = 0;
+ }
+ }
+ } else if (pa_in[23] == 1400) {
+ quick_drop_offset = min_t(int, count / 3, 2);
+ quick_drop += quick_drop_offset;
+ capdiv2g += quick_drop_offset / 2;
+
+ if (capdiv2g > 7)
+ capdiv2g = 7;
+
+ if (quick_drop > 0) {
+ quick_drop = 0;
+ capdiv2g -= quick_drop_offset;
+ if (capdiv2g < 0)
+ capdiv2g = 0;
+ }
+ } else {
+ return false;
+ }
+ } else if (AR_SREV_9330(ah)) {
+ if (pa_in[23] < 1000) {
+ capdiv_offset = (1000 - pa_in[23]) / 100;
+ capdiv2g += capdiv_offset;
+ if (capdiv_offset > 3) {
+ capdiv_offset = 1;
+ quick_drop--;
+ }
+
+ capdiv2g += capdiv_offset;
+ if (capdiv2g > 6)
+ capdiv2g = 6;
+ if (quick_drop < -4)
+ quick_drop = -4;
+ } else if (pa_in[23] == 1400) {
+ if (count > 3) {
+ quick_drop++;
+ capdiv2g -= count / 4;
+ if (quick_drop > -2)
+ quick_drop = -2;
+ } else {
+ capdiv2g--;
+ }
+
+ if (capdiv2g < 0)
+ capdiv2g = 0;
+ } else {
+ return false;
+ }
+ }
+
+ REG_RMW_FIELD(ah, AR_PHY_65NM_CH0_TXRF3,
+ AR_PHY_65NM_CH0_TXRF3_CAPDIV2G, capdiv2g);
+ REG_RMW_FIELD(ah, AR_PHY_PAPRD_TRAINER_CNTL3,
+ AR_PHY_PAPRD_TRAINER_CNTL3_CF_PAPRD_QUICK_DROP,
+ quick_drop);
+
+ return true;
+}
+
int ar9003_paprd_create_curve(struct ath_hw *ah,
struct ath9k_hw_cal_data *caldata, int chain)
{
@@ -821,6 +917,9 @@ int ar9003_paprd_create_curve(struct ath_hw *ah,
if (!create_pa_curve(data_L, data_U, pa_table, small_signal_gain))
status = -2;
+ if (ar9003_paprd_retrain_pa_in(ah, caldata, chain))
+ status = -EINPROGRESS;
+
REG_CLR_BIT(ah, AR_PHY_PAPRD_TRAINER_STAT1,
AR_PHY_PAPRD_TRAINER_STAT1_PAPRD_TRAIN_DONE);
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.h b/drivers/net/wireless/ath/ath9k/ar9003_phy.h
index 7bfbaf0..84d3d49 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.h
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.h
@@ -625,6 +625,10 @@
#define AR_PHY_AIC_CTRL_4_B0 (AR_SM_BASE + 0x4c0)
#define AR_PHY_AIC_STAT_2_B0 (AR_SM_BASE + 0x4cc)
+#define AR_PHY_65NM_CH0_TXRF3 0x16048
+#define AR_PHY_65NM_CH0_TXRF3_CAPDIV2G 0x0000001e
+#define AR_PHY_65NM_CH0_TXRF3_CAPDIV2G_S 1
+
#define AR_PHY_65NM_CH0_SYNTH4 0x1608c
#define AR_PHY_SYNTH4_LONG_SHIFT_SELECT (AR_SREV_9462(ah) ? 0x00000001 : 0x00000002)
#define AR_PHY_SYNTH4_LONG_SHIFT_SELECT_S (AR_SREV_9462(ah) ? 0 : 1)
diff --git a/drivers/net/wireless/ath/ath9k/link.c b/drivers/net/wireless/ath/ath9k/link.c
index d4549e9..1c24192 100644
--- a/drivers/net/wireless/ath/ath9k/link.c
+++ b/drivers/net/wireless/ath/ath9k/link.c
@@ -254,6 +254,7 @@ void ath_paprd_calibrate(struct work_struct *work)
int chain_ok = 0;
int chain;
int len = 1800;
+ int ret;
if (!caldata)
return;
@@ -302,7 +303,13 @@ void ath_paprd_calibrate(struct work_struct *work)
break;
}
- if (ar9003_paprd_create_curve(ah, caldata, chain)) {
+ ret = ar9003_paprd_create_curve(ah, caldata, chain);
+ if (ret == -EINPROGRESS) {
+ ath_dbg(common, CALIBRATE,
+ "PAPRD curve on chain %d needs to be re-trained\n",
+ chain);
+ break;
+ } else if (ret) {
ath_dbg(common, CALIBRATE,
"PAPRD create curve failed on chain %d\n",
chain);
--
1.7.9.6 (Apple Git-31.1)
On 2012-08-08 4:17 PM, Mohammed Shafi wrote:
> Hi Felix!
>
> On Tue, Aug 7, 2012 at 6:36 PM, Felix Fietkau <[email protected]> wrote:
>> This feature had been disabled in ath9k because the code to support
>> it was incomplete, but now the code is in sync with the internal QCA
>> codebase, so it's time to enable it.
>
> is it enabled for all AR9300 based chipsets ?
All AR93xx based devices where it is marked as supported in EEPROM.
- Felix