diff options
author | Werner Almesberger <werner@openmoko.org> | 2009-01-14 11:55:56 +0000 |
---|---|---|
committer | Andy Green <agreen@pads.home.warmcat.com> | 2009-01-14 11:55:56 +0000 |
commit | e2c0650efa751a6a2220618695fa41a2a5e7d23c (patch) | |
tree | a2fc746d8f7fca24102f15f69dd558bd57b7bd6f | |
parent | aadaf347b01b410adce68c36bddc11facfcc4969 (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.c | 16 |
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) |