| Message ID | 1327057770-6688-1-git-send-email-ldewangan@nvidia.com |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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? -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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? -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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);
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@nvidia.com> --- 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(-)