[PATCH] bcm43xx-mac80211: Fix regression in interrupt handling
Since commit 85a83d26697dd2203ac4e5f33022951f2c3e6e33, "bcm43xx-mac80211: Rewrite and simplify handling of the initialization status", some PCI adapters have problems due to interrupts happening before the device status reaches BCM43xx_STARTED. This patch delays the initial interrupt enable until after the device status is set. Signed-off-by: Larry Finger <[EMAIL PROTECTED]> --- John, This patch fixes a regression since 2.6.23-rc1. Michael and I have discussed this and he has agreed that this is the proper fix. Larry bcm43xx_main.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c === --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_main.c @@ -3014,13 +3014,13 @@ static int bcm43xx_wireless_core_start(s dev->dev->irq); goto out; } - bcm43xx_interrupt_enable(dev, dev->irq_savedstate); bcm43xx_mac_enable(dev); bcm43xx_periodic_tasks_setup(dev); ieee80211_start_queues(dev->wl->hw); bcm43xx_set_status(dev, BCM43xx_STAT_STARTED); + bcm43xx_interrupt_enable(dev, dev->irq_savedstate); bcmdbg(dev->wl, "Wireless interface started\n"); out: return err; ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Port of bcm43xx from softmac to mac80211 is available for testing
Richard Jonsson wrote:
Isn't Desired TX power supposed to adapt so that higher bitrates are possible,
with Bit Rate going lower if that is not enough to keep a good connection?
Richard,
Please grab a new copy of the port_to_mac80211 patch, and try the patch below. It boosts the desired
power by up to 5 dBm as signal - noise decreases from 20 to 0.
Larry
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -622,6 +622,8 @@ struct bcm43xx_wldev {
bool short_preamble;/* TRUE if using short preamble. */
bool short_slot;/* TRUE if using short slot timing. */
bool radio_hw_enable; /* State of radio hardware enable bit. */
+ u8 saved_signal_noise[4];
+ u8 signal_noise_index;
/* PHY/Radio device. */
struct bcm43xx_phy phy;
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -2862,6 +2862,8 @@ static void setup_struct_phy_for_init(st
phy->interfmode = BCM43xx_INTERFMODE_NONE;
phy->channel = 0xFF;
phy->power_level = 0;
+
+ dev->signal_noise_index = 0;
}
static void setup_struct_wldev_for_init(struct bcm43xx_wldev *dev)
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_phy.c
@@ -1771,6 +1771,7 @@ void bcm43xx_phy_xmitpower(struct bcm43x
s16 desired_pwr;
s16 estimated_pwr;
s16 pwr_adjust;
+ s16 snadjust;
s16 radio_att_delta;
s16 baseband_att_delta;
s16 radio_attenuation;
@@ -1824,6 +1825,14 @@ void bcm43xx_phy_xmitpower(struct bcm43x
estimated_pwr = bcm43xx_phy_estimate_power_out(dev, average);
+ /* calculate any power boost from low S/N values */
+ snadjust = (dev->saved_signal_noise[0] + dev->saved_signal_noise[1] +
+ dev->saved_signal_noise[2] + dev->saved_signal_noise[3] +
+ 2) / 4;
+ /* boost from 0 to 5 dBm as S/N decreases from 20 to 0 */
+ snadjust = limit_value(5 - snadjust/4, 0, 5);
+ snadjust *= 4; /* convert to Q5.2 format */
+
max_pwr = dev->dev->bus->sprom.r1.maxpwr_bg;
if ((dev->dev->bus->sprom.r1.boardflags_lo
@@ -1848,7 +1857,7 @@ void bcm43xx_phy_xmitpower(struct bcm43x
- 0x6, max_pwr);
/* find the desired power in Q5.2 - power_level is in dBm */
- desired_pwr = limit_value(phy->power_level << 2, 0, max_pwr);
+ desired_pwr = limit_value((phy->power_level << 2) + snadjust, 0,
max_pwr);
if (bcm43xx_debug(dev, BCM43xx_DBG_XMITPOWER))
bcmdbg(dev->wl, "Current TX power output: " Q52_FMT
" dBm, Desired TX power output: " Q52_FMT
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_xmit.c
@@ -526,6 +526,12 @@ void bcm43xx_rx(struct bcm43xx_wldev *de
status.antenna = !!(phystat0 & BCM43xx_RX_PHYST0_ANT);
status.mactime = mactime;
+ /* update S/N buffer */
+ dev->saved_signal_noise[dev->signal_noise_index++] =
+ status.ssi - status.noise;
+ if (dev->signal_noise_index >= 4)
+ dev->signal_noise_index = 0;
+
chanid = (chanstat & BCM43xx_RX_CHAN_ID) >> BCM43xx_RX_CHAN_ID_SHIFT;
switch (chanstat & BCM43xx_RX_CHAN_PHYTYPE) {
case BCM43xx_PHYTYPE_B:
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx.h
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx.h
@@ -622,6 +622,8 @@ struct bcm43xx_wldev {
bool short_preamble;/* TRUE if using short preamble. */
bool short_slot;/* TRUE if using short slot timing. */
bool radio_hw_enable; /* State of radio hardware enable bit. */
+ u8 saved_signal_noise[4];
+ u8 signal_noise_index;
/* PHY/Radio device. */
struct bcm43xx_phy phy;
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -2862,6 +2862,8 @@ static void setup_struct_phy_for_init(st
phy->interfmode = BCM43xx_INTERFMODE_NONE;
Re: Port of bcm43xx from softmac to mac80211 is available for testing
Richard Jonsson wrote: > "rmmod bcm43xx" when kde is running hangs rmmod and prevents a clean > shutdown. > I tried to find which program causes this while using bcm4301 driver, but so > far no luck. System shuts down fine if I don't try to rmmod first. rmmod > works fine from runlevel 3 aside from this message when inserting module > again: > "net eth1: device_rename: sysfs_create_symlink failed (-17)" I just got one of these during bootup, which prevented bcm43xx from starting correctly. The logged sequence was: kernel: bcm43xx-phy1: Broadcom 4311 WLAN found kernel: ssb: Switching to IEEE 802.11 core, index 1 kernel: bcm43xx-phy1 debug: Found PHY: Analog 4, Type 2, Revision 8 kernel: bcm43xx-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2050, Revision 2 kernel: bcm43xx-phy1 debug: Radio turned off kernel: wmaster0: Selected rate control algorithm 'simple' ifup: Service network not started and mode 'auto' -> skipping kernel: net eth1: device_rename: sysfs_create_symlink failed (-17) ifup: Network interface is managed from NetworkManager ifup: NetworkManager will be advised to set up eth1 ifup: but it cannot be assured from here. kernel: bcm43xx-phy1 debug: Adding Interface type 2 kernel: ssb: Switching to PCI-E core, index 3 kernel: ssb: Switching to IEEE 802.11 core, index 1 kernel: bcm43xx-phy1: bcm43xx: Microcode bcm43xx_microcode5.fw3.fw loaded The fix for this was to 'modprobe -r bcm43xx' followed by 'modprobe bcm43xx', which got everything started OK. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Port of bcm43xx from softmac to mac80211 is available for testing
Richard Jonsson wrote: > > I have tried these patches on 2.6.23-rc2 and find perceived performance to be > about the same as for the bcm4301 mac80211 driver. I use this script to > stresstest the connection: > > iperf -c 192.168.0.1 -t 3600 > /dev/null & > watch --interval .1 "dmesg|grep phy[0-9]|tail -n1 \ > && ifconfig eth1 \ > && iwconfig eth1 2>&1" > > iwconfig: > eth1 IEEE 802.11g ESSID:"NETGEAR" > Mode:Managed Frequency:2.442 GHz Access Point: 00:0F:B5:3D:4B:E2 > Bit Rate=2 Mb/s > Retry min limit:7 RTS thr:off Fragment thr=2346 B > Encryption key:off > Link Quality=65/100 Signal level=-60 dBm Noise level=-70 dBm > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > Tx excessive retries:0 Invalid misc:0 Missed beacon:0 > > dmesg|grep "TX power" > [ 755.816434] bcm43xx-phy0 debug: Current TX power output: 10.25 dBm, > Desired > TX power output: 10.0 dBm > [ 763.339286] bcm43xx-phy0 debug: Current TX power output: 9.0 dBm, Desired > TX power output: 10.0 dBm > [ 770.840137] bcm43xx-phy0 debug: Current TX power output: 10.50 dBm, > Desired > TX power output: 10.0 dBm > [ 778.343126] bcm43xx-phy0 debug: Current TX power output: 9.0 dBm, Desired > TX power output: 10.0 dBm > [ 785.842109] bcm43xx-phy0 debug: Current TX power output: 10.50 dBm, > Desired > TX power output: 10.0 dBm > [ 793.347213] bcm43xx-phy0 debug: Current TX power output: 10.25 dBm, > Desired > TX power output: 10.0 dBm > > Isn't Desired TX power supposed to adapt so that higher bitrates are > possible, > with Bit Rate going lower if that is not enough to keep a good connection? It should, but this feature is not yet implemented. I have some test code to do this, but it is not ready. When it is, I'll send you a trial patch. Check if your system has a file names /sys/kernel/debug/bcm43xx/phyX/power_level. If it does, you can write new values for the Desired power into it. Values up to 18 are allowed. > When next to AP I get 54Mbps when connection is idle or has low utilisation, > but when running iperf the Bit rate instantly changes to 1Mbps. While running > iperf it jumps between 1, 2, 5.5 and 11Mbps. When manually setting it to 54M > it will work with good thoughput. I think it fails at 11M and starts over > from 1 again. > > Performance next to AP (iperf -c 192.168.0.1): > 1M721K > 2M1.64M > 5.5M 3.72M > 6M5.66M > 9M7.62M > 11M --- > 12M 9.28M > 18M 11.9M > 24M 14.0M > 36M 17.2M > 48M 18.5M > 54M 18.4M > auto 451K > > When 10 meters away from AP anything higher than 5.5 is unusable, often 5.5M > too. > > 11M mode is unusable at all distances, 12M works fine. This probably breaks > rate scaling for me. Yes, it certainly would. My 4311 shows a little dip at 11 Mbs, but not as big as yours. Is your AP using b/g mode, or just g mode? What is the make and model of the AP? > "rmmod bcm43xx" when kde is running hangs rmmod and prevents a clean > shutdown. > I tried to find which program causes this while using bcm4301 driver, but so > far no luck. System shuts down fine if I don't try to rmmod first. rmmod > works fine from runlevel 3 aside from this message when inserting module > again: > "net eth1: device_rename: sysfs_create_symlink failed (-17)" On my system, I routinely unload the module using 'modprobe -r bcm43xx'. Sometimes, it happens 20 or 30 times between reboots. These are always at runlevel 5. Only once or twice has it not completed. Are you using NetworkManager or using the traditional ifup/ifdown methods? > > Nitpicking: > When changing bitrate manually it will not show up with iwconfig before any > traffic has occured. This is a mac80211 problem. My original version of the patch that implemented the "set rate" function loaded the new rate so that it would show up immediately, but that part was nixed. Complain on [EMAIL PROTECTED] > Sometimes iwconfig link quality shows values in the whole 0-255 range. Do the Signal and Noise levels show -256 dBm at the same time? If so, mac80211 has not received any data. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: Port of bcm43xx from softmac to mac80211 is available for testing
On Sunday 05 August 2007 01:26:52 Larry Finger wrote: > The port of bcm43xx from softmac to mac80211 is available for testing. > There are two patch sets that can be downloaded from > ftp://lwfinger.dynalias.org/patches and be applied to kernel 2.6.23-rc1 or > -rc2, the mainstream git tree (Linus's), and Linville's wireless-2.6 git > tree. > > The two files are ftp://lwfinger.dynalias.org/patches/SSB_Final, which > installs the SSB driver, and > ftp://lwfinger.dynalias.org/patches/port_to_mac80211, which has the changes > for the bcm43xx driver. The resulting driver will use V3 firmware. > > These patches are similar to the 4301 test driver that was circulated > earlier. The major change is that the earlier version was trying to set the > power too low. Once that was fixed, performance has become quite good, as > shown below. I'm still working on the power setup, which may help the > BCM4306. > > Transker rates (xmit/recv in Mbs), obtained by using an Iperf server on my > LAN > > Bit Rate BCM4311 BCM4318 BCM4306 > set (Mbs) > 1 1.17/8.66 1.22/9.39 1.22/3.73 > 2 1.96/11.2 1.98/12.5 1.90/4.98 > 5.5 4.15/17.7 4.19/17.7 3.98/5.09 > 6 4.86/17.3 4.86/19.9 2.66/4.94 > 9 6.58/17.7 6.56/19.9 3.26/5.01 > 116.57/14.2 6.54/18.5 6.07/5.20 > 1810.7/19.6 10.7/20.2 4.74/5.05 > 2412.6/19.6 12.8/20.0 4.12/5.34 > 3616.2/20.1 15.9/20.1 4.76/4.90 > 4817.9/20.0 15.1/19.6 3.70/4.18 > 5419.0/19.8 15.1/20.0 1.83/2.64 > > These results look rather good for the later models - my BCM4306 has a PHY > rev of 1. On this version, much more is required in the PHY setup, and we > clearly have more work for that device. > > Please let me know of any problems in applying the patches, or any oops's > that occur. > > Larry I have tried these patches on 2.6.23-rc2 and find perceived performance to be about the same as for the bcm4301 mac80211 driver. I use this script to stresstest the connection: iperf -c 192.168.0.1 -t 3600 > /dev/null & watch --interval .1 "dmesg|grep phy[0-9]|tail -n1 \ && ifconfig eth1 \ && iwconfig eth1 2>&1" iwconfig: eth1 IEEE 802.11g ESSID:"NETGEAR" Mode:Managed Frequency:2.442 GHz Access Point: 00:0F:B5:3D:4B:E2 Bit Rate=2 Mb/s Retry min limit:7 RTS thr:off Fragment thr=2346 B Encryption key:off Link Quality=65/100 Signal level=-60 dBm Noise level=-70 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 dmesg|grep "TX power" [ 755.816434] bcm43xx-phy0 debug: Current TX power output: 10.25 dBm, Desired TX power output: 10.0 dBm [ 763.339286] bcm43xx-phy0 debug: Current TX power output: 9.0 dBm, Desired TX power output: 10.0 dBm [ 770.840137] bcm43xx-phy0 debug: Current TX power output: 10.50 dBm, Desired TX power output: 10.0 dBm [ 778.343126] bcm43xx-phy0 debug: Current TX power output: 9.0 dBm, Desired TX power output: 10.0 dBm [ 785.842109] bcm43xx-phy0 debug: Current TX power output: 10.50 dBm, Desired TX power output: 10.0 dBm [ 793.347213] bcm43xx-phy0 debug: Current TX power output: 10.25 dBm, Desired TX power output: 10.0 dBm Isn't Desired TX power supposed to adapt so that higher bitrates are possible, with Bit Rate going lower if that is not enough to keep a good connection? When next to AP I get 54Mbps when connection is idle or has low utilisation, but when running iperf the Bit rate instantly changes to 1Mbps. While running iperf it jumps between 1, 2, 5.5 and 11Mbps. When manually setting it to 54M it will work with good thoughput. I think it fails at 11M and starts over from 1 again. Performance next to AP (iperf -c 192.168.0.1): 1M 721K 2M 1.64M 5.5M3.72M 6M 5.66M 9M 7.62M 11M --- 12M 9.28M 18M 11.9M 24M 14.0M 36M 17.2M 48M 18.5M 54M 18.4M auto451K When 10 meters away from AP anything higher than 5.5 is unusable, often 5.5M too. 11M mode is unusable at all distances, 12M works fine. This probably breaks rate scaling for me. "rmmod bcm43xx" when kde is running hangs rmmod and prevents a clean shutdown. I tried to find which program causes this while using bcm4301 driver, but so far no luck. System shuts down fine if I don't try to rmmod first. rmmod works fine from runlevel 3 aside from this message when inserting module again: "net eth1: device_rename: sysfs_create_symlink failed (-17)" Nitpicking: When changing bitrate manually it will not show up with iwconfig before any traffic has occured. Sometimes iwconfig link quality shows values in the whole 0-255 range. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.d
Re: [PATCH V2] bcm43xx-mac80211: Rescale link quality output
On Sunday 05 August 2007, Larry Finger wrote: > Michael Buesch wrote: > > On Sunday 05 August 2007, Larry Finger wrote: > >> The link quality output from wireless extensions is too small by the ratio > >> of 100/BCM43xx_RX_MAX_SSI (60) for bcm43xx-mac80211. This patch puts the > >> quantity on the proper scale. > >> > >> Signed-off-by: Larry Finger <[EMAIL PROTECTED]> > >> --- > >> > >> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c > >> === > >> --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c > >> +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c > >> @@ -537,7 +537,8 @@ void bcm43xx_rx(struct bcm43xx_wldev *de > >> (phystat0 & > >> BCM43xx_RX_PHYST0_GAINCTL), > >> (phystat3 & > >> BCM43xx_RX_PHYST3_TRSTATE)); > >>status.noise = dev->stats.link_noise; > >> - status.signal = jssi; /* this looks wrong, but is what mac80211 wants */ > >> + /* the next line looks wrong, but is what mac80211 wants */ > >> + status.signal = (jssi * 100) / BCM43xx_RX_MAX_SSI; > > > > So signal is in percent? > > Where is this actually documented. I cannot find a hint on what > > the values of all these things are supposed to be. > > Yes, it is clear as mud, with the additional complications of mac80211 mixing > the definitions of > signal and rssi (as far as I'm concerned). The scale is set by the following > code snippet in > bcm43xx_wireless_init. > > hw->max_signal = 100; > hw->max_rssi = -110; > hw->max_noise = -110; > > In this code, "signal" is put on a scale of 0 to 100, and rssi and noise on a > scale of -110 to 0 and > are assumed to be dBm. Of course, rssi should be a positive number and signal > should be in dBm, but > my renaming of signal => quality and rssi => signal was shot down, so we are > stuck. > > An alternative to the patch above would be to set hw->max_signal = > BCM43xx_RX_MAX_SSI. In that case, > the line of iwconfig output that reads "Link Quality=83/100 Signal level=-34 > dBm Noise level=-71 > dBm" would have a "Link Quality" of 50/60 instead of 83/100. > > The bottom line is that it is an arbitrary quantity on an arbitrary scale. Is > it better for it to be > XX/100 than YY/60? I think so, but YMMV. Ah, I see. Kind of confusing. :) Well, I would like to do hw->max_signal = MAX_RSSI but it seems to be an unwritten rule that signal scales to 100. At least I never saw a different scale in a driver, yet. So I think I will apply your patch. Thanks! ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] bcm43xx-mac80211: Rescale link quality output
Michael Buesch wrote: > On Sunday 05 August 2007, Larry Finger wrote: >> The link quality output from wireless extensions is too small by the ratio >> of 100/BCM43xx_RX_MAX_SSI (60) for bcm43xx-mac80211. This patch puts the >> quantity on the proper scale. >> >> Signed-off-by: Larry Finger <[EMAIL PROTECTED]> >> --- >> >> Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c >> === >> --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c >> +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c >> @@ -537,7 +537,8 @@ void bcm43xx_rx(struct bcm43xx_wldev *de >>(phystat0 & >> BCM43xx_RX_PHYST0_GAINCTL), >>(phystat3 & >> BCM43xx_RX_PHYST3_TRSTATE)); >> status.noise = dev->stats.link_noise; >> -status.signal = jssi; /* this looks wrong, but is what mac80211 wants */ >> +/* the next line looks wrong, but is what mac80211 wants */ >> +status.signal = (jssi * 100) / BCM43xx_RX_MAX_SSI; > > So signal is in percent? > Where is this actually documented. I cannot find a hint on what > the values of all these things are supposed to be. Yes, it is clear as mud, with the additional complications of mac80211 mixing the definitions of signal and rssi (as far as I'm concerned). The scale is set by the following code snippet in bcm43xx_wireless_init. hw->max_signal = 100; hw->max_rssi = -110; hw->max_noise = -110; In this code, "signal" is put on a scale of 0 to 100, and rssi and noise on a scale of -110 to 0 and are assumed to be dBm. Of course, rssi should be a positive number and signal should be in dBm, but my renaming of signal => quality and rssi => signal was shot down, so we are stuck. An alternative to the patch above would be to set hw->max_signal = BCM43xx_RX_MAX_SSI. In that case, the line of iwconfig output that reads "Link Quality=83/100 Signal level=-34 dBm Noise level=-71 dBm" would have a "Link Quality" of 50/60 instead of 83/100. The bottom line is that it is an arbitrary quantity on an arbitrary scale. Is it better for it to be XX/100 than YY/60? I think so, but YMMV. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH V2] bcm43xx-mac80211: Rescale link quality output
On Sunday 05 August 2007, Larry Finger wrote: > The link quality output from wireless extensions is too small by the ratio > of 100/BCM43xx_RX_MAX_SSI (60) for bcm43xx-mac80211. This patch puts the > quantity on the proper scale. > > Signed-off-by: Larry Finger <[EMAIL PROTECTED]> > --- > > Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c > === > --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c > +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c > @@ -537,7 +537,8 @@ void bcm43xx_rx(struct bcm43xx_wldev *de > (phystat0 & > BCM43xx_RX_PHYST0_GAINCTL), > (phystat3 & > BCM43xx_RX_PHYST3_TRSTATE)); > status.noise = dev->stats.link_noise; > - status.signal = jssi; /* this looks wrong, but is what mac80211 wants */ > + /* the next line looks wrong, but is what mac80211 wants */ > + status.signal = (jssi * 100) / BCM43xx_RX_MAX_SSI; So signal is in percent? Where is this actually documented. I cannot find a hint on what the values of all these things are supposed to be. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
On Sunday 05 August 2007, Pavel Roskin wrote: > On Sat, 2007-08-04 at 18:47 +0200, Michael Buesch wrote: > > > Yeah, I'd like to get rid of this message, too. But by fixing the > > bug and not by hiding it. > > > > So any suggestions on how to fix this? > > I think you could try to write a detailed explanation of the problem, in > particular, what those tables do, where the numbers come from, what > hardware is affected, what the driver does now, what it should do, and > how to find out the right solution from reverse engineering data. If I knew all these things, I would fix it. > After all, there are working drivers for the chipset, and they can be > reverse engineered. It cannot be a problem with no solution. > > Chances are that you will have some ideas before you finish writing the > message. It happened to me many times. But even if it doesn't happen, > you will make it easy for others to suggest solutions. And you will > give the reverse engineering team some ideas what to look for. Well, it's not that easy. Current code just doesn't make any sense. I do not understand how hardware power control works exactly, so I can't write some detailed message or something. That's probably a chicken and egg problem ;) ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: 2.6.23-rc1-wireless-dev bcm43xx_mac80211 associates, but Ethernet appears broken
On Saturday 04 August 2007, Will Dyson wrote:
> On 8/4/07, Michael Buesch <[EMAIL PROTECTED]> wrote:
>
> > So any suggestions on how to fix this?
> > The problem is that I'm not sure why we calibrate the LO by these strange
> > tables. Maybe we can fix this by dropping the tables and simply
> > calibrate it for every possible attenuation.
> > These tables have some relation to the hardware power control.
> > So maybe we don't need to adjust the LO from the txpower routines
> > at all, when using hwpctl? (Only on demand of the power vector).
>
> I certainly can't claim to understand how the LO calibration is
> supposed to work. I'm especially having a hard time understanding how
> these LO tables (lo->with_padmix and lo->no_padmix) get built.
>
> With that in mind, why can't we just make the table large enough for
> an RFATT of 11?
>
> It seems to work for me on a 4306
>
> Gmail-mangled patch follows (just to show what I'm talking about)
>
> diff --git a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_lo.h
> b/drivers/net/wireless/bcm43xx-mac80211/b
> index 377bda4..1d89fdd 100644
> --- a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_lo.h
> +++ b/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_lo.h
> @@ -26,7 +26,7 @@ struct bcm43xx_loctl {
> * Use bcm43xx_get_lo_g_ctl() to retrieve a value from the lists.
> */
> struct bcm43xx_txpower_lo_control {
> -#define BCM43xx_NR_BB 9
> +#define BCM43xx_NR_BB 12
> #define BCM43xx_NR_RF 16
> /* LO Control values, with PAD Mixer */
> struct bcm43xx_loctl with_padmix[ BCM43xx_NR_BB ][ BCM43xx_NR_RF ];
> diff --git a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
> b/drivers/net/wireless/bcm43xx-mac80211/
> index 4db7c5c..8f35d33 100644
> --- a/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
> +++ b/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_phy.c
> @@ -181,12 +181,15 @@ static void generate_bbatt_list(struct bcm43xx_wldev
> *dev,
> { .att = 6, },
> { .att = 7, },
> { .att = 8, },
> + { .att = 9, },
> + { .att = 10, },
> + { .att = 11, },
> };
>
> list->list = bbatt_0;
> list->len = ARRAY_SIZE(bbatt_0);
> list->min_val = 0;
> - list->max_val = 8;
> + list->max_val = 11;
> }
>
> static void bcm43xx_shm_clear_tssi(struct bcm43xx_wldev *dev)
>
>
Well, that's exactly the part I don't understand either.
It's can't be the case that we must extend the tables to get proper operation.
Except there's the same bug in the original driver, too, of course.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
[PATCH V2] bcm43xx-mac80211: Rescale link quality output
The link quality output from wireless extensions is too small by the ratio of 100/BCM43xx_RX_MAX_SSI (60) for bcm43xx-mac80211. This patch puts the quantity on the proper scale. Signed-off-by: Larry Finger <[EMAIL PROTECTED]> --- Index: wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c === --- wireless-dev.orig/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c +++ wireless-dev/drivers/net/wireless/bcm43xx-mac80211/bcm43xx_xmit.c @@ -537,7 +537,8 @@ void bcm43xx_rx(struct bcm43xx_wldev *de (phystat0 & BCM43xx_RX_PHYST0_GAINCTL), (phystat3 & BCM43xx_RX_PHYST3_TRSTATE)); status.noise = dev->stats.link_noise; - status.signal = jssi; /* this looks wrong, but is what mac80211 wants */ + /* the next line looks wrong, but is what mac80211 wants */ + status.signal = (jssi * 100) / BCM43xx_RX_MAX_SSI; if (phystat0 & BCM43xx_RX_PHYST0_OFDM) status.rate = bcm43xx_plcp_get_bitrate_ofdm(plcp); else ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
