[PATCH V1] mfd: tps65910: Add wakeup support

[PATCH V1] mfd: tps65910: Add wakeup support

[Laxman Dewangan]

Adding wakeup support for PMIC device 65910. This can be
selected through the board specific platform data.

The wakeup should enabled if PMIC need to be configure for
waking up system through RTC or ONKEY.

Signed-off-by: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
This patch will enable the wakeup functionality through
device tps65910/tps65911.

 drivers/mfd/tps65910-irq.c   |    9 +++++++++
 drivers/mfd/tps65910.c       |    1 +
 include/linux/mfd/tps65910.h |    2 ++
 3 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/drivers/mfd/tps65910-irq.c b/drivers/mfd/tps65910-irq.c
index a56be93..8b6f423 100644
--- a/drivers/mfd/tps65910-irq.c
+++ b/drivers/mfd/tps65910-irq.c
@@ -210,6 +210,15 @@ int tps65910_irq_init(struct tps65910 *tps65910, int irq,
 	if (ret != 0)
 		dev_err(tps65910->dev, "Failed to request IRQ: %d\n", ret);
 
+	if (!ret && pdata->en_wakeup) {
+		device_init_wakeup(tps65910->dev, 1);
+		ret = enable_irq_wake(irq);
+		if (ret < 0)
+			dev_warn(tps65910->dev, "Can't enable IRQ as wake "
+				"source: %d\n", ret);
+		return 0;
+	}
+
 	return ret;
 }
 
