Re: Speed enhancement for BCM4306/2
Is this close?
E
--- /tmp/phy_g.c2008-09-05 21:06:57.0 -0700
+++ phy_g.c2008-09-05 21:36:18.0 -0700
@@ -2198,7 +2198,7 @@
else
b43_phy_initb6(dev);
-if (phy-rev = 2 || phy-gmode)
+if (phy-rev = 2 phy-gmode)
b43_phy_inita(dev);
if (phy-rev = 2) {
@@ -2216,9 +2216,9 @@
if (phy-gmode || phy-rev = 2) {
tmp = b43_phy_read(dev, B43_PHY_VERSION_OFDM);
tmp = B43_PHYVER_VERSION;
-if (tmp == 3 || tmp == 5) {
+if (tmp == 4 || tmp == 5) {
b43_phy_write(dev, B43_PHY_OFDM(0xC2), 0x1816);
-b43_phy_write(dev, B43_PHY_OFDM(0xC3), 0x8006);
+b43_phy_write(dev, B43_PHY_OFDM(0xC3), 0x8606);
}
if (tmp == 5) {
b43_phy_write(dev, B43_PHY_OFDM(0xCC),
@@ -2226,7 +2226,7 @@
0x00FF) | 0x1F00);
}
}
-if ((phy-rev = 2 phy-gmode) || phy-rev = 2)
+if ((phy-rev =2)
b43_phy_write(dev, B43_PHY_OFDM(0x7E), 0x78);
if (phy-radio_rev == 8) {
b43_phy_write(dev, B43_PHY_EXTG(0x01),
Larry Finger wrote:
I recently found some places where the G-PHY initialization
specifications were wrong. I updated the relevant parts of the V3
specifications at http://bcm-specs.sipsolutions.net - the pages for
GPHY, B6PHY and B5PHY were changed.
When I prepared a patch containing these changes, the speed of the
BCM4306/2 for OFDM rates more than doubled. As an example, when
iwconfig is used to set the rate at 36M, the TX rate increased from
6.8 to 15.8 Mb/s.
Unfortunately, direct submission of my patch would violate the
clean-room rules. Michael Buesch has other things that are more
important. As a result, we need someone to look at the changes on the
web page and prepare a patch for submission. I will be happy to test
your submission.
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed enhancement for BCM4306/2
On Saturday 06 September 2008 07:04:36 [EMAIL PROTECTED] wrote: +} +if (phy-rev = 2) b43legacy_phy_write(dev, 0x047E, 0x0078); } Does this even compile? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43: Fix QoS defaults
This fixes the initialization of the default QoS parameters.
This got broken by 0b57664cf2393bc1eff594ff7e5ff26533843fe6
Reported-by: Lorenzo Nava
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please queue for the next merge window, as I'm not interested
in finding explanations for applying this to 2.6.27 (2.6.27 already has
this bug)
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c 2008-09-06
15:09:16.0 +0200
+++ wireless-testing/drivers/net/wireless/b43/main.c2008-09-06
15:45:09.0 +0200
@@ -3056,37 +3056,40 @@ static void b43_qos_params_upload(struct
shm_offset + (i * 2),
params[i]);
}
}
}
+/* Mapping of mac80211 queue numbers to b43 QoS SHM offsets. */
+static const u16 b43_qos_shm_offsets[] = {
+ /* [mac80211-queue-nr] = SHM_OFFSET, */
+ [0] = B43_QOS_VOICE,
+ [1] = B43_QOS_VIDEO,
+ [2] = B43_QOS_BESTEFFORT,
+ [3] = B43_QOS_BACKGROUND,
+};
+
/* Update the QOS parameters in hardware. */
static void b43_qos_update(struct b43_wldev *dev)
{
struct b43_wl *wl = dev-wl;
struct b43_qos_params *params;
unsigned long flags;
unsigned int i;
- /* Mapping of mac80211 queues to b43 SHM offsets. */
- static const u16 qos_shm_offsets[] = {
- [0] = B43_QOS_VOICE,
- [1] = B43_QOS_VIDEO,
- [2] = B43_QOS_BESTEFFORT,
- [3] = B43_QOS_BACKGROUND,
- };
- BUILD_BUG_ON(ARRAY_SIZE(qos_shm_offsets) != ARRAY_SIZE(wl-qos_params));
+ BUILD_BUG_ON(ARRAY_SIZE(b43_qos_shm_offsets) !=
+ARRAY_SIZE(wl-qos_params));
b43_mac_suspend(dev);
spin_lock_irqsave(wl-irq_lock, flags);
for (i = 0; i ARRAY_SIZE(wl-qos_params); i++) {
params = (wl-qos_params[i]);
if (params-need_hw_update) {
b43_qos_params_upload(dev, (params-p),
- qos_shm_offsets[i]);
+ b43_qos_shm_offsets[i]);
params-need_hw_update = 0;
}
}
spin_unlock_irqrestore(wl-irq_lock, flags);
b43_mac_enable(dev);
@@ -3094,17 +3097,48 @@ static void b43_qos_update(struct b43_wl
static void b43_qos_clear(struct b43_wl *wl)
{
struct b43_qos_params *params;
unsigned int i;
+ /* Initialize QoS parameters to sane defaults. */
+
+ BUILD_BUG_ON(ARRAY_SIZE(b43_qos_shm_offsets) !=
+ARRAY_SIZE(wl-qos_params));
+
for (i = 0; i ARRAY_SIZE(wl-qos_params); i++) {
params = (wl-qos_params[i]);
- memset((params-p), 0, sizeof(params-p));
- params-p.aifs = -1;
+ switch (b43_qos_shm_offsets[i]) {
+ case B43_QOS_VOICE:
+ params-p.txop = 0;
+ params-p.aifs = 2;
+ params-p.cw_min = 0x0001;
+ params-p.cw_max = 0x0001;
+ break;
+ case B43_QOS_VIDEO:
+ params-p.txop = 0;
+ params-p.aifs = 2;
+ params-p.cw_min = 0x0001;
+ params-p.cw_max = 0x0001;
+ break;
+ case B43_QOS_BESTEFFORT:
+ params-p.txop = 0;
+ params-p.aifs = 3;
+ params-p.cw_min = 0x0001;
+ params-p.cw_max = 0x03FF;
+ break;
+ case B43_QOS_BACKGROUND:
+ params-p.txop = 0;
+ params-p.aifs = 7;
+ params-p.cw_min = 0x0001;
+ params-p.cw_max = 0x03FF;
+ break;
+ default:
+ B43_WARN_ON(1);
+ }
params-need_hw_update = 1;
}
}
/* Initialize the core's QOS capabilities */
static void b43_qos_init(struct b43_wldev *dev)
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed enhancement for BCM4306/2
[EMAIL PROTECTED] wrote:
Ok, here's try #2.
E
/home/2.6.27/rc4-wl/drivers/net/wireless/b43legacy# diff -uN /tmp/phy.c
phy.c
--- /tmp/phy.c2008-09-05 21:56:20.0 -0700
+++ phy.c2008-09-05 22:03:28.0 -0700
For kernel patches, you need to be working in the base directory of
the kernel sources. For your tree, that would be in
/home/2.6.27/rc4-wl. That way the patches will apply with the
effective command of 'patch -p1 patch_file'. For kernel patches, I
use quilt so that patches are easy to apply and remove.
@@ -1010,7 +1010,7 @@
b43legacy_phy_initb5(dev);
else
b43legacy_phy_initb6(dev);
-if (phy-rev = 2 || phy-gmode)
+if (phy-rev = 2 phy-gmode)
b43legacy_phy_inita(dev);
if (phy-rev = 2) {
The above hunk is correct.
@@ -1027,15 +1027,17 @@
}
if (phy-rev = 2 || phy-gmode) {
This does not match step 7 of the specs. It was not changed recently,
but the code did not match what was on the web site. No, I don't know why.
tmp = b43legacy_phy_read(dev, 0x0400) 0xFF;
-if (tmp == 3 || tmp == 5) {
+if (tmp == 4 || tmp == 5) {
b43legacy_phy_write(dev, 0x04C2, 0x1816);
-b43legacy_phy_write(dev, 0x04C3, 0x8006);
+b43legacy_phy_write(dev, 0x04C3, 0x8606);
if (tmp == 5)
b43legacy_phy_write(dev, 0x04CC,
(b43legacy_phy_read(dev,
0x04CC) 0x00FF) |
0x1F00);
}
+}
+if (phy-rev = 2)
b43legacy_phy_write(dev, 0x047E, 0x0078);
}
if (phy-radio_rev == 8) {
This hunk does not match the specs. In addition, I think there are too
many right-hand curly braces for it to compile.
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43 G-PHY: Remove mmiowb()
It causes compile errors on m68k and it is not needed.
Remove it.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
---
John, please queue for the next merge window.
Index: wireless-testing/drivers/net/wireless/b43/phy_g.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/phy_g.c 2008-09-06
15:06:56.0 +0200
+++ wireless-testing/drivers/net/wireless/b43/phy_g.c 2008-09-06
19:24:35.0 +0200
@@ -383,13 +383,12 @@ static void b43_set_original_gains(struc
}
/* http://bcm-specs.sipsolutions.net/NRSSILookupTable */
void b43_nrssi_hw_write(struct b43_wldev *dev, u16 offset, s16 val)
{
b43_phy_write(dev, B43_PHY_NRSSILT_CTRL, offset);
- mmiowb();
b43_phy_write(dev, B43_PHY_NRSSILT_DATA, (u16) val);
}
/* http://bcm-specs.sipsolutions.net/NRSSILookupTable */
s16 b43_nrssi_hw_read(struct b43_wldev *dev, u16 offset)
{
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed enhancement for BCM4306/2
Larry Finger wrote:
[EMAIL PROTECTED] wrote:
Ok, here's try #2.
E
/home/2.6.27/rc4-wl/drivers/net/wireless/b43legacy# diff -uN
/tmp/phy.c phy.c
--- /tmp/phy.c2008-09-05 21:56:20.0 -0700
+++ phy.c2008-09-05 22:03:28.0 -0700
For kernel patches, you need to be working in the base directory of
the kernel sources. For your tree, that would be in
/home/2.6.27/rc4-wl. That way the patches will apply with the
effective command of 'patch -p1 patch_file'. For kernel patches, I
use quilt so that patches are easy to apply and remove.
@@ -1010,7 +1010,7 @@
b43legacy_phy_initb5(dev);
else
b43legacy_phy_initb6(dev);
-if (phy-rev = 2 || phy-gmode)
+if (phy-rev = 2 phy-gmode)
b43legacy_phy_inita(dev);
if (phy-rev = 2) {
The above hunk is correct.
@@ -1027,15 +1027,17 @@
}
if (phy-rev = 2 || phy-gmode) {
This does not match step 7 of the specs. It was not changed recently,
but the code did not match what was on the web site. No, I don't know
why.
tmp = b43legacy_phy_read(dev, 0x0400) 0xFF;
-if (tmp == 3 || tmp == 5) {
+if (tmp == 4 || tmp == 5) {
b43legacy_phy_write(dev, 0x04C2, 0x1816);
-b43legacy_phy_write(dev, 0x04C3, 0x8006);
+b43legacy_phy_write(dev, 0x04C3, 0x8606);
if (tmp == 5)
b43legacy_phy_write(dev, 0x04CC,
(b43legacy_phy_read(dev,
0x04CC) 0x00FF) |
0x1F00);
}
+}
+if (phy-rev = 2)
b43legacy_phy_write(dev, 0x047E, 0x0078);
}
if (phy-radio_rev == 8) {
This hunk does not match the specs. In addition, I think there are too
many right-hand curly braces for it to compile.
Larry
I've been sitting on a git clone that refuses to proceed faster than 6
KiB/s (it's a problem here in Melbourne). Should it complete I will
correct these issues. I did see several other ways in which the code
does not match the specs. Should that be documented in the code or
should the code be conformed to the specs even if that ends up breaking
the driver?
Without getting into specifics it's cases where the specs will say When
something=value but the code says when variable =(value -1).
Ehud
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed enhancement for BCM4306/2
On Saturday 06 September 2008 20:07:15 [EMAIL PROTECTED] wrote: correct these issues. I did see several other ways in which the code does not match the specs. Should that be documented in the code or should the code be conformed to the specs even if that ends up breaking the driver? You're really considering breaking the driver just to conform the specs? Without getting into specifics it's cases where the specs will say When something=value but the code says when variable =(value -1). Please show us the code, so we can give you advise. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43legacy: Fix failure in rate-adjustment mechanism
A coding error present since b43legacy was incorporated into the
kernel has prevented the driver from using the rate-setting mechanism
of mac80211. The driver has been forced to remain at a 1 Mb/s rate.
Signed-off-by: Larry Finger [EMAIL PROTECTED]
Cc: Stable [EMAIL PROTECTED] [2.6.26], [2.6.25]
---
John,
Although this is not strictly a regression, it is a bug. I hope
it can be sent to 2.6.27.
Thanks,
Larry
---
Index: wireless-testing/drivers/net/wireless/b43legacy/xmit.c
===
--- wireless-testing.orig/drivers/net/wireless/b43legacy/xmit.c
+++ wireless-testing/drivers/net/wireless/b43legacy/xmit.c
@@ -629,7 +629,7 @@ void b43legacy_handle_hwtxstatus(struct
status.pm_indicated = !!(tmp 0x80);
status.intermediate = !!(tmp 0x40);
status.for_ampdu = !!(tmp 0x20);
- status.acked = !!(tmp 0x02);
+ status.acked = tmp 0x01;
b43legacy_handle_txstatus(dev, status);
}
Index: wireless-testing/drivers/net/wireless/b43legacy/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43legacy/main.c
+++ wireless-testing/drivers/net/wireless/b43legacy/main.c
@@ -744,7 +744,7 @@ static void handle_irq_transmit_status(s
while (1) {
v0 = b43legacy_read32(dev, B43legacy_MMIO_XMITSTAT_0);
- if (!(v0 0x0001))
+ if (!v0)
break;
v1 = b43legacy_read32(dev, B43legacy_MMIO_XMITSTAT_1);
@@ -758,7 +758,7 @@ static void handle_irq_transmit_status(s
stat.pm_indicated = !!(tmp 0x0080);
stat.intermediate = !!(tmp 0x0040);
stat.for_ampdu = !!(tmp 0x0020);
- stat.acked = !!(tmp 0x0002);
+ stat.acked = tmp 0x0001;
b43legacy_handle_txstatus(dev, stat);
}
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43legacy: Fix failure in rate-adjustment mechanism
On Saturday 06 September 2008 20:34:02 Larry Finger wrote: A coding error present since b43legacy was incorporated into the kernel has prevented the driver from using the rate-setting mechanism of mac80211. The driver has been forced to remain at a 1 Mb/s rate. Does version3 firmware have a different bitlayout for the status? Although this is not strictly a regression, it is a bug. I hope it can be sent to 2.6.27. The new rules don't allow us to fix bugs after the merge window. Only regressions. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43legacy: Fix failure in rate-adjustment mechanism
Michael Buesch wrote: On Saturday 06 September 2008 20:34:02 Larry Finger wrote: A coding error present since b43legacy was incorporated into the kernel has prevented the driver from using the rate-setting mechanism of mac80211. The driver has been forced to remain at a 1 Mb/s rate. Does version3 firmware have a different bitlayout for the status? It seems so. I found this because I was not getting any acks back to net/mac80211/rc80211_pid_algo.c. I then reviewed the V3 specs, found that bit 0, not bit 1, contained the ack. Test prints confirmed that result. With this patch, both my BCM4306/2 and BCM4303 reach the maximum rate. With the current code, 54 Mb/s is not as fast as 36 Mb/s, but at least the algorithm is working. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43legacy: Fix failure in rate-adjustment mechanism
On Saturday 06 September 2008 20:52:53 Larry Finger wrote: Michael Buesch wrote: On Saturday 06 September 2008 20:34:02 Larry Finger wrote: A coding error present since b43legacy was incorporated into the kernel has prevented the driver from using the rate-setting mechanism of mac80211. The driver has been forced to remain at a 1 Mb/s rate. Does version3 firmware have a different bitlayout for the status? It seems so. I found this because I was not getting any acks back to net/mac80211/rc80211_pid_algo.c. I then reviewed the V3 specs, found that bit 0, not bit 1, contained the ack. Test prints confirmed that result. With this patch, both my BCM4306/2 and BCM4303 reach the maximum rate. With the current code, 54 Mb/s is not as fast as 36 Mb/s, but at least the algorithm is working. Yeah ok. I just asked, because it seems the _whole_ flags bitfield is rightshifted by one (so the other flags are wrong, too. See the intermediate flag) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed enhancement for BCM4306/2
[EMAIL PROTECTED] wrote: I've been sitting on a git clone that refuses to proceed faster than 6 KiB/s (it's a problem here in Melbourne). Should it complete I will correct these issues. I did see several other ways in which the code does not match the specs. Should that be documented in the code or should the code be conformed to the specs even if that ends up breaking the driver? Without getting into specifics it's cases where the specs will say When something=value but the code says when variable =(value -1). As Michael said, we need to see the specifics. Those specs have not been updated for a long time, and there are certainly errors in them. The only thing I can say with certainty is that in step 7 of the GPHY page, the specs are right and the code is wrong. That has been tested! Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43legacy: Fix failure in rate-adjustment mechanism
On Saturday 06 September 2008 20:57:50 Johannes Berg wrote: On Sat, 2008-09-06 at 20:55 +0200, Michael Buesch wrote: On Saturday 06 September 2008 20:52:53 Larry Finger wrote: Michael Buesch wrote: On Saturday 06 September 2008 20:34:02 Larry Finger wrote: A coding error present since b43legacy was incorporated into the kernel has prevented the driver from using the rate-setting mechanism of mac80211. The driver has been forced to remain at a 1 Mb/s rate. Does version3 firmware have a different bitlayout for the status? It seems so. I found this because I was not getting any acks back to net/mac80211/rc80211_pid_algo.c. I then reviewed the V3 specs, found that bit 0, not bit 1, contained the ack. Test prints confirmed that result. With this patch, both my BCM4306/2 and BCM4303 reach the maximum rate. With the current code, 54 Mb/s is not as fast as 36 Mb/s, but at least the algorithm is working. Yeah ok. I just asked, because it seems the _whole_ flags bitfield is rightshifted by one (so the other flags are wrong, too. See the intermediate flag) It is, this isn't really a difference between the two but a result of you shifting it up/down due to the tx status via dma queue vs. tx status via registers thing. Yeah, that's the point. larry's patch modified both the register and dmaqueue mechanism. I think the register mechanism might be correct as-is (Or is it even dead code and it's not used by any legacy device?) -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43legacy: Fix failure in rate-adjustment mechanism
On Sat, 2008-09-06 at 20:55 +0200, Michael Buesch wrote: On Saturday 06 September 2008 20:52:53 Larry Finger wrote: Michael Buesch wrote: On Saturday 06 September 2008 20:34:02 Larry Finger wrote: A coding error present since b43legacy was incorporated into the kernel has prevented the driver from using the rate-setting mechanism of mac80211. The driver has been forced to remain at a 1 Mb/s rate. Does version3 firmware have a different bitlayout for the status? It seems so. I found this because I was not getting any acks back to net/mac80211/rc80211_pid_algo.c. I then reviewed the V3 specs, found that bit 0, not bit 1, contained the ack. Test prints confirmed that result. With this patch, both my BCM4306/2 and BCM4303 reach the maximum rate. With the current code, 54 Mb/s is not as fast as 36 Mb/s, but at least the algorithm is working. Yeah ok. I just asked, because it seems the _whole_ flags bitfield is rightshifted by one (so the other flags are wrong, too. See the intermediate flag) It is, this isn't really a difference between the two but a result of you shifting it up/down due to the tx status via dma queue vs. tx status via registers thing. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43legacy: Fix failure in rate-adjustment mechanism
Michael Buesch wrote:
On Saturday 06 September 2008 20:57:50 Johannes Berg wrote:
It is, this isn't really a difference between the two but a result of
you shifting it up/down due to the tx status via dma queue vs. tx status
via registers thing.
Yeah, that's the point. larry's patch modified both the register and dmaqueue
mechanism. I think the register mechanism might be correct as-is (Or is it
even
dead code and it's not used by any legacy device?)
I modified the patch to add printouts in both paths as shown below:
Index: linux-2.6/drivers/net/wireless/b43legacy/xmit.c
===
--- linux-2.6.orig/drivers/net/wireless/b43legacy/xmit.c
+++ linux-2.6/drivers/net/wireless/b43legacy/xmit.c
@@ -631,7 +631,8 @@ void b43legacy_handle_hwtxstatus(struct
status.pm_indicated = !!(tmp 0x80);
status.intermediate = !!(tmp 0x40);
status.for_ampdu = !!(tmp 0x20);
- status.acked = !!(tmp 0x02);
+ status.acked = tmp 0x01;
+ printk(KERN_INFO b43legacy: In b43legacy_handle_hwtxstatus,
hw-flags = 0x%X\n, hw-flags);
b43legacy_handle_txstatus(dev, status);
}
Index: linux-2.6/drivers/net/wireless/b43legacy/main.c
===
--- linux-2.6.orig/drivers/net/wireless/b43legacy/main.c
+++ linux-2.6/drivers/net/wireless/b43legacy/main.c
@@ -744,7 +744,7 @@ static void handle_irq_transmit_status(s
while (1) {
v0 = b43legacy_read32(dev, B43legacy_MMIO_XMITSTAT_0);
- if (!(v0 0x0001))
+ if (!v0)
break;
v1 = b43legacy_read32(dev, B43legacy_MMIO_XMITSTAT_1);
@@ -752,13 +752,14 @@ static void handle_irq_transmit_status(s
stat.seq = (v1 0x);
stat.phy_stat = ((v1 0x00FF) 16);
tmp = (v0 0x);
+ printk(KERN_INFO b43legacy: In
handle_irq_transmit_status, tmp 0x%X\n, tmp);
stat.frame_count = ((tmp 0xF000) 12);
stat.rts_count = ((tmp 0x0F00) 8);
stat.supp_reason = ((tmp 0x001C) 2);
stat.pm_indicated = !!(tmp 0x0080);
stat.intermediate = !!(tmp 0x0040);
stat.for_ampdu = !!(tmp 0x0020);
- stat.acked = !!(tmp 0x0002);
+ stat.acked = tmp 0x0001;
b43legacy_handle_txstatus(dev, stat);
}
What I see are lots of
b43legacy: In b43legacy_handle_hwtxstatus, hw-flags = 0x1
and this is the only one that ever triggered. ATM, I'm not sure why
handle_irq_transmit_status() is not called.
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43legacy: Fix failure in rate-adjustment mechanism
On Sat, 2008-09-06 at 14:36 -0500, Larry Finger wrote:
What I see are lots of
b43legacy: In b43legacy_handle_hwtxstatus, hw-flags = 0x1
and this is the only one that ever triggered. ATM, I'm not sure why
handle_irq_transmit_status() is not called.
The mechanism depends on the card revision, but according to
drivers/net/wireless/b43legacy/dma.c it's always via the dma/pio
mechanism for legacy cards:
if (dev-dev-id.revision 5) {
ring = b43legacy_setup_dmaring(dev, 3, 0, type);
if (!ring)
goto err_destroy_rx0;
dma-rx_ring3 = ring;
}
johannes
signature.asc
Description: This is a digitally signed message part
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43legacy: Fix failure in rate-adjustment mechanism
Johannes Berg wrote:
The mechanism depends on the card revision, but according to
drivers/net/wireless/b43legacy/dma.c it's always via the dma/pio
mechanism for legacy cards:
if (dev-dev-id.revision 5) {
ring = b43legacy_setup_dmaring(dev, 3, 0, type);
if (!ring)
goto err_destroy_rx0;
dma-rx_ring3 = ring;
}
In the V3 specs, I found
Transmit Status
When this interrupt is set, the retrieve the TransmitStatus. Note that
on cores with revision 5, the last DMA controller or PIO queue can
also also get the DMA recieve done interrupt, which also triggers the
TransmitStatus retrieval process. The driver should be prepared to
deal with both interrupts at any time, on any revision. In AP mode,
this interrupt also initiates the sending of powersave responses.
The implication is that the interrupt will only be generated if we use
the last (i.e. #5) DMA controller. As we are only using #3, no
interrupts and handle_irq_status() is dead code.
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43legacy: Fix failure in rate-adjustment mechanism
On Sat, 2008-09-06 at 14:59 -0500, Larry Finger wrote: In the V3 specs, I found Transmit Status When this interrupt is set, the retrieve the TransmitStatus. Note that on cores with revision 5, the last DMA controller or PIO queue can also also get the DMA recieve done interrupt, which also triggers the TransmitStatus retrieval process. The driver should be prepared to deal with both interrupts at any time, on any revision. In AP mode, this interrupt also initiates the sending of powersave responses. Yeah, this isn't entirely correct, when the core revision is 5 then the register-based TX status doesn't actually exist and the firmware always uses the FIFO-based mechanism. The implication is that the interrupt will only be generated if we use the last (i.e. #5) DMA controller. As we are only using #3, no interrupts and handle_irq_status() is dead code. Right, only core revisions 2 and 4 are supported here. johannes signature.asc Description: This is a digitally signed message part ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism
A coding error present since b43legacy was incorporated into the kernel has prevented the driver from using the rate-setting mechanism of mac80211. The driver has been forced to remain at a 1 Mb/s rate. Signed-off-by: Larry Finger [EMAIL PROTECTED] Cc: Stable [EMAIL PROTECTED] [2.6.26], [2.6.25] --- John, This is a bug, not a regression. I guess under the new rules that it is 2.6.28 material. Thanks, Larry --- Index: wireless-testing/drivers/net/wireless/b43legacy/xmit.c === --- wireless-testing.orig/drivers/net/wireless/b43legacy/xmit.c +++ wireless-testing/drivers/net/wireless/b43legacy/xmit.c @@ -624,7 +624,7 @@ void b43legacy_handle_hwtxstatus(struct tmp = hw-count; status.frame_count = (tmp 4); status.rts_count = (tmp 0x0F); - tmp = hw-flags; + tmp = hw-flags 1; status.supp_reason = ((tmp 0x1C) 2); status.pm_indicated = !!(tmp 0x80); status.intermediate = !!(tmp 0x40); ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] b43legacy: Fix failure in rate-adjustment mechanism
On Saturday 06 September 2008 23:51:22 Larry Finger wrote: A coding error present since b43legacy was incorporated into the kernel has prevented the driver from using the rate-setting mechanism of mac80211. The driver has been forced to remain at a 1 Mb/s rate. Signed-off-by: Larry Finger [EMAIL PROTECTED] Cc: Stable [EMAIL PROTECTED][2.6.26], [2.6.25] Reviewed-by: Michael Buesch [EMAIL PROTECTED] --- John, This is a bug, not a regression. I guess under the new rules that it is 2.6.28 material. I wonder what the -stable rules are. It seems really screwed to me to avoid applying the fix to 2.6.27, but still apply it to 2.6.25/26-stable. I'd like to see this patch in .25, .26 and .27, however I'm not sure what the rules are. For reference: Three people agree on the correctness of the patch, it's a oneliner and it's tested to fix the bug. However it is not a regression. The bug is in there since day-0 of b43legacy. But this fix improves TX rates a lot. Index: wireless-testing/drivers/net/wireless/b43legacy/xmit.c === --- wireless-testing.orig/drivers/net/wireless/b43legacy/xmit.c +++ wireless-testing/drivers/net/wireless/b43legacy/xmit.c @@ -624,7 +624,7 @@ void b43legacy_handle_hwtxstatus(struct tmp = hw-count; status.frame_count = (tmp 4); status.rts_count = (tmp 0x0F); - tmp = hw-flags; + tmp = hw-flags 1; status.supp_reason = ((tmp 0x1C) 2); status.pm_indicated = !!(tmp 0x80); status.intermediate = !!(tmp 0x40); -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed enhancement for BCM4306/2
Larry Finger wrote:
[EMAIL PROTECTED] wrote:
Ok, here's try #2.
E
...
This hunk does not match the specs. In addition, I think there are too
many right-hand curly braces for it to compile.
Larry
I haven't tried a build yet, but please let me know if I'm on the right
track.
E
# diff -uN /tmp/phy.c drivers/net/wireless/b43legacy/phy.c
--- /tmp/phy.c2008-09-06 15:13:33.0 -0700
+++ drivers/net/wireless/b43legacy/phy.c2008-09-06
15:54:03.0 -0700
@@ -1010,7 +1010,7 @@
b43legacy_phy_initb5(dev);
else
b43legacy_phy_initb6(dev);
-if (phy-rev = 2 || phy-gmode)
+if (phy-rev = 2 phy-gmode)
b43legacy_phy_inita(dev);
if (phy-rev = 2) {
@@ -1021,21 +1021,26 @@
b43legacy_phy_write(dev, 0x0811, 0x);
b43legacy_phy_write(dev, 0x0015, 0x00C0);
}
-if (phy-rev 5) {
+if (phy-rev = 3) {
b43legacy_phy_write(dev, 0x0811, 0x0400);
b43legacy_phy_write(dev, 0x0015, 0x00C0);
}
-if (phy-rev = 2 || phy-gmode) {
+if (phy-gmode) {
tmp = b43legacy_phy_read(dev, 0x0400) 0xFF;
-if (tmp == 3 || tmp == 5) {
+if (tmp == 3) {
+b43legacy_phy_write(dev, 0x04C2, 0x1816);
+b43legacy_phy_write(dev, 0x04C3, 0x8606);
+}
+if (tmp == 4 || tmp == 5) {
b43legacy_phy_write(dev, 0x04C2, 0x1816);
b43legacy_phy_write(dev, 0x04C3, 0x8006);
-if (tmp == 5)
-b43legacy_phy_write(dev, 0x04CC,
-(b43legacy_phy_read(dev,
- 0x04CC) 0x00FF) |
- 0x1F00);
+b43legacy_phy_write(dev, 0x04CC,
+(b43legacy_phy_read(dev,
+0x04CC) 0x00FF) |
+0x1F00);
}
+}
+if (phy--rev = 2)
b43legacy_phy_write(dev, 0x047E, 0x0078);
}
if (phy-radio_rev == 8) {
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed enhancement for BCM4306/2
[EMAIL PROTECTED] wrote:
I haven't tried a build yet, but please let me know if I'm on the right
track.
E
# diff -uN /tmp/phy.c drivers/net/wireless/b43legacy/phy.c
--- /tmp/phy.c2008-09-06 15:13:33.0 -0700
+++ drivers/net/wireless/b43legacy/phy.c2008-09-06
15:54:03.0 -0700
@@ -1010,7 +1010,7 @@
b43legacy_phy_initb5(dev);
else
b43legacy_phy_initb6(dev);
-if (phy-rev = 2 || phy-gmode)
+if (phy-rev = 2 phy-gmode)
b43legacy_phy_inita(dev);
if (phy-rev = 2) {
@@ -1021,21 +1021,26 @@
b43legacy_phy_write(dev, 0x0811, 0x);
b43legacy_phy_write(dev, 0x0015, 0x00C0);
}
-if (phy-rev 5) {
+if (phy-rev = 3) {
AFAIK, this change is an error in the specs. I have since changed it.
Sorry I didn't catch it earlier.
Otherwise, this patch seems to be correct. All you need now are the
fixes for b43legacy_phy_initb5() and b43legacy_phy_initb6().
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed enhancement for BCM4306/2
Larry Finger wrote:
[EMAIL PROTECTED] wrote:
I haven't tried a build yet, but please let me know if I'm on the
right track.
E
# diff -uN /tmp/phy.c drivers/net/wireless/b43legacy/phy.c
--- /tmp/phy.c2008-09-06 15:13:33.0 -0700
+++ drivers/net/wireless/b43legacy/phy.c2008-09-06
15:54:03.0 -0700
@@ -1010,7 +1010,7 @@
b43legacy_phy_initb5(dev);
else
b43legacy_phy_initb6(dev);
-if (phy-rev = 2 || phy-gmode)
+if (phy-rev = 2 phy-gmode)
b43legacy_phy_inita(dev);
if (phy-rev = 2) {
@@ -1021,21 +1021,26 @@
b43legacy_phy_write(dev, 0x0811, 0x);
b43legacy_phy_write(dev, 0x0015, 0x00C0);
}
-if (phy-rev 5) {
+if (phy-rev = 3) {
AFAIK, this change is an error in the specs. I have since changed it.
Sorry I didn't catch it earlier.
Otherwise, this patch seems to be correct. All you need now are the
fixes for b43legacy_phy_initb5() and b43legacy_phy_initb6().
Larry
Ok, I've re-looked at the specs and made the appropriate corrections.
I've also gone through all of the PHY specs and found one other
correction. It's enclosed below for review.
Where do I go to find the stuff for ...initb5() and ...initb6()?
Thanks
E
# diff -uN /tmp/phy.c drivers/net/wireless/b43legacy/phy.c
--- /tmp/phy.c2008-09-06 15:13:33.0 -0700
+++ drivers/net/wireless/b43legacy/phy.c2008-09-06
16:42:40.0 -0700
@@ -1010,7 +1010,7 @@
b43legacy_phy_initb5(dev);
else
b43legacy_phy_initb6(dev);
-if (phy-rev = 2 || phy-gmode)
+if (phy-rev = 2 phy-gmode)
b43legacy_phy_inita(dev);
if (phy-rev = 2) {
@@ -1025,17 +1025,22 @@
b43legacy_phy_write(dev, 0x0811, 0x0400);
b43legacy_phy_write(dev, 0x0015, 0x00C0);
}
-if (phy-rev = 2 || phy-gmode) {
+if (phy-gmode) {
tmp = b43legacy_phy_read(dev, 0x0400) 0xFF;
-if (tmp == 3 || tmp == 5) {
+if (tmp == 3) {
+b43legacy_phy_write(dev, 0x04C2, 0x1816);
+b43legacy_phy_write(dev, 0x04C3, 0x8606);
+}
+if (tmp == 4 || tmp == 5) {
b43legacy_phy_write(dev, 0x04C2, 0x1816);
b43legacy_phy_write(dev, 0x04C3, 0x8006);
-if (tmp == 5)
-b43legacy_phy_write(dev, 0x04CC,
-(b43legacy_phy_read(dev,
- 0x04CC) 0x00FF) |
- 0x1F00);
+b43legacy_phy_write(dev, 0x04CC,
+(b43legacy_phy_read(dev,
+0x04CC) 0x00FF) |
+0x1F00);
}
+}
+if (phy--rev = 2)
b43legacy_phy_write(dev, 0x047E, 0x0078);
}
if (phy-radio_rev == 8) {
@@ -1092,7 +1097,7 @@
*/
b43legacy_nrssi_hw_update(dev, 0x);
b43legacy_calc_nrssi_threshold(dev);
-} else if (phy-gmode || phy-rev = 2) {
+} else if (phy-gmode) {
if (phy-nrssi[0] == -1000) {
B43legacy_WARN_ON(phy-nrssi[1] != -1000);
b43legacy_calc_nrssi_slope(dev);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed enhancement for BCM4306/2
Larry Finger wrote:
[EMAIL PROTECTED] wrote:
I haven't tried a build yet, but please let me know if I'm on the
right track.
E
# diff -uN /tmp/phy.c drivers/net/wireless/b43legacy/phy.c
--- /tmp/phy.c2008-09-06 15:13:33.0 -0700
+++ drivers/net/wireless/b43legacy/phy.c2008-09-06
15:54:03.0 -0700
@@ -1010,7 +1010,7 @@
b43legacy_phy_initb5(dev);
else
b43legacy_phy_initb6(dev);
-if (phy-rev = 2 || phy-gmode)
+if (phy-rev = 2 phy-gmode)
b43legacy_phy_inita(dev);
if (phy-rev = 2) {
@@ -1021,21 +1021,26 @@
b43legacy_phy_write(dev, 0x0811, 0x);
b43legacy_phy_write(dev, 0x0015, 0x00C0);
}
-if (phy-rev 5) {
+if (phy-rev = 3) {
AFAIK, this change is an error in the specs. I have since changed it.
Sorry I didn't catch it earlier.
Otherwise, this patch seems to be correct. All you need now are the
fixes for b43legacy_phy_initb5() and b43legacy_phy_initb6().
Larry
Ok, this one applies changes to the PHY, B5PHY, and B6PHY changes.
E
# diff -uN /tmp/phy.c drivers/net/wireless/b43legacy/phy.c
--- /tmp/phy.c2008-09-06 15:13:33.0 -0700
+++ drivers/net/wireless/b43legacy/phy.c2008-09-06
17:13:31.0 -0700
@@ -595,12 +595,14 @@
0x0035) 0xFFC0) | 0x0064);
b43legacy_phy_write(dev, 0x005D, (b43legacy_phy_read(dev,
0x005D) 0xFF80) | 0x000A);
+b43legacy_phy_write(dev, 0x5B, 0x);
+b43legacy_phy_write(dev, 0x5C, 0x);
}
if (dev-bad_frames_preempt)
b43legacy_phy_write(dev, B43legacy_PHY_RADIO_BITFIELD,
b43legacy_phy_read(dev,
-B43legacy_PHY_RADIO_BITFIELD) | (1 11));
+B43legacy_PHY_RADIO_BITFIELD) | (1 12));
if (phy-analog == 1) {
b43legacy_phy_write(dev, 0x0026, 0xCE00);
@@ -771,7 +773,7 @@
b43legacy_phy_write(dev, 0x002A, 0x8AC0);
b43legacy_phy_write(dev, 0x0038, 0x0668);
b43legacy_radio_set_txpower_bg(dev, 0x, 0x, 0x);
-if (phy-radio_rev = 5)
+if (phy-radio_rev == 4 || phy-radio_rev == 5)
b43legacy_phy_write(dev, 0x005D, (b43legacy_phy_read(dev,
0x005D) 0xFF80) | 0x0003);
if (phy-radio_rev = 2)
@@ -1010,7 +1012,7 @@
b43legacy_phy_initb5(dev);
else
b43legacy_phy_initb6(dev);
-if (phy-rev = 2 || phy-gmode)
+if (phy-rev = 2 phy-gmode)
b43legacy_phy_inita(dev);
if (phy-rev = 2) {
@@ -1025,17 +1027,22 @@
b43legacy_phy_write(dev, 0x0811, 0x0400);
b43legacy_phy_write(dev, 0x0015, 0x00C0);
}
-if (phy-rev = 2 || phy-gmode) {
+if (phy-gmode) {
tmp = b43legacy_phy_read(dev, 0x0400) 0xFF;
-if (tmp == 3 || tmp == 5) {
+if (tmp == 3) {
+b43legacy_phy_write(dev, 0x04C2, 0x1816);
+b43legacy_phy_write(dev, 0x04C3, 0x8606);
+}
+if (tmp == 4 || tmp == 5) {
b43legacy_phy_write(dev, 0x04C2, 0x1816);
b43legacy_phy_write(dev, 0x04C3, 0x8006);
-if (tmp == 5)
-b43legacy_phy_write(dev, 0x04CC,
-(b43legacy_phy_read(dev,
- 0x04CC) 0x00FF) |
- 0x1F00);
+b43legacy_phy_write(dev, 0x04CC,
+(b43legacy_phy_read(dev,
+0x04CC) 0x00FF) |
+0x1F00);
}
+}
+if (phy--rev = 2)
b43legacy_phy_write(dev, 0x047E, 0x0078);
}
if (phy-radio_rev == 8) {
@@ -1092,7 +1099,7 @@
*/
b43legacy_nrssi_hw_update(dev, 0x);
b43legacy_calc_nrssi_threshold(dev);
-} else if (phy-gmode || phy-rev = 2) {
+} else if (phy-gmode) {
if (phy-nrssi[0] == -1000) {
B43legacy_WARN_ON(phy-nrssi[1] != -1000);
b43legacy_calc_nrssi_slope(dev);
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed enhancement for BCM4306/2
[EMAIL PROTECTED] wrote:
Larry Finger wrote:
[EMAIL PROTECTED] wrote:
I haven't tried a build yet, but please let me know if I'm on the
right track.
E
# diff -uN /tmp/phy.c drivers/net/wireless/b43legacy/phy.c
--- /tmp/phy.c2008-09-06 15:13:33.0 -0700
+++ drivers/net/wireless/b43legacy/phy.c2008-09-06
15:54:03.0 -0700
@@ -1010,7 +1010,7 @@
b43legacy_phy_initb5(dev);
else
b43legacy_phy_initb6(dev);
-if (phy-rev = 2 || phy-gmode)
+if (phy-rev = 2 phy-gmode)
b43legacy_phy_inita(dev);
if (phy-rev = 2) {
@@ -1021,21 +1021,26 @@
b43legacy_phy_write(dev, 0x0811, 0x);
b43legacy_phy_write(dev, 0x0015, 0x00C0);
}
-if (phy-rev 5) {
+if (phy-rev = 3) {
AFAIK, this change is an error in the specs. I have since changed it.
Sorry I didn't catch it earlier.
Otherwise, this patch seems to be correct. All you need now are the
fixes for b43legacy_phy_initb5() and b43legacy_phy_initb6().
Larry
Ok, I've re-looked at the specs and made the appropriate corrections.
I've also gone through all of the PHY specs and found one other
correction. It's enclosed below for review.
Where do I go to find the stuff for ...initb5() and ...initb6()?
That one was also an error in the specs - fixed now.
On the V3 specifications site, click on the RecentChanges button and
select B5PHY and B6PHY to get the specs for the other routines. I
rechecked the specs, and all agree with my current (revised) routines.
Larry
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed enhancement for BCM4306/2
Larry Finger wrote:
[EMAIL PROTECTED] wrote:
Larry Finger wrote:
[EMAIL PROTECTED] wrote:
I haven't tried a build yet, but please let me know if I'm on the
right track.
E
# diff -uN /tmp/phy.c drivers/net/wireless/b43legacy/phy.c
--- /tmp/phy.c2008-09-06 15:13:33.0 -0700
+++ drivers/net/wireless/b43legacy/phy.c2008-09-06
15:54:03.0 -0700
@@ -1010,7 +1010,7 @@
b43legacy_phy_initb5(dev);
else
b43legacy_phy_initb6(dev);
-if (phy-rev = 2 || phy-gmode)
+if (phy-rev = 2 phy-gmode)
b43legacy_phy_inita(dev);
if (phy-rev = 2) {
@@ -1021,21 +1021,26 @@
b43legacy_phy_write(dev, 0x0811, 0x);
b43legacy_phy_write(dev, 0x0015, 0x00C0);
}
-if (phy-rev 5) {
+if (phy-rev = 3) {
AFAIK, this change is an error in the specs. I have since changed
it. Sorry I didn't catch it earlier.
Otherwise, this patch seems to be correct. All you need now are the
fixes for b43legacy_phy_initb5() and b43legacy_phy_initb6().
Larry
Ok, I've re-looked at the specs and made the appropriate
corrections. I've also gone through all of the PHY specs and found
one other correction. It's enclosed below for review.
Where do I go to find the stuff for ...initb5() and ...initb6()?
That one was also an error in the specs - fixed now.
On the V3 specifications site, click on the RecentChanges button and
select B5PHY and B6PHY to get the specs for the other routines. I
rechecked the specs, and all agree with my current (revised) routines.
Larry
Try #5:
# diff -uN /tmp/phy.c drivers/net/wireless/b43legacy/phy.c
--- /tmp/phy.c2008-09-06 15:13:33.0 -0700
+++ drivers/net/wireless/b43legacy/phy.c2008-09-06
17:24:29.0 -0700
@@ -595,12 +595,14 @@
0x0035) 0xFFC0) | 0x0064);
b43legacy_phy_write(dev, 0x005D, (b43legacy_phy_read(dev,
0x005D) 0xFF80) | 0x000A);
+b43legacy_phy_write(dev, 0x5B, 0x);
+b43legacy_phy_write(dev, 0x5C, 0x);
}
if (dev-bad_frames_preempt)
b43legacy_phy_write(dev, B43legacy_PHY_RADIO_BITFIELD,
b43legacy_phy_read(dev,
-B43legacy_PHY_RADIO_BITFIELD) | (1 11));
+B43legacy_PHY_RADIO_BITFIELD) | (1 12));
if (phy-analog == 1) {
b43legacy_phy_write(dev, 0x0026, 0xCE00);
@@ -771,7 +773,7 @@
b43legacy_phy_write(dev, 0x002A, 0x8AC0);
b43legacy_phy_write(dev, 0x0038, 0x0668);
b43legacy_radio_set_txpower_bg(dev, 0x, 0x, 0x);
-if (phy-radio_rev = 5)
+if (phy-radio_rev == 4 || phy-radio_rev == 5)
b43legacy_phy_write(dev, 0x005D, (b43legacy_phy_read(dev,
0x005D) 0xFF80) | 0x0003);
if (phy-radio_rev = 2)
@@ -1010,7 +1012,7 @@
b43legacy_phy_initb5(dev);
else
b43legacy_phy_initb6(dev);
-if (phy-rev = 2 || phy-gmode)
+if (phy-rev = 2 phy-gmode)
b43legacy_phy_inita(dev);
if (phy-rev = 2) {
@@ -1025,17 +1027,22 @@
b43legacy_phy_write(dev, 0x0811, 0x0400);
b43legacy_phy_write(dev, 0x0015, 0x00C0);
}
-if (phy-rev = 2 || phy-gmode) {
+if (phy-gmode) {
tmp = b43legacy_phy_read(dev, 0x0400) 0xFF;
-if (tmp == 3 || tmp == 5) {
+if (tmp == 3) {
+b43legacy_phy_write(dev, 0x04C2, 0x1816);
+b43legacy_phy_write(dev, 0x04C3, 0x8606);
+}
+if (tmp == 4 || tmp == 5) {
b43legacy_phy_write(dev, 0x04C2, 0x1816);
b43legacy_phy_write(dev, 0x04C3, 0x8006);
-if (tmp == 5)
-b43legacy_phy_write(dev, 0x04CC,
-(b43legacy_phy_read(dev,
- 0x04CC) 0x00FF) |
- 0x1F00);
+b43legacy_phy_write(dev, 0x04CC,
+(b43legacy_phy_read(dev,
+0x04CC) 0x00FF) |
+0x1F00);
}
+}
+if (phy-rev = 2)
b43legacy_phy_write(dev, 0x047E, 0x0078);
}
if (phy-radio_rev == 8) {
@@ -1078,7 +1085,7 @@
else
b43legacy_phy_write(dev, 0x002F, 0x0202);
}
-if (phy-gmode || phy-rev = 2) {
+if (phy-gmode) {
b43legacy_phy_lo_adjust(dev, 0);
b43legacy_phy_write(dev, 0x080F, 0x8078);
}
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Speed enhancement for BCM4306/2
[EMAIL PROTECTED] wrote: Try #5: # diff -uN /tmp/phy.c drivers/net/wireless/b43legacy/phy.c --- /tmp/phy.c2008-09-06 15:13:33.0 -0700 This one is pretty close, but I think you missed a change at line 16a of B6PHY. One other thing - use the -uNp switch for diff. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43legacy: Fix failure in rate-adjustment mechanism
On Sat, Sep 06, 2008 at 08:41:05PM +0200, Michael Buesch wrote: On Saturday 06 September 2008 20:34:02 Larry Finger wrote: A coding error present since b43legacy was incorporated into the kernel has prevented the driver from using the rate-setting mechanism of mac80211. The driver has been forced to remain at a 1 Mb/s rate. Does version3 firmware have a different bitlayout for the status? Although this is not strictly a regression, it is a bug. I hope it can be sent to 2.6.27. The new rules don't allow us to fix bugs after the merge window. Only regressions. I imagine the powers that be would claim it isn't a new rule, but it is a new enforcement policy... John ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH] b43legacy: Fix to enhance TX speed
Recent changes in the specifications have improved the performance
of the BCM4306/2 devices that use b43legacy as the driver. These
errors in the specs have been present from the very first implementation
of bcm43xx.
Signed-off-by: Ehud Gavron [EMAIL PROTECTED]
Tested-by: Larry Finger [EMAIL PROTECTED]
---
John,
This is 2.6.28.material.
Ehud
---
Index: linux-2.6/drivers/net/wireless/b43legacy/phy.c
===
--- linux-2.6.orig/drivers/net/wireless/b43legacy/phy.c
+++ linux-2.6/drivers/net/wireless/b43legacy/phy.c
@@ -595,12 +595,14 @@ static void b43legacy_phy_initb5(struct
0x0035) 0xFFC0) | 0x0064);
b43legacy_phy_write(dev, 0x005D, (b43legacy_phy_read(dev,
0x005D) 0xFF80) | 0x000A);
+ b43legacy_phy_write(dev, 0x5B, 0x);
+ b43legacy_phy_write(dev, 0x5C, 0x);
}
if (dev-bad_frames_preempt)
b43legacy_phy_write(dev, B43legacy_PHY_RADIO_BITFIELD,
b43legacy_phy_read(dev,
- B43legacy_PHY_RADIO_BITFIELD) | (1 11));
+ B43legacy_PHY_RADIO_BITFIELD) | (1 12));
if (phy-analog == 1) {
b43legacy_phy_write(dev, 0x0026, 0xCE00);
@@ -753,7 +755,7 @@ static void b43legacy_phy_initb6(struct
b43legacy_radio_write16(dev, 0x0050, 0x0020);
}
if (phy-radio_rev = 2) {
- b43legacy_radio_write16(dev, 0x007C, 0x0020);
+ b43legacy_radio_write16(dev, 0x0050, 0x0020);
b43legacy_radio_write16(dev, 0x005A, 0x0070);
b43legacy_radio_write16(dev, 0x005B, 0x007B);
b43legacy_radio_write16(dev, 0x005C, 0x00B0);
@@ -771,7 +773,7 @@ static void b43legacy_phy_initb6(struct
b43legacy_phy_write(dev, 0x002A, 0x8AC0);
b43legacy_phy_write(dev, 0x0038, 0x0668);
b43legacy_radio_set_txpower_bg(dev, 0x, 0x, 0x);
- if (phy-radio_rev = 5)
+ if (phy-radio_rev == 4 || phy-radio_rev == 5)
b43legacy_phy_write(dev, 0x005D, (b43legacy_phy_read(dev,
0x005D) 0xFF80) | 0x0003);
if (phy-radio_rev = 2)
@@ -1010,7 +1012,7 @@ static void b43legacy_phy_initg(struct b
b43legacy_phy_initb5(dev);
else
b43legacy_phy_initb6(dev);
- if (phy-rev = 2 || phy-gmode)
+ if (phy-rev = 2 phy-gmode)
b43legacy_phy_inita(dev);
if (phy-rev = 2) {
@@ -1025,18 +1027,22 @@ static void b43legacy_phy_initg(struct b
b43legacy_phy_write(dev, 0x0811, 0x0400);
b43legacy_phy_write(dev, 0x0015, 0x00C0);
}
- if (phy-rev = 2 || phy-gmode) {
+ if (phy-gmode) {
tmp = b43legacy_phy_read(dev, 0x0400) 0xFF;
- if (tmp == 3 || tmp == 5) {
+ if (tmp == 3) {
+ b43legacy_phy_write(dev, 0x04C2, 0x1816);
+ b43legacy_phy_write(dev, 0x04C3, 0x8606);
+ }
+ if (tmp == 4 || tmp == 5) {
b43legacy_phy_write(dev, 0x04C2, 0x1816);
b43legacy_phy_write(dev, 0x04C3, 0x8006);
- if (tmp == 5)
- b43legacy_phy_write(dev, 0x04CC,
- (b43legacy_phy_read(dev,
-0x04CC) 0x00FF) |
-0x1F00);
+ b43legacy_phy_write(dev, 0x04CC,
+ (b43legacy_phy_read(dev,
+0x04CC) 0x00FF) |
+0x1F00);
}
- b43legacy_phy_write(dev, 0x047E, 0x0078);
+ if (phy-rev = 2)
+ b43legacy_phy_write(dev, 0x047E, 0x0078);
}
if (phy-radio_rev == 8) {
b43legacy_phy_write(dev, 0x0801, b43legacy_phy_read(dev, 0x0801)
@@ -1078,7 +1084,7 @@ static void b43legacy_phy_initg(struct b
else
b43legacy_phy_write(dev, 0x002F, 0x0202);
}
- if (phy-gmode || phy-rev = 2) {
+ if (phy-gmode) {
b43legacy_phy_lo_adjust(dev, 0);
b43legacy_phy_write(dev, 0x080F, 0x8078);
}
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
