ath5k: reset for 5424-based card

PATCH Bob Copeland 3 participants 16 messages Jan 31, 2008 – Feb 19, 2008 Networking drivers (wireless)

lore

Share & tools

lore

Bob Copeland

author

2008-01-31 16:33 UTC #0 lore raw

Hi all,

I have the following device (0x168c:001c) which comes with certain MacBooks:

02:00.0 Ethernet controller: Atheros Communications, Inc. AR5006EG 802.11 b/g Wireless PCI Express Adapter (rev 01)

The current driver from merged-upstream of a few days ago doesn't seem to work for this card. In ath5k_hw_nic_wakeup, it dies after the nic reset and any MMIO accesses from then on return -1 (needs a hard reboot to fix).

I dumped a trace of the working madwifi driver using mmio-trace and saw that it only sets the bottom two bits when doing AR5K_RESET_CTL. So, the patch below indeed makes probe work for the card.

It isn't perfect after that; it can associate with an AP but appears to reset constantly so it's not really usable.

I'd love to get this working generally; if needed I can try out patches, supply traces, or, given enough direction, contribute some code...

drivers/net/wireless/ath5k/hw.c +1 -1

index 3a4bf40..3fa0621 100644
@@ -359,7 +359,7 @@ static int ath5k_hw_nic_wakeup(struct ath5k_hw *ah, int flags, bool initial)
 
 	/* ...reset chipset and PCI device */
 	if (ah->ah_single_chip == false && ath5k_hw_nic_reset(ah,
-				AR5K_RESET_CTL_CHIP | AR5K_RESET_CTL_PCI)) {
+				AR5K_RESET_CTL_BASEBAND | AR5K_RESET_CTL_PCU)) {
 		ATH5K_ERR(ah->ah_sc, "failed to reset the MAC Chip + PCI\n");
 		return -EIO;
 	}

Signature · 1 line

Bob Copeland %% www.bobcopeland.com

Nick Kossifidis

2008-01-31 16:56 UTC #1 lore raw

2008/1/31, Bob Copeland <[email protected]>:

Quoted 6 lines

Hi all,
I have the following device (0x168c:001c) which comes with certain MacBooks:
02:00.0 Ethernet controller: Atheros Communications, Inc. AR5006EG 802.11 b/g Wireless PCI Express Adapter (rev 01)

Can you plz run ath_info tool found on madwifi-trace branch and post the output (mac/phy revision) ?

Quoted 8 lines

The current driver from merged-upstream of a few days ago doesn't seem to work for this card. In ath5k_hw_nic_wakeup, it dies after the nic reset and any MMIO accesses from then on return -1 (needs a hard reboot to fix).
I dumped a trace of the working madwifi driver using mmio-trace and saw that it only sets the bottom two bits when doing AR5K_RESET_CTL. So, the patch below indeed makes probe work for the card.

It's a known bug, i have a patch pending already, problem is that AR5K_RESET_CTL_PCI probably hangs the "host interface unit" and you need to reboot as you said, just removing it also fixes the probe problem (that seems to only happen on newer pci-e cards).

Quoted 3 lines

It isn't perfect after that; it can associate with an AP but appears to reset constantly so it's not really usable.

That's interesting because even with the fix on nic_wakeup + making initvals tables etc i tried it on a 2425 and couldn't even scan (that's why i hadn't post the patch earlier, card wouldn't work anyway so i left it for the patch series i'm working on). If you got your card scanning then we are really close on fixing it !

Quoted 3 lines

I'd love to get this working generally; if needed I can try out patches, supply traces, or, given enough direction, contribute some code...

Thanx a lot for your patch, just have in mind that we prefer to reset most of the card's units to be on the safe side, that's because we don't know what cards (mac/phy revisions) can live without reseting X unit.

Another important question, what band was the ap on ?

Signature · 3 lines

GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Bob Copeland

author

2008-02-01 04:05 UTC #2 lore raw

Quoted 2 lines · Nick Kossifidis

Can you plz run ath_info tool found on madwifi-trace branch and post the output (mac/phy revision) ?

Sure -- full output is at http://bobcopeland.com/ath5k/ along with EEPROM dump and a scan of my neighborhood.

MAC Version:  2424  (0xa0)
MAC Revision: 5424  (0xa3)
Warning: Invalid EEPROM Magic number!
Device type:  3

5Ghz PHY Revision: SChip (0xa2)
2Ghz PHY Revision: SChip (0xa2)

Quoted 2 lines

so i left it for the patch series i'm working on). If you got your card scanning then we are really close on fixing it !

Excellent news!

Quoted 1 line

