[PATCH 1/3] omap_hsmmc: consider MMC_PM_KEEP_POWER on suspend/resume

[PATCH 1/3] omap_hsmmc: consider MMC_PM_KEEP_POWER on suspend/resume

[Eliad Peller]

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.

Signed-off-by: Eliad Peller <eliad@wizery.com>
---
 drivers/mmc/host/omap_hsmmc.c |   24 +++++++++++++++---------
 1 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 21e4a79..ec7c83c 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -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);
-- 
1.7.6.401.g6a319

[PATCH 2/3] omap_hsmmc: add pm_caps field

[Eliad Peller]

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.

Signed-off-by: Eliad Peller <eliad@wizery.com>
---
 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(-)

diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 097a42d..d00a54a 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -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())
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index f757e78..c440973 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -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 */
diff --git a/arch/arm/plat-omap/include/plat/mmc.h b/arch/arm/plat-omap/include/plat/mmc.h
index c7b8741..d3263ac 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -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
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index ec7c83c..2bc964a6 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -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 */
-- 
1.7.6.401.g6a319

[PATCH 3/3] omap: board-sdp4430: declare support for MMC_PM_KEEP_POWER

[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 <eliad@wizery.com>
---
 arch/arm/mach-omap2/board-4430sdp.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index c7cef44..fd8b2a5 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -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,
-- 
1.7.6.401.g6a319

[PATCH 3/3] omap: board-sdp4430: declare support for MMC_PM_KEEP_POWER

[Coelho, Luciano]

Hi Eliad,

On Tue, Nov 22, 2011 at 4:02 PM, Eliad Peller <eliad@wizery.com> wrote:
> Declare support for keeping the power of the wlan chip
> while suspended. this is needed for Wakeup-On-Wireless.
>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
> ?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).


-- 
Cheers,
Luca.

[PATCH 3/3] omap: board-sdp4430: declare support for MMC_PM_KEEP_POWER

[Eliad Peller]

On Mon, Nov 28, 2011 at 9:50 AM, Coelho, Luciano <coelho@ti.com> wrote:
> On Tue, Nov 22, 2011 at 4:02 PM, Eliad Peller <eliad@wizery.com> wrote:
>> Declare support for keeping the power of the wlan chip
>> while suspended. this is needed for Wakeup-On-Wireless.
>>
>> Signed-off-by: Eliad Peller <eliad@wizery.com>
>> ---
>> ?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).
>
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

[Luciano Coelho]

On Mon, 2011-11-28 at 10:26 +0200, Eliad Peller wrote: 
> On Mon, Nov 28, 2011 at 9:50 AM, Coelho, Luciano <coelho@ti.com> wrote:
> > On Tue, Nov 22, 2011 at 4:02 PM, Eliad Peller <eliad@wizery.com> wrote:
> >> Declare support for keeping the power of the wlan chip
> >> while suspended. this is needed for Wakeup-On-Wireless.
> >>
> >> Signed-off-by: Eliad Peller <eliad@wizery.com>
> >> ---
> >>  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).
> >
> 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. :(

-- 
Cheers,
Luca.

[PATCH 2/3] omap_hsmmc: add pm_caps field

[Igor Grinberg]

Hi Eliad,

On 11/22/11 16:02, Eliad Peller wrote:
> 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.

Shouldn't this be user space runtime controllable?
Instead of being a static per board decision?

> 
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
>  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(-)
> 
> diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
> index 097a42d..d00a54a 100644
> --- a/arch/arm/mach-omap2/hsmmc.c
> +++ b/arch/arm/mach-omap2/hsmmc.c
> @@ -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())
> diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
> index f757e78..c440973 100644
> --- a/arch/arm/mach-omap2/hsmmc.h
> +++ b/arch/arm/mach-omap2/hsmmc.h
> @@ -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 */
> diff --git a/arch/arm/plat-omap/include/plat/mmc.h b/arch/arm/plat-omap/include/plat/mmc.h
> index c7b8741..d3263ac 100644
> --- a/arch/arm/plat-omap/include/plat/mmc.h
> +++ b/arch/arm/plat-omap/include/plat/mmc.h
> @@ -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
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index ec7c83c..2bc964a6 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -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 */

-- 
Regards,
Igor.

[PATCH 2/3] omap_hsmmc: add pm_caps field

[Eliad Peller]

hi Igor,

On Mon, Nov 28, 2011 at 11:15 AM, Igor Grinberg <grinberg@compulab.co.il> wrote:
> On 11/22/11 16:02, Eliad Peller wrote:
>> 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.
>
> 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 3/3] omap: board-sdp4430: declare support for MMC_PM_KEEP_POWER

[Igor Grinberg]

Hi Luciano,