diff --git a/drivers/mfd/tps65910.c b/drivers/mfd/tps65910.c
index 8517481..88e3dec 100644
--- a/drivers/mfd/tps65910.c
+++ b/drivers/mfd/tps65910.c
@@ -169,6 +169,7 @@ static int tps65910_i2c_probe(struct i2c_client *i2c,
 
 	init_data->irq = pmic_plat_data->irq;
 	init_data->irq_base = pmic_plat_data->irq_base;
+	init_data->en_wakeup = pmic_plat_data->en_wakeup;
 
 	tps65910_gpio_init(tps65910, pmic_plat_data->gpio_base);
 
diff --git a/include/linux/mfd/tps65910.h b/include/linux/mfd/tps65910.h
index d0cb12e..ba8eb6a 100644
--- a/include/linux/mfd/tps65910.h
+++ b/include/linux/mfd/tps65910.h
@@ -777,6 +777,7 @@ struct tps65910_board {
 	int gpio_base;
 	int irq;
 	int irq_base;
+	int en_wakeup;
 	int vmbch_threshold;
 	int vmbch2_threshold;
 	struct regulator_init_data *tps65910_pmic_init_data[TPS65910_NUM_REGS];
@@ -813,6 +814,7 @@ struct tps65910 {
 struct tps65910_platform_data {
 	int irq;
 	int irq_base;
+	int en_wakeup;
 };
 
 int tps65910_set_bits(struct tps65910 *tps65910, u8 reg, u8 mask);
-- 
1.7.1.1

Re: [PATCH V1] mfd: tps65910: Add wakeup support

[Mark Brown]

On Fri, Jan 20, 2012 at 04:39:30PM +0530, Laxman Dewangan wrote:
> Adding wakeup support for PMIC device 65910. This can be
> selected through the board specific platform data.

> The wakeup should enabled if PMIC need to be configure for
> waking up system through RTC or ONKEY.

Why the platform data?  The power management infrastructure provides
control of this already.

Re: [PATCH V1] mfd: tps65910: Add wakeup support

[Laxman Dewangan]

On Friday 20 January 2012 06:21 PM, Mark Brown wrote:
>
>> The wakeup should enabled if PMIC need to be configure for
>> waking up system through RTC or ONKEY.
> Why the platform data?  The power management infrastructure provides
> control of this already.
I did not get how the wakeup enabled in power management infrastructure?
My understanding is that we need to call the two apis 
device_wakeup_init() and
enable_irq_wake() for enabling the wakeup functionality.
Is there any other API which does the same and I need to call from the 
core driver?

Re: [PATCH V1] mfd: tps65910: Add wakeup support

[Mark Brown]

On Fri, Jan 20, 2012 at 06:30:24PM +0530, Laxman Dewangan wrote:

> I did not get how the wakeup enabled in power management infrastructure?
> My understanding is that we need to call the two apis
> device_wakeup_init() and
> enable_irq_wake() for enabling the wakeup functionality.
> Is there any other API which does the same and I need to call from
> the core driver?

No, that's it - when you call those userspace will get control via sysfs
for turning on and off the wakeup support.

Re: [PATCH V1] mfd: tps65910: Add wakeup support

[Laxman Dewangan]

On Friday 20 January 2012 06:32 PM, Mark Brown wrote:
> On Fri, Jan 20, 2012 at 06:30:24PM +0530, Laxman Dewangan wrote:
>
>> I did not get how the wakeup enabled in power management infrastructure?
>> My understanding is that we need to call the two apis
>> device_wakeup_init() and
>> enable_irq_wake() for enabling the wakeup functionality.
>> Is there any other API which does the same and I need to call from
>> the core driver?
> No, that's it - when you call those userspace will get control via sysfs
> for turning on and off the wakeup support.
So should I call them in driver by default without taking parameter from 
platform data?

Re: [PATCH V1] mfd: tps65910: Add wakeup support

[Mark Brown]

On Fri, Jan 20, 2012 at 06:37:42PM +0530, Laxman Dewangan wrote:
> On Friday 20 January 2012 06:32 PM, Mark Brown wrote:

> >No, that's it - when you call those userspace will get control via sysfs
> >for turning on and off the wakeup support.

> So should I call them in driver by default without taking parameter
> from platform data?

That's the normal behaviour for drivers unless there's some specific
reason for doing something different.  The choice may well depend on the
application software running on the system rather than the kernel.

Re: [PATCH V1] mfd: tps65910: Add wakeup support

[Laxman Dewangan]

On Friday 20 January 2012 06:43 PM, Mark Brown wrote:
> On Fri, Jan 20, 2012 at 06:37:42PM +0530, Laxman Dewangan wrote:
>
>>> No, that's it - when you call those userspace will get control via sysfs
>>> for turning on and off the wakeup support.
>> So should I call them in driver by default without taking parameter
>> from platform data?
> That's the normal behaviour for drivers unless there's some specific
> reason for doing something different.  The choice may well depend on the
> application software running on the system rather than the kernel.
Ok, going through the details of documentation under 
/sys/devices/.../power/wakeup files of
power/device.txt, i think following should be the change if we want to 
control the wakeup control
through user sapce:
During initialization of device, we need to tell that device is wakeup 
capable and hence we need to
call the: device_wakeup_init() and device_set_wakeup_capable(dev, true).

Then it exposes the required sysfs to userspace to select the wakeup 
enable or not i.e. power/wakeup
to be written as enabled or disabled.

Based on user selection, the function device_may_wakeup() will return 
true/false based on
power/wakeup enabled/disabled.
So before entering into the suspend, we need to check this function and 
call enable_irq_wakeup() to
have the wakeup enabled actually in the soc. In resume we need to call 
disable_irq_wake() again.

If this is correct approach then I can push the another patch.

Re: [PATCH V1] mfd: tps65910: Add wakeup support

[Laxman Dewangan]

Resending as text formatting was not proper. Sorry for inconvenience..

On Friday 20 January 2012 06:43 PM, Mark Brown wrote:
> On Fri, Jan 20, 2012 at 06:37:42PM +0530, Laxman Dewangan wrote:
>>> No, that's it - when you call those userspace will get control via sysfs
>>> for turning on and off the wakeup support.
>> So should I call them in driver by default without taking parameter
>> from platform data?
> That's the normal behaviour for drivers unless there's some specific
> reason for doing something different.  The choice may well depend on the
> application software running on the system rather than the kernel.
Going through the details of documentation under 
/sys/devices/.../power/wakeup files of power/device.txt, I think 
following should be the change if we want to control the wakeup control 
through user sapce:
During initialization of device, we need to tell that device is wakeup 
capable and hence we need to call the: device_wakeup_init() and 
device_set_wakeup_capable(dev, true).
Then it exposes the required sysfs to userspace to select the wakeup 
enable or not i.e. power/wakeup to be written as enabled or disabled.
Based on user selection, the function device_may_wakeup() will return 
true/false based on  power/wakeup enabled/disabled. So before entering 
into the suspend, we need to check this function and call 
enable_irq_wakeup() to have the wakeup enabled actually in the soc. In 
resume we need to call disable_irq_wake() again.

If this is correct approach then I can push the another patch.

Re: [PATCH V1] mfd: tps65910: Add wakeup support

[Mark Brown]

On Sat, Jan 21, 2012 at 04:54:52PM +0530, Laxman Dewangan wrote:

> During initialization of device, we need to tell that device is
> wakeup capable and hence we need to call the: device_wakeup_init()
> and device_set_wakeup_capable(dev, true).
> Then it exposes the required sysfs to userspace to select the wakeup
> enable or not i.e. power/wakeup to be written as enabled or
> disabled.
> Based on user selection, the function device_may_wakeup() will
> return true/false based on  power/wakeup enabled/disabled. So before
> entering into the suspend, we need to check this function and call
> enable_irq_wakeup() to have the wakeup enabled actually in the soc.
> In resume we need to call disable_irq_wake() again.

Yes, that sounds about right.  You don't strictly need to worry about
the wake setup except when suspending but it tends to be easier to
implement that way.

Re: [PATCH V1] mfd: tps65910: Add wakeup support

[Laxman Dewangan]

On Saturday 21 January 2012 06:21 PM, Mark Brown wrote:
> On Sat, Jan 21, 2012 at 04:54:52PM +0530, Laxman Dewangan wrote:
>
>> During initialization of device, we need to tell that device is
>> wakeup capable and hence we need to call the: device_wakeup_init()
>> and device_set_wakeup_capable(dev, true).
>> Then it exposes the required sysfs to userspace to select the wakeup
>> enable or not i.e. power/wakeup to be written as enabled or
>> disabled.
>> Based on user selection, the function device_may_wakeup() will
>> return true/false based on  power/wakeup enabled/disabled. So before
>> entering into the suspend, we need to check this function and call
>> enable_irq_wakeup() to have the wakeup enabled actually in the soc.
>> In resume we need to call disable_irq_wake() again.
> Yes, that sounds about right.  You don't strictly need to worry about
> the wake setup except when suspending but it tends to be easier to
> implement that way.
Thanks, I will send another patch for implementing this way.