Another important question, what band was the ap on ?

Good question - it was a Starbucks hotspot so I'm guessing 802.11b?

Signature · 1 line

Bob Copeland %% www.bobcopeland.com

Nick Kossifidis

2008-02-01 12:09 UTC #3 lore raw

2008/2/1, Bob Copeland <[email protected]>:

Quoted 14 lines · Nick Kossifidis

Quoted 2 lines
Can you plz run ath_info tool found on madwifi-trace branch and post the output (mac/phy revision) ?
Sure -- full output is at http://bobcopeland.com/ath5k/ along with EEPROM dump and a scan of my neighborhood.
MAC Version:  2424  (0xa0)
MAC Revision: 5424  (0xa3)
Warning: Invalid EEPROM Magic number!
Device type:  3
5Ghz PHY Revision: SChip (0xa2)
2Ghz PHY Revision: SChip (0xa2)

Quoted 9 lines

Quoted 2 lines
so i left it for the patch series i'm working on). If you got your card scanning then we are really close on fixing it !
Excellent news!
Quoted 1 line
Another important question, what band was the ap on ?
Good question - it was a Starbucks hotspot so I'm guessing 802.11b?

Wow that's the first 5424 report we have ;-)

Do you have an AP so you can run the testbed-trace as described here ?
http://madwifi.org/wiki/DevDocs/MadwifiTrace

b/g modes are ok for start (you can force mode from the sta using iwpriv ath0 mode X, x=1(a) 2(b) 3(g)) but if you can also provide dumps for a and turbo modes it would be really cool (you 'll need an atheros-based ap for the turbo mode to run testbed-trace, if you don't have such ap then you can try to setup your card as AP for a and turboa modes -static turbo-, dumps from ap operation will also do, just make sure you force the mode through iwpriv).

If you provide me with the needed dumps i'll work on it and give you a tarball to test asap (asap > 10days due to exams ;-( ) !!!

One more question: can you plz describe card's behaviour with ath5k ? What error message does it return on reset-failure ?

Thanx a lot for the feedback ;-)

Signature · 3 lines

GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Bob Copeland

author

2008-02-01 22:55 UTC #4 lore raw

Quoted 3 lines · Nick Kossifidis

Do you have an AP so you can run the testbed-trace as described here ?
http://madwifi.org/wiki/DevDocs/MadwifiTrace

Yeah I have an AP but it's broadcom based. I'll try to do the traces this weekend.

Quoted 2 lines

One more question: can you plz describe card's behaviour with ath5k ? What error message does it return on reset-failure ?

Well, with the change from my original post, the card appears to function somewhat but the cpu gets busy and the whole machine crawls. Note, I didn't make any changes for initvals.

I can associate but not for very long. dmesg looks like this:

ath5k phy0: Atheros AR5424 chip found (MAC: 0xa3, PHY: 0x61)
NET: Registered protocol family 17
ath0: Initial auth_alg=0
ath0: authenticate with AP 00:1a:70:da:a9:cd
ath0: RX authentication from 00:1a:70:da:a9:cd (alg=0 transaction=2 status=0)
ath0: authenticated
ath0: associate with AP 00:1a:70:da:a9:cd
ath0: RX AssocResp from 00:1a:70:da:a9:cd (capab=0x411 status=0 aid=2)
ath0: associated
ath0: switched to long barker preamble (BSSID=00:1a:70:da:a9:cd)
ath5k_hw_get_isr: 0x00000020
ath5k_hw_get_isr: 0x00000020
ath5k_hw_get_isr: 0x00000020
ath5k_hw_get_isr: 0x00000020
[repeats a ton]
ath0: No ProbeResp from current AP 00:1a:70:da:a9:cd - assume out of range
printk: 81 messages suppressed.
ath5k_hw_get_isr: 0x00000020
printk: 36 messages suppressed.
ath5k_hw_get_isr: 0x00000020

and sometimes:
ath5k phy3: noise floor calibration timeout (2462MHz)

With debug on these were the resets I was seeing, may be normal but I didn't know:

ath5k trace ath5k_hw_stop_tx_dma:1241
ath5k trace ath5k_hw_stop_pcu_recv:2433
ath5k trace ath5k_hw_set_rx_filter:2518
ath5k trace ath5k_hw_stop_rx_dma:1143
ath5k trace ath5k_hw_reset:573
ath5k trace ath5k_hw_get_rf_gain:1349
ath5k trace ath5k_hw_nic_wakeup:290
ath5k trace ath5k_hw_set_power:1058
ath5k trace ath5k_hw_set_power:1058
ath5k trace ath5k_hw_nic_reset:1011
ath5k trace ath5k_hw_txpower:2012
ath5k trace ath5k_hw_get_rate_table:401
ath5k trace ath5k_hw_disable_pspoll:4342
ath5k trace ath5k_hw_set_opmode:2187
ath5k trace ath5k_hw_reset_tx_queue:3173

