omap_hsmmc: consider MMC_PM_KEEP_POWER on suspend/resume
Subsystems (5)
PATCH 1/3 omap_hsmmc: consider MMC_PM_KEEP_POWER on suspend/resume
When an mmc card has the MMC_PM_KEEP_POWER flag, it shouldn't be powered off on suspend (and thus doesn't have to be powered-on on resume)
While on it, change the suspend flow a bit, to make it a bit easier to follow.
--- drivers/mmc/host/omap_hsmmc.c | 24 +++++++++++++++--------- 1 files changed, 15 insertions(+), 9 deletions(-)
drivers/mmc/host/omap_hsmmc.c +15 -9
@@ -2174,13 +2174,7 @@ static int omap_hsmmc_suspend(struct device *dev)cancel_work_sync (&host->mmc_carddetect_work); ret =mmc_suspend_host (host->mmc); -if (ret ==0 ) { -omap_hsmmc_disable_irq (host); -OMAP_HSMMC_WRITE (host->base,HCTL , -OMAP_HSMMC_READ (host->base,HCTL ) & ~SDBP ); -if (host->got_dbclk) -clk_disable (host->dbclk); - }else { +if (ret) { host->suspended =0 ;if (host->pdata->resume) { ret = host->pdata->resume(&pdev->dev,
@@ -2189,9 +2183,20 @@ static int omap_hsmmc_suspend(struct device *dev)dev_dbg (mmc_dev (host->mmc),"Unmask interrupt failed\n" ); } + goto err; } -pm_runtime_put_sync (host->dev); + +if (!(host->mmc->pm_flags &MMC_PM_KEEP_POWER )) { +omap_hsmmc_disable_irq (host); +OMAP_HSMMC_WRITE (host->base,HCTL , +OMAP_HSMMC_READ (host->base,HCTL ) & ~SDBP ); + } +if (host->got_dbclk) +clk_disable (host->dbclk); + } +err: +pm_runtime_put_sync (host->dev);return ret; }
@@ -2211,7 +2216,8 @@ static int omap_hsmmc_resume(struct device *dev)if (host->got_dbclk)clk_enable (host->dbclk); -omap_hsmmc_conf_bus_power (host); +if (!(host->mmc->pm_flags &MMC_PM_KEEP_POWER )) +omap_hsmmc_conf_bus_power (host);if (host->pdata->resume) { ret = host->pdata->resume (&pdev->dev, host->slot_id);
Signature · 1 line
1.7.6.401.g6a319
PATCH 2/3 omap_hsmmc: add pm_caps field
Add pm_caps field to omap2_hsmmc_info and omap_mmc_slot_data structs, so we will be able to indicate mmc pm capabilities in the board file.
--- arch/arm/mach-omap2/hsmmc.c | 1 + arch/arm/mach-omap2/hsmmc.h | 1 + arch/arm/plat-omap/include/plat/mmc.h | 1 + drivers/mmc/host/omap_hsmmc.c | 2 ++ 4 files changed, 5 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/hsmmc.c +1 -0
@@ -306,6 +306,7 @@ static int __init omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c, mmc->slots[0 ].name = hc_name; mmc->nr_slots =1 ; mmc->slots[0 ].caps = c->caps; + mmc->slots[0 ].pm_caps = c->pm_caps; mmc->slots[0 ].internal_clock = !c->ext_clock; mmc->dma_mask =0xffffffff ;if (cpu_is_omap44xx ())
arch/arm/mach-omap2/hsmmc.h +1 -0
@@ -12,6 +12,7 @@ struct omap2_hsmmc_info {u8 mmc;/* controller 1/2/3 */ u32 caps;/* 4/8 wires and any additional host * capabilities OR'd (ref. linux/mmc/host.h) */ +u32 pm_caps;/* PM capabilities */ bool transceiver;/* MMC-2 option */ bool ext_clock;/* use external pin for input clock */ bool cover_only;/* No card detect - just cover switch */
arch/arm/plat-omap/include/plat/mmc.h +1 -0
@@ -79,6 +79,7 @@ struct omap_mmc_platform_data {*/ u8 wires;/* Used for the MMC driver on omap1 and 2420 */ u32 caps;/* Used for the MMC driver on 2430 and later */ +u32 pm_caps;/* PM capabilities of the mmc */ /* * nomux means "standard" muxing is wrong on this board, and
drivers/mmc/host/omap_hsmmc.c +2 -0
@@ -1985,6 +1985,8 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev)if (mmc_slot (host).nonremovable) mmc->caps |=MMC_CAP_NONREMOVABLE ; + mmc->pm_caps =mmc_slot (host).pm_caps; +omap_hsmmc_conf_bus_power (host);/* Select DMA lines */
Signature · 1 line
1.7.6.401.g6a319
PATCH 2/3 omap_hsmmc: add pm_caps field
Hi Eliad,
Quoted 3 lines · Eliad Peller
Add
pm_capsfield toomap2_hsmmc_infoandomap_mmc_slot_datastructs, so we will be able to indicate mmc pm capabilities in the board file.
Shouldn't this be user space runtime controllable? Instead of being a static per board decision?
Quoted 58 lines
Signed-off-by Eliad Peller <[email protected]>--- arch/arm/mach-omap2/hsmmc.c | 1 + arch/arm/mach-omap2/hsmmc.h | 1 + arch/arm/plat-omap/include/plat/mmc.h | 1 + drivers/mmc/host/omap_hsmmc.c | 2 ++ 4 files changed, 5 insertions(+), 0 deletions(-)arch/arm/mach-omap2/hsmmc.c +1
-0@@ -306,6 +306,7 @@ static int __init omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c, mmc->slots[0 ].name = hc_name; mmc->nr_slots =1 ; mmc->slots[0 ].caps = c->caps; + mmc->slots[0 ].pm_caps = c->pm_caps; mmc->slots[0 ].internal_clock = !c->ext_clock; mmc->dma_mask =0xffffffff ;if (cpu_is_omap44xx ())arch/arm/mach-omap2/hsmmc.h +1
-0@@ -12,6 +12,7 @@ struct omap2_hsmmc_info {u8 mmc;/* controller 1/2/3 */ u32 caps;/* 4/8 wires and any additional host * capabilities OR'd (ref. linux/mmc/host.h) */ +u32 pm_caps;/* PM capabilities */ bool transceiver;/* MMC-2 option */ bool ext_clock;/* use external pin for input clock */ bool cover_only;/* No card detect - just cover switch */ arch/arm/plat-omap/include/plat/mmc.h +1
-0@@ -79,6 +79,7 @@ struct omap_mmc_platform_data {*/ u8 wires;/* Used for the MMC driver on omap1 and 2420 */ u32 caps;/* Used for the MMC driver on 2430 and later */ +u32 pm_caps;/* PM capabilities of the mmc */ /* * nomux means "standard" muxing is wrong on this board, and drivers/mmc/host/omap_hsmmc.c +2
-0@@ -1985,6 +1985,8 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev)if (mmc_slot (host).nonremovable) mmc->caps |=MMC_CAP_NONREMOVABLE ; + mmc->pm_caps =mmc_slot (host).pm_caps; +omap_hsmmc_conf_bus_power (host);/* Select DMA lines */
Signature · 2 lines
Regards, Igor.
PATCH 2/3 omap_hsmmc: add pm_caps field
hi Igor,
Quoted 8 lines · Igor Grinberg
Quoted 3 lines · Eliad Peller
Add
pm_capsfield toomap2_hsmmc_infoandomap_mmc_slot_datastructs, so we will be able to indicate mmc pm capabilities in the board file.Shouldn't this be user space runtime controllable? Instead of being a static per board decision?
we only declare here support for the pm capabilities. the actual configuration of these capabilities is done at a later stage, and can be controlled (implicitly) by userspace (e.g. by enabling Wakeup-On-Wireless for the wl12xx chip).
regards,
Eliad.
PATCH 2/3 omap_hsmmc: add pm_caps field
Quoted 8 lines · Eliad Peller
hi Igor,
Quoted 5 lines · Igor Grinberg
Quoted 3 lines · Eliad Peller
Add
pm_capsfield toomap2_hsmmc_infoandomap_mmc_slot_datastructs, so we will be able to indicate mmc pm capabilities in the board file.
Quoted 7 lines
Quoted 3 lines
Shouldn't this be user space runtime controllable? Instead of being a static per board decision?
we only declare here support for the pm capabilities. the actual configuration of these capabilities is done at a later stage, and can be controlled (implicitly) by userspace (e.g. by enabling Wakeup-On-Wireless for the wl12xx chip).
This is good to hear, because patch 1/3 makes it look like the bus power does get immediately affected depending on that capability, isn't it?
Signature · 2 lines
Regards, Igor.
PATCH 2/3 omap_hsmmc: add pm_caps field
Quoted 12 lines · Igor Grinberg
Quoted 11 lines · Eliad Peller
hi Igor,
Quoted 8 lines · Igor Grinberg
Quoted 3 lines · Eliad Peller
Add
pm_capsfield toomap2_hsmmc_infoandomap_mmc_slot_datastructs, so we will be able to indicate mmc pm capabilities in the board file.Shouldn't this be user space runtime controllable? Instead of being a static per board decision?
Quoted 9 lines
Quoted 4 lines
we only declare here support for the pm capabilities. the actual configuration of these capabilities is done at a later stage, and can be controlled (implicitly) by userspace (e.g. by enabling Wakeup-On-Wireless for the wl12xx chip).
This is good to hear, because patch 1/3 makes it look like the bus power does get immediately affected depending on that capability, isn't it?
no.
it checks pm_flags (configured pm features) rather than pm_caps (supported pm features).
Eliad.
PATCH 2/3 omap_hsmmc: add pm_caps field
Quoted 18 lines · Eliad Peller
Quoted 17 lines · Igor Grinberg
Quoted 15 lines · Eliad Peller
hi Igor,
Quoted 8 lines · Igor Grinberg
Quoted 3 lines · Eliad Peller
Add
pm_capsfield toomap2_hsmmc_infoandomap_mmc_slot_datastructs, so we will be able to indicate mmc pm capabilities in the board file.Shouldn't this be user space runtime controllable? Instead of being a static per board decision?
we only declare here support for the pm capabilities. the actual configuration of these capabilities is done at a later stage, and can be controlled (implicitly) by userspace (e.g. by enabling Wakeup-On-Wireless for the wl12xx chip).
Quoted 7 lines
Quoted 4 lines
This is good to hear, because patch 1/3 makes it look like the bus power does get immediately affected depending on that capability, isn't it?
no.
it checkspm_flags(configured pm features) rather thanpm_caps(supported pm features).
I see. Thanks for the explanation.
Signature · 2 lines
Regards, Igor.
PATCH 3/3 omap: board-sdp4430: declare support for MMC_PM_KEEP_POWER
In reply to Eliad PellerDeclare support for keeping the power of the wlan chip while suspended. this is needed for Wakeup-On-Wireless.
--- arch/arm/mach-omap2/board-4430sdp.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-4430sdp.c +1 -0
@@ -420,6 +420,7 @@ static struct omap2_hsmmc_info mmc[] = { { .mmc = 5, .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_POWER_OFF_CARD, + .pm_caps = MMC_PM_KEEP_POWER, .gpio_cd = -EINVAL, .gpio_wp = -EINVAL, .ocr_mask = MMC_VDD_165_195,
Signature · 1 line
1.7.6.401.g6a319
PATCH 3/3 omap: board-sdp4430: declare support for MMC_PM_KEEP_POWER
Hi Eliad,
Quoted 7 lines · Eliad Peller
Declare support for keeping the power of the wlan chip while suspended. this is needed for Wakeup-On-Wireless.
Signed-off-by Eliad Peller <[email protected]>---
?arch/arm/mach-omap2/board-4430sdp.c | ? ?1 +
?1 files changed, 1 insertions(+), 0 deletions(-)
What about all the other board files that also have this structure? For example board-omap4panda.c? I think they should all be changed and the change should also be communicated more broadly for those board files which (unfortunately) are not upstream (or which are upstream but without the wl12xx-specific definitions on it, such as Beagle).
Signature · 2 lines
Cheers, Luca.
PATCH 3/3 omap: board-sdp4430: declare support for MMC_PM_KEEP_POWER
Quoted 9 lines · Luciano
Quoted 7 lines · Eliad Peller
Declare support for keeping the power of the wlan chip while suspended. this is needed for Wakeup-On-Wireless.
Signed-off-by Eliad Peller <[email protected]>---
?arch/arm/mach-omap2/board-4430sdp.c | ? ?1 +
?1 files changed, 1 insertions(+), 0 deletions(-)
Quoted 6 lines
What about all the other board files that also have this structure? For example
board-omap4panda.c? I think they should all be changed and the change should also be communicated more broadly for those board files which (unfortunately) are not upstream (or which are upstream but without the wl12xx-specific definitions on it, such as Beagle).
i preferred adding this capability only for boards i can test. unfortunately, i don't a panda/beagle setup.
anyway, i don't think we have to add it all at once. let's just do it one board at a time... i'll add support for zoom as well. any volunteers for panda/beagle? ;)
Eliad.
PATCH 3/3 omap: board-sdp4430: declare support for MMC_PM_KEEP_POWER
Quoted 16 lines · Eliad Peller
Quoted 9 lines · Luciano
Quoted 7 lines · Eliad Peller
Declare support for keeping the power of the wlan chip while suspended. this is needed for Wakeup-On-Wireless.
Signed-off-by Eliad Peller <[email protected]>--- arch/arm/mach-omap2/board-4430sdp.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)Quoted 6 lines
What about all the other board files that also have this structure? For example
board-omap4panda.c? I think they should all be changed and the change should also be communicated more broadly for those board files which (unfortunately) are not upstream (or which are upstream but without the wl12xx-specific definitions on it, such as Beagle).
Quoted 5 lines
i preferred adding this capability only for boards i can test. unfortunately, i don't a panda/beagle setup.
anyway, i don't think we have to add it all at once. let's just do it one board at a time... i'll add support for zoom as well. any volunteers for panda/beagle? ;)
Hmmm, okay, there is logic in that for the pragmatic, but this seems to be so clearly what is needed to solve the same problem with other boards that it could deserve changing all the board files. In practice, your changes may affect all the other boards too, regardless of whether you set the new flag or not. In any case, not my call here.
I may do it for panda later on, if I get the time to test it. For beagle, it doesn't really apply, because the wl12xx support is out-of-tree, unfortunately. :(
Signature · 2 lines
Cheers, Luca.
PATCH 3/3 omap: board-sdp4430: declare support for MMC_PM_KEEP_POWER
Hi Luciano,
Quoted 29 lines · Luciano Coelho
Quoted 16 lines · Eliad Peller
Quoted 9 lines · Luciano
Quoted 7 lines · Eliad Peller
Declare support for keeping the power of the wlan chip while suspended. this is needed for Wakeup-On-Wireless.
Signed-off-by Eliad Peller <[email protected]>--- arch/arm/mach-omap2/board-4430sdp.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)Quoted 6 lines
What about all the other board files that also have this structure? For example
board-omap4panda.c? I think they should all be changed and the change should also be communicated more broadly for those board files which (unfortunately) are not upstream (or which are upstream but without the wl12xx-specific definitions on it, such as Beagle).Quoted 5 lines
i preferred adding this capability only for boards i can test. unfortunately, i don't a panda/beagle setup.
anyway, i don't think we have to add it all at once. let's just do it one board at a time... i'll add support for zoom as well. any volunteers for panda/beagle? ;)Hmmm, okay, there is logic in that for the pragmatic, but this seems to be so clearly what is needed to solve the same problem with other boards that it could deserve changing all the board files. In practice, your changes may affect all the other boards too, regardless of whether you set the new flag or not. In any case, not my call here.
Quoted 3 lines
I may do it for panda later on, if I get the time to test it. For beagle, it doesn't really apply, because the wl12xx support is out-of-tree, unfortunately. :(
If I understood correctly, you want to change all the board files supporting the wl12xx wifi chip to have this capability set, right?
Isn't this immediately affects the power consumption in sleep state?
Shouldn't this be runtime controllable?
I bet there are many applications that do not care about WoW, but do care about the power consumption.
How does this change affect them?
Signature · 2 lines
Regards, Igor.
PATCH 3/3 omap: board-sdp4430: declare support for MMC_PM_KEEP_POWER
Quoted 1 line · Igor Grinberg
Hi Luciano,
Hi Igor,
Quoted 5 lines · Luciano Coelho
Quoted 3 lines
I may do it for panda later on, if I get the time to test it. For beagle, it doesn't really apply, because the wl12xx support is out-of-tree, unfortunately. :(
Quoted 9 lines
If I understood correctly, you want to change all the board files supporting the wl12xx wifi chip to have this capability set, right?
Isn't this immediately affects the power consumption in sleep state?
Shouldn't this be runtime controllable?
I bet there are many applications that do not care about WoW, but do care about the power consumption.
How does this change affect them?
Good point, I don't know. :) Probably Eliad has the answer for that.
In any case, I don't see why this behaviour should be different in the different board files. If there is the problem of power consumption while in suspend, we will have it also with the 4430sdp board.
I'm not sure about doing it dynamically, though. I think it would be more of a kernel configuration option or something. At least the board file is not the correct place to decide whether the wl12xx chip will support WoW or not. And, if we change only the MMC capabilities of the wl12xx chip, we won't hurt other scenarios, when the wl12xx chip is not in use.
Signature · 2 lines
Cheers, Luca.
PATCH 3/3 omap: board-sdp4430: declare support for MMC_PM_KEEP_POWER
Quoted 16 lines · Luciano Coelho
Quoted 5 lines · Igor Grinberg
Quoted 3 lines · Luciano Coelho
I may do it for panda later on, if I get the time to test it. ?For beagle, it doesn't really apply, because the wl12xx support is out-of-tree, unfortunately. :(
Quoted 9 lines
If I understood correctly, you want to change all the board files supporting the wl12xx wifi chip to have this capability set, right?
Isn't this immediately affects the power consumption in sleep state?
Shouldn't this be runtime controllable?
I bet there are many applications that do not care about WoW, but do care about the power consumption.
How does this change affect them?
Quoted 2 lines
Good point, I don't know. :) Probably Eliad has the answer for that.
see the discussion regarding patch [2/3] - we only declare here support for this capability, but it's disabled by default.
Eliad.
PATCH 3/3 omap: board-sdp4430: declare support for MMC_PM_KEEP_POWER
Quoted 17 lines · Eliad Peller
Quoted 16 lines · Luciano Coelho
Quoted 14 lines · Igor Grinberg
Quoted 3 lines · Luciano Coelho
I may do it for panda later on, if I get the time to test it. For beagle, it doesn't really apply, because the wl12xx support is out-of-tree, unfortunately. :(
If I understood correctly, you want to change all the board files supporting the wl12xx wifi chip to have this capability set, right?
Isn't this immediately affects the power consumption in sleep state?
Shouldn't this be runtime controllable?
I bet there are many applications that do not care about WoW, but do care about the power consumption.
How does this change affect them?
Quoted 4 lines
Quoted 2 lines
Good point, I don't know. :) Probably Eliad has the answer for that.
see the discussion regarding patch [2/3] - we only declare here support for this capability, but it's disabled by default.
Great, thanks! :) I now also understand the difference between the pm_flags and pm_caps. :)
So, back to where we started, we should add the capability to all boards that define the MMC capabilities of the wl12xx chip. No matter who will do it. :)
Signature · 2 lines
Cheers, Luca.
PATCH 1/3 omap_hsmmc: consider MMC_PM_KEEP_POWER on suspend/resume
In reply to Eliad PellerHi,
Quoted 8 lines · Eliad Peller
When an mmc card has the
MMC_PM_KEEP_POWERflag, it shouldn't be powered off on suspend (and thus doesn't have to be powered-on on resume)While on it, change the suspend flow a bit, to make it a bit easier to follow.
Signed-off-by Eliad Peller <[email protected]>
Tony, feel free to merge this patchset (if you're happy with the rest of it) through your tree, with my:
for this patch. Thanks,
- Chris.
Signature · 2 lines
Chris Ball <[email protected]> <http://printf.net/> One Laptop Per Child
Tony Lindgren
maintainerPATCH 1/3 omap_hsmmc: consider MMC_PM_KEEP_POWER on suspend/resume
Quoted 10 lines · Chris Ball
Hi,
Quoted 7 lines · Eliad Peller
When an mmc card has the
MMC_PM_KEEP_POWERflag, it shouldn't be powered off on suspend (and thus doesn't have to be powered-on on resume)While on it, change the suspend flow a bit, to make it a bit easier to follow.
Quoted 8 lines
Quoted 1 line
Signed-off-by Eliad Peller <[email protected]>Tony, feel free to merge this patchset (if you're happy with the rest of it) through your tree, with my:
Acked-by Chris Ball <[email protected]>for this patch. Thanks,
Thanks applying these into omap driver branch.
Regards,
Tony