On Wed, Mar 05, 2014 at 05:15:27PM +0100, Arend van Spriel wrote: > On 03/05/14 11:24, Samuel Ortiz wrote: > >I'm attaching the log corresponding to a modprobe brcmfmac debug=0x31416 > >&& ifconfig wlan0 up sequence. > >I have modified this in the driver, to make it less aggressive about > >SDIO sleeps: > > > >sdio_host.h: > >#define BRCMF_WD_POLL_MS 200 > > > >dhd_sdio.c: > >#define BRCMF_IDLE_INTERVAL 20 > > So this log looks fine, because due to the changes above it never > goes to sleep. The log actually show it is a backport, right? That's correct, yes. > >>> I also have 2 question for you;-) > >Sorry if I sounded a bit rude, I didn't mean it :-/ > > I did not take it as rude so no worries. > > >>> - what mmc host controller is used? > >So this is sdhci-acpi. > > > >>> - do you have CONFIG_RUNTIME_PM enabled? > >CONFIG_PM_RUNTIME is enabled, yes. Do you want me to test with it > >disabled ? > > > > I am asking because Russell King recently discovered that SDHCI > based host controller drivers disable the SDIO interrupt. You mean they do so from their runtime_suspend hook ? I see the thread now: http://www.spinics.net/lists/arm-kernel/msg308757.html It seems those patches have not been reviewed nor merged... I'll watch that thread closely ;) > This would > explain the timeout on the scan as the scan results are events from > the device that require this interrupt. Even with your patches this > may still happen. You can probably disable it for the host > controller through sysfs. I did so, and things seem to be more stable. The throughput is a lot better. Better is expected but 20x better is something else. I still get fairly weak signal, typically -75 dBm for APs that are a few meters away. Does that sound like reasonable values to you ? Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