Quoted 1 line

Thanx a lot for the feedback ;-)

np!

Signature · 1 line

Bob Copeland %% www.bobcopeland.com

Nick Kossifidis

2008-02-02 01:48 UTC #5 lore raw

2008/2/2, Bob Copeland <[email protected]>:

Quoted 8 lines · Nick Kossifidis

Quoted 3 lines
Do you have an AP so you can run the testbed-trace as described here ?
http://madwifi.org/wiki/DevDocs/MadwifiTrace
Yeah I have an AP but it's broadcom based. I'll try to do the traces this weekend.

Thanx ;-)

Quoted 9 lines

Quoted 2 lines
One more question: can you plz describe card's behaviour with ath5k ? What error message does it return on reset-failure ?
Well, with the change from my original post, the card appears to function somewhat but the cpu gets busy and the whole machine crawls. Note, I didn't make any changes for initvals.
I can associate but not for very long. dmesg looks like this:

Quoted 15 lines

ath5k phy0: Atheros AR5424 chip found (MAC: 0xa3, PHY: 0x61)
NET: Registered protocol family 17
ath0: Initial auth_alg=0
ath0: authenticate with AP 00:1a:70:da:a9:cd
ath0: RX authentication from 00:1a:70:da:a9:cd (alg=0 transaction=2 status=0)
ath0: authenticated
ath0: associate with AP 00:1a:70:da:a9:cd
ath0: RX AssocResp from 00:1a:70:da:a9:cd (capab=0x411 status=0 aid=2)
ath0: associated
ath0: switched to long barker preamble (BSSID=00:1a:70:da:a9:cd)
ath5k_hw_get_isr: 0x00000020
ath5k_hw_get_isr: 0x00000020
ath5k_hw_get_isr: 0x00000020
ath5k_hw_get_isr: 0x00000020

Great info ! Your card sends the RXORN interrupt (Rx overrun), at least we know what the problem is ;-)

How about your signal strength ?

Quoted 3 lines

[repeats a ton]
ath0: No ProbeResp from current AP 00:1a:70:da:a9:cd - assume out of range

That's normal since we have rx overrun frames don't reach the driver...

Quoted 3 lines

and sometimes:
ath5k phy3: noise floor calibration timeout (2462MHz)

That's ok since we haven't added initvals/rfbuffer tables for your card so phy isn't initialized propertly (this is the first problem we should fix so we can be sure that rx overrun is not phy-related).

Quoted 19 lines

With debug on these were the resets I was seeing, may be normal but I didn't know:
ath5k trace ath5k_hw_stop_tx_dma:1241
ath5k trace ath5k_hw_stop_pcu_recv:2433
ath5k trace ath5k_hw_set_rx_filter:2518
ath5k trace ath5k_hw_stop_rx_dma:1143
ath5k trace ath5k_hw_reset:573
ath5k trace ath5k_hw_get_rf_gain:1349
ath5k trace ath5k_hw_nic_wakeup:290
ath5k trace ath5k_hw_set_power:1058
ath5k trace ath5k_hw_set_power:1058
ath5k trace ath5k_hw_nic_reset:1011
ath5k trace ath5k_hw_txpower:2012
ath5k trace ath5k_hw_get_rate_table:401
ath5k trace ath5k_hw_disable_pspoll:4342
ath5k trace ath5k_hw_set_opmode:2187
ath5k trace ath5k_hw_reset_tx_queue:3173

Yup on rx overrun card resets but it worries me that get_isr reports it, get_isr only prints an interrupt code when it doesn't process it, and that's a bug in your case (on some cards rx overrun is fatal and we don't handle this right now, well just one more fix to add on my pending patches ;-) ).

Try this fix...
edit drivers/net/wireless/ath5k/hw.c, go to ath5k_hw_get_isr and you'll see this...

1472 if (ah->ah_version != AR5K_AR5210) {
1473 /*HIU = Host Interface Unit (PCI etc)*/
1474 if (unlikely(data & (AR5K_ISR_HIUERR)))
1475 *interrupt_mask |= AR5K_INT_FATAL;

Change AR5K_ISR_HIUERR with AR5K_ISR_RXORN

This will force a card reset once you receive an RXORN interrupt (will report it as FATAL) and will get rid of get_isr message ;-)

Signature · 3 lines

GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Bob Copeland

author

2008-02-03 01:47 UTC #6 lore raw

Quoted 5 lines · Nick Kossifidis

Quoted 3 lines
Yeah I have an AP but it's broadcom based. I'll try to do the traces this weekend.
Thanx ;-)