On 11/28/11 11:08, Luciano Coelho wrote:
> On Mon, 2011-11-28 at 10:26 +0200, Eliad Peller wrote: 
>> On Mon, Nov 28, 2011 at 9:50 AM, Coelho, Luciano <coelho@ti.com> wrote:
>>> On Tue, Nov 22, 2011 at 4:02 PM, Eliad Peller <eliad@wizery.com> wrote:
>>>> Declare support for keeping the power of the wlan chip
>>>> while suspended. this is needed for Wakeup-On-Wireless.
>>>>
>>>> Signed-off-by: Eliad Peller <eliad@wizery.com>
>>>> ---
>>>>  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).
>>>
>> 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. :(

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?


-- 
Regards,
Igor.

[PATCH 3/3] omap: board-sdp4430: declare support for MMC_PM_KEEP_POWER

[Luciano Coelho]

On Mon, 2011-11-28 at 11:26 +0200, Igor Grinberg wrote: 
> Hi Luciano,

Hi Igor,


> On 11/28/11 11:08, Luciano Coelho wrote:
> > 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?

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.

-- 
Cheers,
Luca.

[PATCH 2/3] omap_hsmmc: add pm_caps field

[Igor Grinberg]

On 11/28/11 11:23, Eliad Peller wrote:
> hi Igor,
> 
> On Mon, Nov 28, 2011 at 11:15 AM, Igor Grinberg <grinberg@compulab.co.il> wrote:
>> On 11/22/11 16:02, Eliad Peller wrote:
>>> 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.
>>
>> 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?


-- 
Regards,
Igor.

[PATCH 2/3] omap_hsmmc: add pm_caps field

[Eliad Peller]

On Mon, Nov 28, 2011 at 12:01 PM, Igor Grinberg <grinberg@compulab.co.il> wrote:
> On 11/28/11 11:23, Eliad Peller wrote:
>> hi Igor,
>>
>> On Mon, Nov 28, 2011 at 11:15 AM, Igor Grinberg <grinberg@compulab.co.il> wrote:
>>> On 11/22/11 16:02, Eliad Peller wrote:
>>>> 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.
>>>
>>> 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?
>
no.
it checks pm_flags (configured pm features) rather than pm_caps
(supported pm features).

Eliad.

[PATCH 3/3] omap: board-sdp4430: declare support for MMC_PM_KEEP_POWER

[Eliad Peller]

On Mon, Nov 28, 2011 at 11:58 AM, Luciano Coelho <coelho@ti.com> wrote:
> On Mon, 2011-11-28 at 11:26 +0200, Igor Grinberg wrote:
>> On 11/28/11 11:08, Luciano Coelho wrote:
>> > 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?
>
> 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

[Luciano Coelho]

On Mon, 2011-11-28 at 12:12 +0200, Eliad Peller wrote: 
> On Mon, Nov 28, 2011 at 11:58 AM, Luciano Coelho <coelho@ti.com> wrote:
> > On Mon, 2011-11-28 at 11:26 +0200, Igor Grinberg wrote:
> >> On 11/28/11 11:08, Luciano Coelho wrote:
> >> > 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?
> >
> > 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. :)

-- 
Cheers,
Luca.

[PATCH 2/3] omap_hsmmc: add pm_caps field

[Igor Grinberg]

On 11/28/11 12:07, Eliad Peller wrote:
> On Mon, Nov 28, 2011 at 12:01 PM, Igor Grinberg <grinberg@compulab.co.il> wrote:
>> On 11/28/11 11:23, Eliad Peller wrote:
>>> hi Igor,
>>>
>>> On Mon, Nov 28, 2011 at 11:15 AM, Igor Grinberg <grinberg@compulab.co.il> wrote:
>>>> On 11/22/11 16:02, Eliad Peller wrote:
>>>>> 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.
>>>>
>>>> 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?
>>
> no.
> it checks pm_flags (configured pm features) rather than pm_caps
> (supported pm features).

I see. Thanks for the explanation.


-- 
Regards,
Igor.

[PATCH 1/3] omap_hsmmc: consider MMC_PM_KEEP_POWER on suspend/resume

[Chris Ball]

Hi,

On Tue, Nov 22 2011, Eliad Peller wrote:
> 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.
>
> Signed-off-by: Eliad Peller <eliad@wizery.com>

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 <cjb@laptop.org>

for this patch.  Thanks,

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

[PATCH 1/3] omap_hsmmc: consider MMC_PM_KEEP_POWER on suspend/resume

[Tony Lindgren]

* Chris Ball <cjb@laptop.org> [111201 09:40]:
> Hi,
> 
> On Tue, Nov 22 2011, Eliad Peller wrote:
> > 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.
> >
> > Signed-off-by: Eliad Peller <eliad@wizery.com>
> 
> 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 <cjb@laptop.org>
> 
> for this patch.  Thanks,

Thanks applying these into omap driver branch.

Regards,

Tony