[...] >> >> Depending if you have SD/(e)MMC card slot(s), the below patch might >> affect your results. So it might be a good idea to re-run your test to >> get some fresh data. >> >> [PATCH 1/2] mmc: core: Make runtime resume default behavior for MMC/SD [3] > I didn't find this patch in mainline kernel, where is this patch?
It's queued for 4.5 on my next branch via my mmc git. Thus also available in linux-next. One should know that it's affecting MMC/SD cards and not SDIO. Future wise I was hoping we could do something similar for SDIO, but I need to think that through a bit more. >> >>>>> Signed-off-by: Zhonghui Fu <zhonghui...@linux.intel.com> >>>> I think this is an interesting change, but I wonder if you really >>>> understand how this affects the order of how devices may be >>>> suspended/resumed? >>>> >>>> Also, I believe you didn't answer my question for the earlier version >>>> of the patch, so let me try again. >>>> >>>> There are a strict dependency chain when suspending/resuming devices >>>> that must be maintained. Currently this is controlled via device >>>> registration/probe order. >>>> >>>> An SDIO func driver/device must always be suspended *before* the SDIO >>>> card device. Additionally the corresponding MMC host, must be >>>> suspended after the SDIO card device. Vice verse applies to the resume >>>> sequence. >>>> >>>> As this patch enables asynchronous suspend, I am worried that it will >>>> break this dependency chain. What do you think? >>> After enabling asynchronous suspend/resume, PM core still ensures the >>> strict suspend/resume dependency between child and parent devices - child >>> must be suspended before its parent, and parent must be resumed before its >>> child. SDIO function is child of SDIO card, and SDIO card is child of MMC >>> host, and MMC host is child of MMC controller. So the dependency chain is >>> not broken. Actually, many devices have been using asynchronous >>> suspend/resume mode now. >> >> I believe your view of how the PM core works for devices that *don't* >> use async suspend is wrong! The PM core doesn't respect parent/child >> relations during the device system PM phase for these devices. > I agree with you for the following description. But, I never described how PM > core works for devices that don't use async mode. Where did you get my view > about this? I just said that PM core still ensure the dependency between > child and parent devices after using async mode, I never said that the method > ensuring dependency is the same for sync devices and async devices. You said it again. "PM core *still* ensures the dependency... after using async mode". I guess it depends what you mean by "still". :-) Anyway, it doesn't matter as I think we have sorted it out now. [...] >> This change will also affect SDIO combo cards. That means the when >> there is a mmc blk device driver bound to the mmc card, its >> ->suspend() methods will be called asynchronously. >> >> Have you considered that? Especially since there are nothing being >> mentioned about it in the change-log? > I have considered this, this patch still work for SDIO combo cards. >> >> Also, within this context I am wondering why you *only* enable async >> suspend for SDIO cards and not all cards (SD/MMC)? Is there a problem >> with doing that? > I am optimizing suspend/resume speed for some Intel's tablet platforms and > focusing only on the most time-consuming device path now. I will deliver > similar patch for SD/MMC card. Okay, thanks for sharing you plans! I would prefer if we instead enables async suspend for all types of card devices and the sdio func devices within one patch. I suggest we use mmc_add_card() and sdio_add_func(), to where we enable async suspend for the devices. [...] Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