Ok, so I did -b and -g traces. That branch is a little out of date, so I wound up downgrading to 2.6.22.

I don't have an a-capable AP, so how might I get a/turboa/turbog traces? Do I use wlanconfig from the madwifi docs like so:

   $ iwpriv ath0 mode 1
   $ wlanconfig ath0 create wlandev wifi0 wlanmode ap

What mode # is used for turbo a/g?

I put the tarballs at http://bobcopeland.com/ath5k/

Quoted 4 lines

Great info ! Your card sends the RXORN interrupt (Rx overrun), at least we know what the problem is ;-)
How about your signal strength ?

Looks fine, I think:

    Quality=89/100  Signal level=-39 dBm  Noise level=-96 dBm

Quoted 3 lines

That's ok since we haven't added initvals/rfbuffer tables for your card so phy isn't initialized propertly (this is the first problem we should fix so we can be sure that rx overrun is not phy-related).

OK, well I guess that info is in the tarballs. I poked around in the code, and it looks like my tables are similar to 5413 with maybe a couple of extra registers. But I'll await your analysis. :)

Quoted 7 lines

1472 if (ah->ah_version != AR5K_AR5210) {
1473 /*HIU = Host Interface Unit (PCI etc)*/
1474 if (unlikely(data & (AR5K_ISR_HIUERR)))
1475 *interrupt_mask |= AR5K_INT_FATAL;
Change AR5K_ISR_HIUERR with AR5K_ISR_RXORN

It does get rid of the message, but other than not seeing the printk any more, it doesn't seem to help things much.

Good luck on the exams!

Signature · 1 line

Bob Copeland %% www.bobcopeland.com

Nick Kossifidis

2008-02-05 09:13 UTC #7 lore raw

Quoted 11 lines

Ok, so I did -b and -g traces. That branch is a little out of date, so I wound up downgrading to 2.6.22.
I don't have an a-capable AP, so how might I get a/turboa/turbog traces? Do I use wlanconfig from the madwifi docs like so:
   $ iwpriv ath0 mode 1
   $ wlanconfig ath0 create wlandev wifi0 wlanmode ap
What mode # is used for turbo a/g?

turbog doesn't work, turboa is 4 i think, don't worry about turbo modes, just try to get a regdump for a and it'll be fine (check out initvals to be sure if you like that you are on a mode) ;-)

Quoted 2 lines

I put the tarballs at http://bobcopeland.com/ath5k/

Great, thanx a lot ;-)

Quoted 8 lines

Quoted 4 lines
Great info ! Your card sends the RXORN interrupt (Rx overrun), at least we know what the problem is ;-)
How about your signal strength ?
Looks fine, I think:
    Quality=89/100  Signal level=-39 dBm  Noise level=-96 dBm

It's fine, that's cool it seems phy is ok (and hopefully is the same with 5413 as i thought), it must be some mac settings related to pci-e that result rx overrun, i've spotted some registers but i'll need to spend some time on it and right now that's not possible ;-(

Quoted 8 lines

Quoted 3 lines
That's ok since we haven't added initvals/rfbuffer tables for your card so phy isn't initialized propertly (this is the first problem we should fix so we can be sure that rx overrun is not phy-related).
OK, well I guess that info is in the tarballs. I poked around in the code, and it looks like my tables are similar to 5413 with maybe a couple of extra registers. But I'll await your analysis. :)

Might be some other part of reset/attach that we miss, i'll look on it asap ;-)

Quoted 6 lines

Quoted 6 lines
1472 if (ah->ah_version != AR5K_AR5210) {
1473 /*HIU = Host Interface Unit (PCI etc)*/
1474 if (unlikely(data & (AR5K_ISR_HIUERR)))
1475 *interrupt_mask |= AR5K_INT_FATAL;

Quoted 7 lines

Quoted 1 line
Change AR5K_ISR_HIUERR with AR5K_ISR_RXORN
It does get rid of the message, but other than not seeing the printk any more, it doesn't seem to help things much.
Good luck on the exams!

Thanx a lot and thanx for the traces ;-)

Signature · 3 lines

GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Bob Copeland

author

2008-02-10 16:23 UTC #8 lore raw

Quoted 4 lines · Nick Kossifidis

