+Sandeep -----Original Message----- From: Stephen Warren [mailto:swarren@xxxxxxxxxx] Sent: Tuesday, June 14, 2011 8:58 AM To: Olof Johansson; Grant Grundler Cc: cjb@xxxxxxxxxx; Greg KH (gregkh@xxxxxxx); Venkat Rao; devel@xxxxxxxxxxxxxxxxxxxx; linux-mmc@xxxxxxxxxxxxxxx; 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@xxxxxxxxxxxx> wrote: > >On Mon, Jun 13, 2011 at 2:18 PM, Stephen Warren <swarren@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
