On Tue, Dec 28, 2010 at 9:21 PM, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > It looks like you could simply do a power down-power up cycle before trying to > load new firmware, just in case. I guess that's suboptimal for some reason? It would work, but we will not be able to unconditionally disable the radios (e.g. airplane mode comes to mind). > Please pretend that the runtime PM framework doesn't exist for a while. How > would you design things in that case? Duplicate most of runtime-PM's plumbing into the MMC/SDIO subsystem. Off the top of my hat: - We need the device hierarchy and the suspend/resume dependencies (a single SDIO card has several logical sub-devices, a.k.a SDIO functions) - We need to maintain usage_count for each device, and expose the same API to handle it - We need autosuspend for MMC cards (power them off on inactivity) - We need the same, or similar, locking plumbing - We probably need the same sysfs ABI as well: autosuspend_delay_ms, and even /sys/devices/.../power/control itself is useful (not for our device, but for others, sure) - ... Thanks, Ohad. -- 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