It's fine, that's cool it seems phy is ok (and hopefully is the same with 5413 as i thought), it must be some mac settings related to pci-e that result rx overrun, i've spotted some registers but i'll need to spend some time on it and right now that's not possible ;-(

So I played around with the code this weekend and have gotten it to work somewhat (I am posting this using the driver). I think it only works right after system power-up and something's not right because it's a little laggy.

One weird thing -- in my traces, the g-mode tables seem to be the b-mode tables and vice-versa. I may have mixed up the trace files but I'm not sure how. Anyway it works without changes to the initvals.

I'll post a patch later tonight.

Signature · 1 line

Bob Copeland %% www.bobcopeland.com

Nick Kossifidis

2008-02-10 19:05 UTC #9 lore raw

2008/2/10, Bob Copeland <[email protected]>:

Quoted 11 lines · Nick Kossifidis

Quoted 4 lines
It's fine, that's cool it seems phy is ok (and hopefully is the same with 5413 as i thought), it must be some mac settings related to pci-e that result rx overrun, i've spotted some registers but i'll need to spend some time on it and right now that's not possible ;-(
So I played around with the code this weekend and have gotten it to work somewhat (I am posting this using the driver). I think it only works right after system power-up and something's not right because it's a little laggy.

Quoted 6 lines

One weird thing -- in my traces, the g-mode tables seem to be the b-mode tables and vice-versa. I may have mixed up the trace files but I'm not sure how. Anyway it works without changes to the initvals.
I'll post a patch later tonight.

Did you forced b mode via iwpriv while tracing (even if ap is b-only card will use g settings) ? You should at least see different IFS etc settings (check out initvals).

Good work ;-)

Signature · 3 lines

GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Bob Copeland

author

2008-02-11 15:01 UTC #10 lore raw

Quoted 2 lines · Nick Kossifidis

2008/2/10, Bob Copeland <[email protected]>:
Quoted 1 line
I'll post a patch later tonight.

Well I spoke too soon :) I was unable to repeatedly get this to work so I guess maybe I was lucky the times it did. Here's what I have so far.

- in my traces the hal always set DMA == 128B. So I did not bump it up, and that seemed to cure rx overrun. Obviously should be done on a per-card basis.

- turned off reset of PCI to avoid host interface unit hang as discussed previously

- noticed this card has a different sleep pending value, not sure what the rf5413 uses compared to this

- added various registers that I have no idea what they do.

Quoted 3 lines

Did you forced b mode via iwpriv while tracing (even if ap is b-only card will use g settings) ? You should at least see different IFS etc settings (check out initvals).

Not sure, I'll try them again. Are the other traces for other cards online somewhere?

Quoted 1 line

Good work ;-)

Heh I really don't know a phy from a sta so feel free to pick this apart...

Quoted 1 line

From 53d584dd188a131632e09353d1dd674f02a15b3c Mon Sep 17 00:00:00 2001

From: Bob Copeland <[email protected]>
Date: Sat, 9 Feb 2008 00:16:12 -0500
Subject: [PATCH] ath5k: changes for 5424/2424 cards

This adds some register writes and updates some values used by the Atheros 5424 chipset. This is just an experimental patch that should not be applied.

---
 drivers/net/wireless/ath5k/hw.c |   29 ++++++++++++++++++++++-------
 1 files changed, 22 insertions(+), 7 deletions(-)

drivers/net/wireless/ath5k/hw.c +22 -7

index 3a4bf40..ba832b0 100644
@@ -358,8 +358,8 @@ static int ath5k_hw_nic_wakeup(struct ath5k_hw *ah, int flags, bool initial)
 	}
 
 	/* ...reset chipset and PCI device */
