Resume issue with brcmfmac *not* loaded

[Sukesh Srikakula]

+Sandeep

-----Original Message-----
From: Stephen Warren [mailto:swarren at nvidia.com] 
Sent: Tuesday, June 14, 2011 8:58 AM
To: Olof Johansson; Grant Grundler
Cc: cjb at laptop.org; Greg KH (gregkh at suse.de); Venkat Rao; devel at driverdev.osuosl.org; linux-mmc at vger.kernel.org; Olof Johansson; Sukesh Srikakula
Subject: RE: Resume issue with brcmfmac *not* loaded

Olof Johansson wrote at Monday, June 13, 2011 7:13 PM:
> Hi,
> 
> First, the below were pure guesses on my behalf, but browsing around
> the sources for a few minutes seems to confirm that caps are... well,
> caps. flags are currently active flags.
> 
> On Mon, Jun 13, 2011 at 5:26 PM, Grant Grundler <grundler at chromium.org> wrote:
> >On Mon, Jun 13, 2011 at 2:18 PM, Stephen Warren <swarren at nvidia.com> wrote:
> >> I'm having resume problems on a system (NVIDIA Tegra Seaboard) that would
> >> use the brcmfmac staging driver.
> >
> > Stephen,
> > Are you using the chromium.org tree...and using 2.6.38 based kernel?
> > Or directly using gregkh's staging-next:staging-2.6 tree/branch?

I'm using the chromeos-2.6.38 tree from kernel.git.

> >> When the driver is loaded, suspend and resume (echo mem > /sys/state/power)
> >> work fine.
> >>
> >> However, without the driver loaded, resume works, but 10 seconds later,
> >> the kernel hangs a little, and spits out the errors quoted at the end of
> >> this email. The hangs interfere with other devices on the system; e.g.
> >> audio DMA gets starved and causes audible artifacts.
> >>
> >> I tracked this down to brcmfmac's suspend function wl_cfg80211_suspend()
> >> calling sdioh_sdio_set_host_pm_flags(MMC_PM_KEEP_POWER).
> >
> > Broadcom and/or Olofj might have insight in this. It's not clear to me
> > why loading the driver on resume would break this.  Loading the driver
> > at boot time works fine for me and should essentially be exercising
> > the same code path from the driver PoV.
> 
> Sounds to me like loading the driver isn't what is breaking things,
> it's the suspend/resume without a driver at all.

Yes, that's correct.

> That slot lacks a CD GPIO, which means that the MMC code will poll for
> cards present. It seems like one of those polls are what's causing
> problem in this case.
> 
> The wifi adapter will stay powered across the suspend/resume (external
> power feed, not part of MMC). So the MMC interface will go down but
> the card will remain powered.
>
> >> I note that the MMC controller suspend/resume path are influenced by
> >> MMC_PM_KEEP_POWER, but only when the driver for the attached SDIO device
> >> specify that flag, hence it's in host->pm_flags and not just in
> >> host->pm_caps.
> >
> > Sorry, I don't know the difference and assume Olof does.
> >
> >> If I hack all the MMC core code to look for (host->pm_caps &
> >> MMC_PM_KEEP_POWER) instead of (host->pm_flags & MMC_PM_KEEP_POWER), then
> >> suspend/resume works fine even without the brcmfmac driver loaded.
> >
> > Olof (just walked by) suspects pm_caps means it's supported and
> > pm_flags indicates state (enabled).

> Right -- it sounds to me like checking caps at resume time is the
> wrong way to go about it -- caps are just caps, and flags are the
> current actual setting.

Yes, checking caps doesn't seem correct; it was just a quick hack to
validate that keeping the power on was what made things work after the
driver was loaded.

> >> I imagine such a change isn't blanket appropriate for the MMC core. Can
> >> anyone clue me in on:
> >>
> >> * Is the call to sdioh_sdio_set_host_pm_flags() just something that masks
> >> a somewhat unrelated problem that should be investigated, or a direct fix
> >> for this issue?
> 
> Sounds to me like there's another problem going on here. I wonder if
> the card gets confused if the host goes away and comes back without it
> having been power cycled as well.

Ah. That sounds plausible.

> This should be simple for Broadcom to reproduce, and they are the ones
> with the knowledge of how their adapter behaves. So I'd like to hear
> from them about this.
> 
> >> Note that the call to sdioh_sdio_set_host_pm_flags() was introduced to
> >> staging-2.6.git in commit 6b5a5a3eb77ea69382da9d2a64d74107e49cedaa
> >> "STAGING: brcm80211 v2 keep power on in suspend state".
> 
> Reverting that change won't make a difference in this case, will it?

No. I didn't try it, but I'm pretty sure that would just make resume
fail *with* the driver loaded too.

> Sounds like the solution here might instead be:
> 
> * Specify the power_gpio properly for the slot in question (it does
> have one wired up if I'm reading the right schematics, it's just not
> specified in the board file)

I assume you mean WF_RST_L_PWDN_L?

> * Add a suspend/resume function to the sdhci-tegra driver currently
> not in use, that disables power to the slot during suspend if the
> pm_flags don't have MMC_KEEP_POWER set.

I'll give that a try and see...

> That should take care of this issue, but it would also be good to hear
> from Broadcom above as to why the current behavior causes problems.

Thanks.

-- 
nvpublic