MMC_CAP_POWER_OFF_CARD, MMC_PM_KEEP_POWER - when to set
Hi all I'm a bit confused by the above two macros. The latter of them seems rather clear: it indicates, whether the card power should be kept across all kinds of suspend. Whereas the former one is not so clear. Some sources indicate, that this flag means, that the host / board are _capable_ of powering down the slot. Others seem to suggest, that it also means, that the card can handle being powered off. The former meaning would make sense to me, but then - why would one want to check it when deciding whether or not to use runtime PM with the host? Isn't it exactly what the MMC_PM_KEEP_POWER flag is for? If MMC_CAP_POWER_OFF_CARD does indeed mean, that the host is able to switch the power off and on, then it can be safely set almost always. E.g., if the slot is supplied by a regulator, this flag can be enabled automatically? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
Re: MMC_CAP_POWER_OFF_CARD, MMC_PM_KEEP_POWER - when to set
Hi Guennadi, On Thu, May 24, 2012 at 2:18 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Some sources indicate, that this flag means, that the host / board are _capable_ of powering down the slot. Others seem to suggest, that it also means, that the card can handle being powered off. Take a look how MMC_CAP_POWER_OFF_CARD is described in the commit log which added it: commit ed919b0125b26dcc052e44836f66e7e1f5c49c7e Author: Ohad Ben-Cohen o...@wizery.com Date: Fri Nov 19 09:29:09 2010 +0200 mmc: sdio: fix runtime PM anomalies by introducing MMC_CAP_POWER_OFF_CARD Some board/card/host configurations are not capable of powering off the card after boot. To support such configurations, and to allow smoother transition to runtime PM behavior, MMC_CAP_POWER_OFF_CARD is added, so hosts need to explicitly indicate whether it's OK to power off their cards after boot. SDIO core will enable runtime PM for a card only if that cap is set. As a result, the card will be powered down after boot, and will only be powered up again when a driver is loaded (and then it's up to the driver to decide whether power will be kept or not). This will prevent sdio_bus_probe() failures with setups that do not support powering off the card. Reported-and-tested-by: Daniel Drake d...@laptop.org Reported-and-tested-by: Arnd Hannemann a...@arndnet.de Signed-off-by: Ohad Ben-Cohen o...@wizery.com Signed-off-by: Chris Ball c...@laptop.org The former meaning would make sense to me, but then - why would one want to check it when deciding whether or not to use runtime PM with the host? Because if a certain board/host/card setup doesn't support it, then we should not power off the card, because doing so means we'll have to reset the entire board if we want the card to work again. Isn't it exactly what the MMC_PM_KEEP_POWER flag is for? No, MMC_PM_KEEP_POWER is different: it is a dynamic user decision controlling whether the card should stay on while the system is suspended, while MMC_CAP_POWER_OFF_CARD is a static capability of the hardware. If MMC_CAP_POWER_OFF_CARD does indeed mean, that the host is able to switch the power off and on, then it can be safely set almost always. E.g., if the slot is supplied by a regulator, this flag can be enabled automatically? Not always. For example, consider a (non-fictional) configuration where you can power off the card, but after you power it on again, you must toggle some card reset pin for it to work, but your board doesn't have that reset pin hardwired to any gpio. In this case, despite the existing regulator, you must not power off the card, because doing so requires you to reset your entire board if you want the card to work again. Thanks, Ohad. -- 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
Re: MMC_CAP_POWER_OFF_CARD, MMC_PM_KEEP_POWER - when to set
On Thu, 24 May 2012, Ohad Ben-Cohen wrote: Hi Guennadi, On Thu, May 24, 2012 at 2:18 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Some sources indicate, that this flag means, that the host / board are _capable_ of powering down the slot. Others seem to suggest, that it also means, that the card can handle being powered off. Take a look how MMC_CAP_POWER_OFF_CARD is described in the commit log which added it: Yes, I read it, it was one of sources. commit ed919b0125b26dcc052e44836f66e7e1f5c49c7e Author: Ohad Ben-Cohen o...@wizery.com Date: Fri Nov 19 09:29:09 2010 +0200 mmc: sdio: fix runtime PM anomalies by introducing MMC_CAP_POWER_OFF_CARD Some board/card/host configurations are not capable of powering off the card after boot. To support such configurations, and to allow smoother transition to runtime PM behavior, MMC_CAP_POWER_OFF_CARD is added, so hosts need to explicitly indicate whether it's OK to power off their cards after boot. SDIO core will enable runtime PM for a card only if that cap is set. As a result, the card will be powered down after boot, and will only be powered up again when a driver is loaded (and then it's up to the driver to decide whether power will be kept or not). This will prevent sdio_bus_probe() failures with setups that do not support powering off the card. Reported-and-tested-by: Daniel Drake d...@laptop.org Reported-and-tested-by: Arnd Hannemann a...@arndnet.de Signed-off-by: Ohad Ben-Cohen o...@wizery.com Signed-off-by: Chris Ball c...@laptop.org The former meaning would make sense to me, but then - why would one want to check it when deciding whether or not to use runtime PM with the host? Because if a certain board/host/card setup doesn't support it, then we should not power off the card, because doing so means we'll have to reset the entire board if we want the card to work again. How do you know, if this is a normal sd-card slot? Isn't it exactly what the MMC_PM_KEEP_POWER flag is for? No, MMC_PM_KEEP_POWER is different: it is a dynamic user decision controlling whether the card should stay on while the system is suspended, Isn't it both? mmc_host::pm_caps is static capabilities, and ::pm_flags is the current dynamic configuration? while MMC_CAP_POWER_OFF_CARD is a static capability of the hardware. If MMC_CAP_POWER_OFF_CARD does indeed mean, that the host is able to switch the power off and on, then it can be safely set almost always. E.g., if the slot is supplied by a regulator, this flag can be enabled automatically? Not always. For example, consider a (non-fictional) configuration where you can power off the card, but after you power it on again, you must toggle some card reset pin for it to work, but your board doesn't have that reset pin hardwired to any gpio. In this case, despite the existing regulator, you must not power off the card, because doing so requires you to reset your entire board if you want the card to work again. A complete board reset in this case will differ from the card power-off only in the state of the rest of the SD-card ping, e.g., the clock. So, additionally switching off the clock in this case should be equivalent to the board reset? Given the above, wouldn't it be sufficient to test (mmc-pm_flags MMC_PM_KEEP_POWER) to decide, whether the card can be suspended? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
Re: MMC_CAP_POWER_OFF_CARD, MMC_PM_KEEP_POWER - when to set
Hi Guennadi, On Thu, May 24, 2012 at 4:07 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: How do you know, if this is a normal sd-card slot? Not sure I follow the question. But if you ask whether we can dynamically set MMC_CAP_POWER_OFF_CARD, then we can't (with what we know today). This CAP is dealing with issues of specific boards which, unfortunately, we have no way (today) to dynamically probe. No, MMC_PM_KEEP_POWER is different: it is a dynamic user decision controlling whether the card should stay on while the system is suspended, Isn't it both? Yes, you're right - we need host support to keep the card powered while the system is suspended. A complete board reset in this case will differ from the card power-off only in the state of the rest of the SD-card ping, e.g., the clock. So, additionally switching off the clock in this case should be equivalent to the board reset? Not really - consider the example I gave you, where you are required to toggle a card reset pin after you power cycle it, but there's no way to control that pin. In that case, only a complete board reset can help you. Given the above, wouldn't it be sufficient to test (mmc-pm_flags MMC_PM_KEEP_POWER) to decide, whether the card can be suspended? No, MMC_PM_KEEP_POWER is about the ability (and desire) to keep the card powered while the system is suspended. MMC_CAP_POWER_OFF_CARD is about the ability to power off the card without killing it completely until the next board reset. These two flags really address completely different problems, despite the similar nomenclature. Thanks, Ohad. -- 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
Re: MMC_CAP_POWER_OFF_CARD, MMC_PM_KEEP_POWER - when to set
On Thu, 24 May 2012, Ohad Ben-Cohen wrote: Hi Guennadi, On Thu, May 24, 2012 at 4:07 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: How do you know, if this is a normal sd-card slot? Not sure I follow the question. Sorry, I mean - you don't know what card will be plugged in, so, you cannot know, whether that specific card and its driver can be safely powered off. But if you ask whether we can dynamically set MMC_CAP_POWER_OFF_CARD, then we can't (with what we know today). This CAP is dealing with issues of specific boards which, unfortunately, we have no way (today) to dynamically probe. No, MMC_PM_KEEP_POWER is different: it is a dynamic user decision controlling whether the card should stay on while the system is suspended, Isn't it both? Yes, you're right - we need host support to keep the card powered while the system is suspended. A complete board reset in this case will differ from the card power-off only in the state of the rest of the SD-card ping, e.g., the clock. So, additionally switching off the clock in this case should be equivalent to the board reset? Not really - consider the example I gave you, where you are required to toggle a card reset pin after you power cycle it, but there's no way to control that pin. In that case, only a complete board reset can help you. Given the above, wouldn't it be sufficient to test (mmc-pm_flags MMC_PM_KEEP_POWER) to decide, whether the card can be suspended? No, MMC_PM_KEEP_POWER is about the ability (and desire) to keep the card powered while the system is suspended. MMC_CAP_POWER_OFF_CARD is about the ability to power off the card without killing it completely until the next board reset. Ok, I think, it's this: MMC_PM_KEEP_POWER is for system-wide suspend / resume, whereas MMC_CAP_POWER_OFF_CARD is for runtime PM. Am I right? In that case, I think, they also should function similar - wouldn't it make sense to use MMC_CAP_POWER_OFF_CARD similar to MMC_PM_KEEP_POWER - as a static capability flag (meaning, whether the board is physically able to switch power) and a dynamic flag, that, say, an SDIO function driver could set if it knows, that it cannot handle runtime power switching properly? Thanks Guennadi These two flags really address completely different problems, despite the similar nomenclature. Thanks, Ohad. --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
Re: MMC_CAP_POWER_OFF_CARD, MMC_PM_KEEP_POWER - when to set
Hi Guennadi, On Thu, May 24, 2012 at 5:06 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Sorry, I mean - you don't know what card will be plugged in, so, you cannot know, whether that specific card and its driver can be safely powered off. We do know in certain cases, most commonly with wifi SDIO cards which are hardwired to the board. Ok, I think, it's this: MMC_PM_KEEP_POWER is for system-wide suspend / resume, whereas MMC_CAP_POWER_OFF_CARD is for runtime PM. Am I right? MMC_CAP_POWER_OFF_CARD is used by SDIO runtime PM, but I won't classify it as runtime PM specific. It describes the hardware, and not inherently limited to a specific use case. that case, I think, they also should function similar Can you explain why ? - wouldn't it make sense to use MMC_CAP_POWER_OFF_CARD similar to MMC_PM_KEEP_POWER - as a static capability flag (meaning, whether the board is physically able to switch power) and a dynamic flag, that, say, an SDIO function driver could set if it knows, that it cannot handle runtime power switching properly? I'm not sure I'm following the reasoning. Can you explain what are you trying to solve ? Is there a specific problem you have in mind ? Thanks, Ohad. -- 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
Re: MMC_CAP_POWER_OFF_CARD, MMC_PM_KEEP_POWER - when to set
Hi Ohad On Thu, 24 May 2012, Ohad Ben-Cohen wrote: Hi Guennadi, On Thu, May 24, 2012 at 5:06 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Sorry, I mean - you don't know what card will be plugged in, so, you cannot know, whether that specific card and its driver can be safely powered off. We do know in certain cases, most commonly with wifi SDIO cards which are hardwired to the board. Yes, exactly, in certain cases. And when it's not hard-wired? Ok, I think, it's this: MMC_PM_KEEP_POWER is for system-wide suspend / resume, whereas MMC_CAP_POWER_OFF_CARD is for runtime PM. Am I right? MMC_CAP_POWER_OFF_CARD is used by SDIO runtime PM, but I won't classify it as runtime PM specific. It describes the hardware, and not inherently limited to a specific use case. Ok that case, I think, they also should function similar Can you explain why ? Because with pluggable cards one flag is not enough. I think, you need (1) board capability to switch power, and (2) driver's allowance to power the card down. - wouldn't it make sense to use MMC_CAP_POWER_OFF_CARD similar to MMC_PM_KEEP_POWER - as a static capability flag (meaning, whether the board is physically able to switch power) and a dynamic flag, that, say, an SDIO function driver could set if it knows, that it cannot handle runtime power switching properly? I'm not sure I'm following the reasoning. Can you explain what are you trying to solve ? Is there a specific problem you have in mind ? The problem of hot-pluggable cards. One card / driver combination will support powering down at runtime, another one will not. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
Re: MMC_CAP_POWER_OFF_CARD, MMC_PM_KEEP_POWER - when to set
Hi Guennadi, On Thu, May 24, 2012 at 6:42 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Yes, exactly, in certain cases. And when it's not hard-wired? We don't support this yet. Daniel suggested using either black or white listing (based on vendor/device id presumably) so we can support regular cards without breaking others, but I'm not sure if Daniel had any free cycles to look into it. Because with pluggable cards one flag is not enough. I think, you need (1) board capability to switch power, and (2) driver's allowance to power the card down. ... The problem of hot-pluggable cards. One card / driver combination will support powering down at runtime, another one will not. Ah ok now I understand you, thanks for the explanation. Whether or not to involve the driver here probably depends on the actual hardware requirements. E.g., if the vendor/device id is enough information, then we might be able to implement this below the drivers without involving them. But in case only the driver could tell between variants of specific chips, then a generic white/black listing might not be enough. Feel free to propose a solution, but please back it up with real hardware and show that it satisfies the MMC_CAP_POWER_OFF_CARD issues we had in the past. Thanks, Ohad. -- 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
Re: MMC_CAP_POWER_OFF_CARD, MMC_PM_KEEP_POWER - when to set
On Thu, May 24, 2012 at 10:08 PM, Ohad Ben-Cohen o...@wizery.com wrote: Feel free to propose a solution, but please back it up with real hardware and show that it satisfies the MMC_CAP_POWER_OFF_CARD issues we had in the past. The solution should also still support powering off the card even if a driver for it isn't loaded (at least for chips that support it). Thanks, Ohad. -- 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
Re: MMC_CAP_POWER_OFF_CARD, MMC_PM_KEEP_POWER - when to set
On Thu, 24 May 2012, Ohad Ben-Cohen wrote: Hi Guennadi, On Thu, May 24, 2012 at 6:42 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Yes, exactly, in certain cases. And when it's not hard-wired? We don't support this yet. Ic, so, basically, for boards with normal SD-card slots SDIO-card runtime PM is not supported. Daniel suggested using either black or white listing (based on vendor/device id presumably) so we can support regular cards without breaking others, but I'm not sure if Daniel had any free cycles to look into it. Because with pluggable cards one flag is not enough. I think, you need (1) board capability to switch power, and (2) driver's allowance to power the card down. ... The problem of hot-pluggable cards. One card / driver combination will support powering down at runtime, another one will not. Ah ok now I understand you, thanks for the explanation. Sorry, I had to clarify the situation first with the flags before I could formulate the problem properly. Whether or not to involve the driver here probably depends on the actual hardware requirements. E.g., if the vendor/device id is enough information, then we might be able to implement this below the drivers without involving them. But in case only the driver could tell between variants of specific chips, then a generic white/black listing might not be enough. I think it'd be better to go with driver-assisted PM straight away instead of implementing black-/white-lists to later find out about cards with the same IDs and different behaviour. Feel free to propose a solution, but please back it up with real hardware and show that it satisfies the MMC_CAP_POWER_OFF_CARD issues we had in the past. Thanks:-) It was important for me in the first place to understand the problem. Now that the problem has become clearer we can think about whether, when and how to solve it and who shall do it:-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
Re: MMC_CAP_POWER_OFF_CARD, MMC_PM_KEEP_POWER - when to set
On Fri, May 25, 2012 at 12:15 AM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: I think it'd be better to go with driver-assisted PM straight away instead of implementing black-/white-lists to later find out about cards with the same IDs and different behaviour. I'm not sure - we usually prefer to evolve as real use cases show up instead of aiming for the final design in the first place (which, as practice shows, most likely anyway have to change when the real use case show up). This usually proves itself as the minimum effort for nailing the existing requirements (less code to develop, debug and maintain). We also want to support powering off the cards even if their driver isn't at all loaded (as I wrote previously). Thanks:-) It was important for me in the first place to understand the problem. Now that the problem has become clearer we can think about whether, when and how to solve it and who shall do it:-) Oh I thought you volunteered ! ;) Thanks, Ohad. -- 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