-	if (ah->ah_single_chip == false && ath5k_hw_nic_reset(ah,
-				AR5K_RESET_CTL_CHIP | AR5K_RESET_CTL_PCI)) {
+	if (ah->ah_single_chip == false && ath5k_hw_nic_reset(ah, 
+		AR5K_RESET_CTL_CHIP)) {
 		ATH5K_ERR(ah->ah_sc, "failed to reset the MAC Chip + PCI\n");
 		return -EIO;
 	}

@@ -887,9 +887,9 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode,
 	 */
 	if (ah->ah_version != AR5K_AR5210) {
 		AR5K_REG_WRITE_BITS(ah, AR5K_TXCFG, AR5K_TXCFG_SDMAMR,
-				AR5K_DMASIZE_512B | AR5K_TXCFG_DMASIZE);
+				AR5K_DMASIZE_128B | AR5K_TXCFG_DMASIZE);
 		AR5K_REG_WRITE_BITS(ah, AR5K_RXCFG, AR5K_RXCFG_SDMAMW,
-				AR5K_DMASIZE_512B);
+				AR5K_DMASIZE_128B);
 	}
 
 	/*

@@ -981,14 +981,22 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode,
 	 * Set the 32MHz reference clock on 5212 phy clock sleep register
 	 */
 	if (ah->ah_version == AR5K_AR5212) {
+		int spending;
+
 		ath5k_hw_reg_write(ah, AR5K_PHY_SCR_32MHZ, AR5K_PHY_SCR);
 		ath5k_hw_reg_write(ah, AR5K_PHY_SLMT_32MHZ, AR5K_PHY_SLMT);
 		ath5k_hw_reg_write(ah, AR5K_PHY_SCAL_32MHZ, AR5K_PHY_SCAL);
 		ath5k_hw_reg_write(ah, AR5K_PHY_SCLOCK_32MHZ, AR5K_PHY_SCLOCK);
 		ath5k_hw_reg_write(ah, AR5K_PHY_SDELAY_32MHZ, AR5K_PHY_SDELAY);
-		ath5k_hw_reg_write(ah, ah->ah_radio == AR5K_RF5111 ?
-			AR5K_PHY_SPENDING_RF5111 : AR5K_PHY_SPENDING_RF5112,
-			AR5K_PHY_SPENDING);
+
+		if (ah->ah_radio <= AR5K_RF5111)
+			spending = AR5K_PHY_SPENDING_RF5111;
+		else if (ah->ah_radio <= AR5K_RF5112)
+			spending = AR5K_PHY_SPENDING_RF5112;
+		else
+			spending = 0x12;
+
+		ath5k_hw_reg_write(ah, spending, AR5K_PHY_SPENDING);
 	}
 
 	/*

@@ -997,6 +1005,13 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode,
 	AR5K_REG_DISABLE_BITS(ah, AR5K_BEACON, AR5K_BEACON_ENABLE |
 			AR5K_BEACON_RESET_TSF);
 
+	if (ah->ah_mac_srev >= AR5K_SREV_VER_AR2424) {
+		ath5k_hw_reg_write(ah, 0x000100aa, 0x8118);
+		ath5k_hw_reg_write(ah, 0x00003210, 0x811c);
+		ath5k_hw_reg_write(ah, 0x00000052, 0x8108);
+		ath5k_hw_reg_write(ah, 0x001e1e1e, AR5K_TXPC);
+		ath5k_hw_reg_write(ah, 0x00000004, 0x8120);
+	}
 	return 0;
 }

Signature · 5 lines

1.5.4


-- 
Bob Copeland %% www.bobcopeland.com

Nick Kossifidis

2008-02-12 07:18 UTC #11 lore raw

2008/2/11, Bob Copeland <[email protected]>:

Quoted 12 lines · Nick Kossifidis

Quoted 2 lines
2008/2/10, Bob Copeland <[email protected]>:
Quoted 1 line
I'll post a patch later tonight.
Well I spoke too soon :) I was unable to repeatedly get this to work so I guess maybe I was lucky the times it did. Here's what I have so far.
- in my traces the hal always set DMA == 128B. So I did not bump it up, and that seemed to cure rx overrun. Obviously should be done on a per-card basis.

It makes sense, i'll see what effect this has on other cards too ;-)

Quoted 3 lines

- turned off reset of PCI to avoid host interface unit hang as discussed previously

ACK

Quoted 12 lines

- noticed this card has a different sleep pending value, not sure what the rf5413 uses compared to this
- added various registers that I have no idea what they do.
Quoted 3 lines
Did you forced b mode via iwpriv while tracing (even if ap is b-only card will use g settings) ? You should at least see different IFS etc settings (check out initvals).
Not sure, I'll try them again. Are the other traces for other cards online somewhere?

Nope i have them all gathered on my laptop, you 'll sure find some posted on ath5k-devel list. I'll send you a b-only trace from one of my cards (a 5413) to check it out ;-)

We are working on a way to have all dumps uploaded somewhere...

Quoted 5 lines

Quoted 1 line
Good work ;-)
Heh I really don't know a phy from a sta so feel free to pick this apart...

You 've really done a great job, that's really helpful ;-)

Quoted 29 lines

From 53d584dd188a131632e09353d1dd674f02a15b3c Mon Sep 17 00:00:00 2001
From: Bob Copeland <[email protected]>
Date: Sat, 9 Feb 2008 00:16:12 -0500
Subject: [PATCH] ath5k: changes for 5424/2424 cards

This adds some register writes and updates some values used by the Atheros 5424 chipset. This is just an experimental patch that should not be applied.

---
 drivers/net/wireless/ath5k/hw.c |   29 ++++++++++++++++++++++-------
 1 files changed, 22 insertions(+), 7 deletions(-)

drivers/net/wireless/ath5k/hw.c +2 -2

index 3a4bf40..ba832b0 100644
@@ -358,8 +358,8 @@ static int ath5k_hw_nic_wakeup(struct ath5k_hw *ah, int flags, bool initial)
        }
 
        /* ...reset chipset and PCI device */
