Return-path: Received: from mail-iy0-f194.google.com ([209.85.210.194]:62806 "EHLO mail-iy0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750786Ab0L2Geq convert rfc822-to-8bit (ORCPT ); Wed, 29 Dec 2010 01:34:46 -0500 MIME-Version: 1.0 In-Reply-To: References: From: Ohad Ben-Cohen Date: Wed, 29 Dec 2010 08:34:25 +0200 Message-ID: Subject: Re: [linux-pm] subtle pm_runtime_put_sync race and sdio functions To: Alan Stern Cc: "Rafael J. Wysocki" , linux-pm@lists.linux-foundation.org, Johannes Berg , linux-wireless@vger.kernel.org, linux-mmc@vger.kernel.org, Ido Yariv , Kevin Hilman Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Tue, Dec 28, 2010 at 11:46 PM, Alan Stern wrote: > What's the relation between mmc_power_off() and mmc_power_save_host()? Essentially they are the same - mmc_power_off() is the one that actually powers off the card. mmc_power_save_host() just invokes first a bus-specific ->power_save() handler (if one exists). > Does one merely go into a low-power state whereas the other does the > complete-power-off reset? No, think of them as the same. Both will lead to a complete power off. The mmc_power_off() is just an internal function which belongs to the MMC core. > During wlan-interface-down, it's not necessary to reduce the power > level; it's merely desirable. ?That's exactly the sort of thing runtime > PM is meant for. ?Hence the existing call to pm_runtime_put_sync() is > sufficient. Not exactly - think of airplane mode, where we must ensure the radios are disabled, without being blocked by /sys/devices/.../power/control - we will need to bypass runtime PM in this scenario too. > Put it another way: ?Suppose an SDIO card has more than one function > and you need to reset the wl1271 function. ?It sounds like there's no > way to do this without resetting the other functions as well. ?What > happens if another function's driver is busy and can't allow a reset > just then? That's a chip specific thing. In our case, there is no other active SDIO function. Other vendors which does employ several SDIO functions have a separate reset for each function _in addition_ to the power line. So for them the runtime PM model is just great - they never care if the actual power is down or not - it's really just about power consumption, and nothing else. When they need an unconditional reset, they just use the appropriate reset line. In our case we have a single control for both power and reset functionality (actually we do have a separate power line to the device, but it is not controlled by software - it is fed directly from the battery rail).