Re: [PATCH] b43: Fix QoS defaults
On Thursday 11 September 2008 05:37:48 Larry Finger wrote: Lorenzo Nava wrote: I'm not a reverse engineer, so I have no chance to check the original code to agree (or not) with you. Ok, the mail has Johannes in Cc. I hope that he can tell me if me and Francesco are right or not. Johannes please check it (I mean specs at http://bcm-v4.sipsolutions.net/802.11/QoS) , thank you. It took me a while to find it, but the definitive statement is in the structure that defines the EDCF Q info array. It contains 16 2-byte words. The first 8 match the variables in the page mentioned above, and the last 8 are padding. Lorenzo and Francesco are right. I have modified the specs to conform to this finding. Can somebody who cares please send a patch to John Linville, for inclusion in the next merge window? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix QoS defaults
On Wednesday 10 September 2008 00:15:14 Lorenzo Nava wrote: Hi everybody, I worked with the QoS parameters trying to understand why, checking them within the firmware, they don't seems to have the correct values even if they were set correctly by the driver. I think that there could be an error in the b43.h file: /* SHM offsets to the QOS data structures for the 4 different queues. */ #define B43_QOS_PARAMS(queue) (B43_SHM_SH_EDCFQ + \ (B43_NR_QOSPARAMS * sizeof(u16) * (queue))) #define B43_QOS_BACKGROUND B43_QOS_PARAMS(0) #define B43_QOS_BESTEFFORT B43_QOS_PARAMS(1) #define B43_QOS_VIDEO B43_QOS_PARAMS(2) #define B43_QOS_VOICE B43_QOS_PARAMS(3) /* QOS parameter hardware data structure offsets. */ #define B43_NR_QOSPARAMS22 Each EDCF parameters set take up 32 byte (in the firmware the offset between 2 EDCFQ is 0x010 that is equivalent to 0x020 if the offset was expressed in byte). This means that the B43_NR_QOSPARAMS must be set to 16. With the value equal to 16 I can access correctly the aifs, cwcur, cwmax, etc within the firmware. What do you think about that? The specifications says there are 22 (decimal) entries. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix QoS defaults
Hi Michael, we are collecting every kind of material about Broadcom board, too. Could you please point out the document with such specifications? I confirm what Lorenzo wrote: there are 32 bytes for queue. If you leave 22 then all the Qos mechanisms go wrong. Indeed, the bcm board takes (quite) exclusive control of the channel as gap is always set to zero. Cheers, -FG On Sep 10, 2008, at 2:58 PM, Michael Buesch wrote: On Wednesday 10 September 2008 00:15:14 Lorenzo Nava wrote: Hi everybody, I worked with the QoS parameters trying to understand why, checking them within the firmware, they don't seems to have the correct values even if they were set correctly by the driver. I think that there could be an error in the b43.h file: /* SHM offsets to the QOS data structures for the 4 different queues. */ #define B43_QOS_PARAMS(queue) (B43_SHM_SH_EDCFQ + \ (B43_NR_QOSPARAMS * sizeof(u16) * (queue))) #define B43_QOS_BACKGROUND B43_QOS_PARAMS(0) #define B43_QOS_BESTEFFORT B43_QOS_PARAMS(1) #define B43_QOS_VIDEO B43_QOS_PARAMS(2) #define B43_QOS_VOICE B43_QOS_PARAMS(3) /* QOS parameter hardware data structure offsets. */ #define B43_NR_QOSPARAMS22 Each EDCF parameters set take up 32 byte (in the firmware the offset between 2 EDCFQ is 0x010 that is equivalent to 0x020 if the offset was expressed in byte). This means that the B43_NR_QOSPARAMS must be set to 16. With the value equal to 16 I can access correctly the aifs, cwcur, cwmax, etc within the firmware. What do you think about that? The specifications says there are 22 (decimal) entries. -- Greetings Michael. ___ 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: [PATCH] b43: Fix QoS defaults
On Wednesday 10 September 2008 15:18:07 Francesco Gringoli wrote: Hi Michael, we are collecting every kind of material about Broadcom board, too. Could you please point out the document with such specifications? http://bcm-v4.sipsolutions.net/802.11/QoS I confirm what Lorenzo wrote: there are 32 bytes for queue. If you leave 22 then all the Qos mechanisms go wrong. Indeed, the bcm board takes (quite) exclusive control of the channel as gap is always set to zero. The code is correct wrt specs. It says there are 0x16 words. First fix specs, then fix code, please. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix QoS defaults
Stay on list. I'm not going to start another private thread for this. In general, I avoid private threads most of the time and barely answer them. There are so many people on the list that can answer your questions. On Wednesday 10 September 2008 17:50:33 Francesco Gringoli wrote: The code is correct wrt specs. It says there are 0x16 words. First fix specs, then fix code, please. I do not understand: those specs say that there are 16 words. The table has 0x16 entries. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix QoS defaults
I'm not a reverse engineer, so I have no chance to check the original code to agree (or not) with you. Ok, the mail has Johannes in Cc. I hope that he can tell me if me and Francesco are right or not. Johannes please check it (I mean specs at http://bcm-v4.sipsolutions.net/802.11/QoS) , thank you. regards Lorenzo -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix QoS defaults
Lorenzo Nava wrote: I'm not a reverse engineer, so I have no chance to check the original code to agree (or not) with you. Ok, the mail has Johannes in Cc. I hope that he can tell me if me and Francesco are right or not. Johannes please check it (I mean specs at http://bcm-v4.sipsolutions.net/802.11/QoS) , thank you. It took me a while to find it, but the definitive statement is in the structure that defines the EDCF Q info array. It contains 16 2-byte words. The first 8 match the variables in the page mentioned above, and the last 8 are padding. Lorenzo and Francesco are right. I have modified the specs to conform to this finding. Larry ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] b43: Fix QoS defaults
Hi everybody, I worked with the QoS parameters trying to understand why, checking them within the firmware, they don't seems to have the correct values even if they were set correctly by the driver. I think that there could be an error in the b43.h file: /* SHM offsets to the QOS data structures for the 4 different queues. */ #define B43_QOS_PARAMS(queue) (B43_SHM_SH_EDCFQ + \ (B43_NR_QOSPARAMS * sizeof(u16) * (queue))) #define B43_QOS_BACKGROUND B43_QOS_PARAMS(0) #define B43_QOS_BESTEFFORT B43_QOS_PARAMS(1) #define B43_QOS_VIDEO B43_QOS_PARAMS(2) #define B43_QOS_VOICE B43_QOS_PARAMS(3) /* QOS parameter hardware data structure offsets. */ #define B43_NR_QOSPARAMS22 Each EDCF parameters set take up 32 byte (in the firmware the offset between 2 EDCFQ is 0x010 that is equivalent to 0x020 if the offset was expressed in byte). This means that the B43_NR_QOSPARAMS must be set to 16. With the value equal to 16 I can access correctly the aifs, cwcur, cwmax, etc within the firmware. What do you think about that? regards. Lorenzo. ___ 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