-       if (ah->ah_single_chip == false && ath5k_hw_nic_reset(ah,
-                               AR5K_RESET_CTL_CHIP | AR5K_RESET_CTL_PCI)) {
+       if (ah->ah_single_chip == false && ath5k_hw_nic_reset(ah,
+               AR5K_RESET_CTL_CHIP)) {
                ATH5K_ERR(ah->ah_sc, "failed to reset the MAC Chip + PCI\n");
                return -EIO;
        }

drivers/net/wireless/ath5k/hw.c int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode, · line 894

Quoted 10 lines

drivers/net/wireless/ath5k/hw.c +2 -2

@@ -887,9 +887,9 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode,
         */
        if (ah->ah_version != AR5K_AR5210) {
                AR5K_REG_WRITE_BITS(ah, AR5K_TXCFG, AR5K_TXCFG_SDMAMR,
-                               AR5K_DMASIZE_512B | AR5K_TXCFG_DMASIZE);
+                               AR5K_DMASIZE_128B | AR5K_TXCFG_DMASIZE);
                AR5K_REG_WRITE_BITS(ah, AR5K_RXCFG, AR5K_RXCFG_SDMAMW,
-                               AR5K_DMASIZE_512B);
+                               AR5K_DMASIZE_128B);
        }

Have you tried 256 ? Also have you tried only setting lower dma size for rx ?

Quoted 28 lines

drivers/net/wireless/ath5k/hw.c +11 -3

