aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorWerner Almesberger <werner@openmoko.org>2009-01-14 11:55:56 +0000
committerAndy Green <agreen@pads.home.warmcat.com>2009-01-14 11:55:56 +0000
commite2c0650efa751a6a2220618695fa41a2a5e7d23c (patch)
treea2fc746d8f7fca24102f15f69dd558bd57b7bd6f
parentaadaf347b01b410adce68c36bddc11facfcc4969 (diff)
WLAN: --power maxperf shot into the dark
As I've mentioned before, telling the WLAN module not to sleep with "wmiconfig -i eth0 --power maxperf" reportedly improves network stability in some situations where otherwise disconnects were frequent. (Sorry if this sounds rather vague. I don't have much real data on this phenomenon. More details would be welcome.) Paul Lever from Atheros suggested that one possible source of trouble when not using --power maxperf could be that the module very often takes a nap and then needs to delay new commands while waking up, and some SDIO hosts may fail to handle the delay properly. The S3C2442 manual leaves it unclear whether the controller handles this condition or not. The Linux MMC/SDIO stack explicitly polls for busy status in MMC mode but not in SDIO mode. I've attached a patch against andy-tracking that rather crudely checks if the module is signalling that it's still busy while we're about to start a new transfer, and delays in this case. In my tests, I could not make the busy condition occur (unless I explicitly violated the stack's synchronization), but then I hardly see any disconnects anyway. So it would be good if those affected by frequent loss of association could try this patch. More precisely, - if association with the base station is often lost, and - "wmiconfig -i eth0 --power maxperf" improves this, then - please apply this patch, leave WLAN power at default settings (i.e., wmiconfig -i eth0 --power rec), and report - if the patch had any effect on the stability of associations, and - whether "READ WHILE BUSY !" or "WRITE WHILE BUSY !" gets logged in dmesg. It may make sense to temporarily put this patch into andy-tracking. While it may be perfectly useless, it shouldn't create any new trouble either. In case it turns out to make a difference, I'll have to find a better place in the stack for it, so it'll be reverted either way. Signed-off-by: Werner Almesberger <werner@openmoko.org>
-rw-r--r--drivers/ar6000/hif/hif2.c16
1 files changed, 14 insertions, 2 deletions
diff --git a/drivers/ar6000/hif/hif2.c b/drivers/ar6000/hif/hif2.c
index c635307e837..2b1c5942003 100644
--- a/drivers/ar6000/hif/hif2.c
+++ b/drivers/ar6000/hif/hif2.c
@@ -119,6 +119,9 @@ static DEFINE_MUTEX(shutdown_lock);
/* ----- Request processing ------------------------------------------------ */
+#include <mach/regs-gpio.h>
+
+
static A_STATUS process_request(struct hif_request *req)
{
int ret;
@@ -126,10 +129,19 @@ static A_STATUS process_request(struct hif_request *req)
dev_dbg(&req->func->dev, "process_request(req %p)\n", req);
sdio_claim_host(req->func);
- if (req->read)
+ if (req->read) {
+ while (!s3c2410_gpio_getpin(S3C2410_GPE7)) {
+ printk(KERN_INFO "READ WHILE BUSY !\n");
+ yield();
+ }
ret = req->read(req->func, req->buf, req->addr, req->len);
- else
+ } else {
+ while (!s3c2410_gpio_getpin(S3C2410_GPE7)) {
+ printk(KERN_INFO "WRITE WHILE BUSY !\n");
+ yield();
+ }
ret = req->write(req->func, req->addr, req->buf, req->len);
+ }
sdio_release_host(req->func);
status = ret ? A_ERROR : A_OK;
if (req->completion)