Re: brcmfmac NVRAM files

[Samuel Ortiz <sameo@linux.intel.com>]

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/