/*

@@ -981,14 +981,22 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode,
         * Set the 32MHz reference clock on 5212 phy clock sleep register
         */
        if (ah->ah_version == AR5K_AR5212) {
+               int spending;
+
                ath5k_hw_reg_write(ah, AR5K_PHY_SCR_32MHZ, AR5K_PHY_SCR);
                ath5k_hw_reg_write(ah, AR5K_PHY_SLMT_32MHZ, AR5K_PHY_SLMT);
                ath5k_hw_reg_write(ah, AR5K_PHY_SCAL_32MHZ, AR5K_PHY_SCAL);
                ath5k_hw_reg_write(ah, AR5K_PHY_SCLOCK_32MHZ, AR5K_PHY_SCLOCK);
                ath5k_hw_reg_write(ah, AR5K_PHY_SDELAY_32MHZ, AR5K_PHY_SDELAY);
-               ath5k_hw_reg_write(ah, ah->ah_radio == AR5K_RF5111 ?
-                       AR5K_PHY_SPENDING_RF5111 : AR5K_PHY_SPENDING_RF5112,
-                       AR5K_PHY_SPENDING);
+
+               if (ah->ah_radio <= AR5K_RF5111)
+                       spending = AR5K_PHY_SPENDING_RF5111;
+               else if (ah->ah_radio <= AR5K_RF5112)
+                       spending = AR5K_PHY_SPENDING_RF5112;
+               else
+                       spending = 0x12;
+
+               ath5k_hw_reg_write(ah, spending, AR5K_PHY_SPENDING);
        }
 
        /*

drivers/net/wireless/ath5k/hw.c int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode, · line 1012

Quoted 8 lines

drivers/net/wireless/ath5k/hw.c +5 -0

@@ -997,6 +1005,13 @@ int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode,
        AR5K_REG_DISABLE_BITS(ah, AR5K_BEACON, AR5K_BEACON_ENABLE |
                        AR5K_BEACON_RESET_TSF);
 
+       if (ah->ah_mac_srev >= AR5K_SREV_VER_AR2424) {
+               ath5k_hw_reg_write(ah, 0x000100aa, 0x8118);
+               ath5k_hw_reg_write(ah, 0x00003210, 0x811c);
+               ath5k_hw_reg_write(ah, 0x00000052, 0x8108);
+               ath5k_hw_reg_write(ah, 0x001e1e1e, AR5K_TXPC);

Remove TXPC and see what happens...

Quoted 5 lines

drivers/net/wireless/ath5k/hw.c +2 -0

+               ath5k_hw_reg_write(ah, 0x00000004, 0x8120);
+       }
        return 0;
 }

Signature · 3 lines

GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Holger Schurig

2008-02-12 07:48 UTC #12 lore raw

Quoted 6 lines

Nope i have them all gathered on my laptop, you 'll sure find some posted on ath5k-devel list. I'll send you a b-only trace from one of my cards (a 5413) to check it out ;-)
We are working on a way to have all dumps uploaded somewhere...

Why not put them into SVN ? Put them there in some original
format and in a text-format, so you can easily add comments with a text editor into the dumps. That comments could then be used as markers for automatically comparing the dumps of different cards.

Nick Kossifidis

2008-02-12 07:55 UTC #13 lore raw

2008/2/12, Holger Schurig <[email protected]>:

Quoted 4 lines

Quoted 4 lines
Nope i have them all gathered on my laptop, you 'll sure find some posted on ath5k-devel list. I'll send you a b-only trace from one of my cards (a 5413) to check it out ;-)

Quoted 9 lines

Quoted 2 lines
We are working on a way to have all dumps uploaded somewhere...
Why not put them into SVN ? Put them there in some original
format and in a text-format, so you can easily add comments with a text editor into the dumps. That comments could then be used as markers for automatically comparing the dumps of different cards.

That's also a possibility ;-)

Signature · 3 lines

GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick

Bob Copeland

author

2008-02-14 04:21 UTC #14 lore raw

In reply to Nick Kossifidis

Quoted 8 lines · Nick Kossifidis

Quoted 2 lines
Not sure, I'll try them again. Are the other traces for other cards online somewhere?
Nope i have them all gathered on my laptop, you 'll sure find some posted on ath5k-devel list. I'll send you a b-only trace from one of my cards (a 5413) to check it out ;-)
We are working on a way to have all dumps uploaded somewhere...

Okay that would be good. I was basically searching for differences by hooking ath_hw_reg_write with a printk, sorting that, and diffing it with a sorted file of "reg_address:value" extracted from the traces. Would be useful to run the same scripts over other cards' dumps...

Quoted 6 lines

drivers/net/wireless/ath5k/hw.c int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode, · line 893
Quoted 4 lines
drivers/net/wireless/ath5k/hw.c +1 -1
-                               AR5K_DMASIZE_512B);
+                               AR5K_DMASIZE_128B);
        }
Have you tried 256 ? Also have you tried only setting lower dma size for rx ?

I did a few times, but not enough to definitively say which works and which doesn't. I'll try to get it repeatedly starting up correctly when I get some free time, and from there I should be able to figure out what's actually needed and what is noise.

Quoted 3 lines

Quoted 1 line
+ ath5k_hw_reg_write(ah, 0x001e1e1e, AR5K_TXPC);
Remove TXPC and see what happens...

Sure, I'll give that a go as well.

Signature · 1 line

Bob Copeland %% www.bobcopeland.com

Bob Copeland

author

2008-02-19 00:00 UTC #15 lore raw

In reply to Nick Kossifidis

I spent a bunch of reboots on trying to narrow down what needs to stay and what can go. Driver is still a little flaky for this card; I'd say about one third of the time I do an insmod the card gets hung and I need to reboot. That makes it harder to rule certain changes in/out.

Also, the calibration stuff will hang more than half the time if we reset everything but the CTL_PCI. I've gone back to just resetting _PCU and _BASEBAND for now. Maybe this wants a card-specific flag, or like Jiri's patch just skip the second reset?

Quoted 1 line

Have you tried 256 ? Also have you tried only setting lower dma size for rx ?

512 for tx definitely did not work. Will try 256 and let you know.

Quoted 7 lines

drivers/net/wireless/ath5k/hw.c int ath5k_hw_reset(struct ath5k_hw *ah, enum ieee80211_if_types op_mode, · line 1012

Quoted 5 lines

drivers/net/wireless/ath5k/hw.c +5 -0

+       if (ah->ah_mac_srev >= AR5K_SREV_VER_AR2424) {
+               ath5k_hw_reg_write(ah, 0x000100aa, 0x8118);
+               ath5k_hw_reg_write(ah, 0x00003210, 0x811c);
+               ath5k_hw_reg_write(ah, 0x00000052, 0x8108);
+               ath5k_hw_reg_write(ah, 0x001e1e1e, AR5K_TXPC);

Remove TXPC and see what happens...

Yep TXPC can absolutely go. 0x8118 can probably go away too. Still unsure about 811c/8108.

Quoted 1 line

Quoted 1 line
+ ath5k_hw_reg_write(ah, 0x00000004, 0x8120);

It never worked without this one.

Signature · 1 line

Bob Copeland %% www.bobcopeland.com