Hi Chao,
On Mon, Nov 25, 2013 at 09:30:46PM -0600, Chao Xu wrote:
> Refresh the patch “gpio: omap: be more aggressive with pm_runtime” by
> Felipe Balbi against v3.12-rc5. Add version checking so that the
> aggressive pm_runtime only applies to omap4 devices. Tested with
> pandaboard rev a2 through sysfs.
> Signed-off-by: Chao Xu <chao.xu@xxxxxxxx>
Here, you need to keep authorship and mention that you refreshed the
patch, it should look something like:
From: Felipe Balbi <balbi@xxxxxx>
try to keep gpio block suspended as much as possible.
Tested with pandaboard and a sysfs exported gpio.
Signed-off-by: Felipe Balbi <balbi at ti.com>
[ chao.xu@xxxxxxxx : refreshed against v3.12-rc5, and added revision
check to enable aggressive pm_runtime on OMAP4-only ]
Signed-off-by: Chao Xu <chao.xu@xxxxxxxx>
> ---
> According to Mr. Felipe Balbi, the original patch was not accepted
> because interrupts would be missed when GPIO was used as IRQ source.
> But in my tests with pandaboard, interrupts were not missed. This is
> because _idle_sysc() sets the idlemode of gpio module to
> smart-idle-wakeup, and according to OMAP4430 TRM, under this idlemode,
> the gpio can generate an asynchronous wakeup request to the PRCM. And
> after GPIO is awake, the wake-up request is reflected into the
> interrupt status registers.
>
> A change I made against the original patch is only using the
> aggressive runtime pm scheme on OMAP4 by adding a flag in pdata,
> because I don’t have HW to test OMAP3 or am33xx devices. According to
> the respective TRMs, their GPIO modules also can generate wake-up
> request if the idlemode is set to smart-idle or smart-idle-wakeup. So
> the patch should work for them, too. But I suspect a potential SW bug
> may cause missed interrupts: the am33xx_gpio_sysc.idlemodes is marked
> as capable of SIDLE_SMART_WKUP in omap_hwmod_33xx.c. But according to
> AM335x TRM, _only_ gpio0 is capable of this mode. This may make GPIO
> stuck in force-idle mode and unable to generate wakeup request. And
> thus interrupt will be missed. Again, I don’t have the HW to verify
> whether this is a bug or not :(
Some of this information would be very nice to have in the commit log.
> drivers/gpio/gpio-omap.c | 103 ++++++++++++++++++++++++++-----
> include/linux/platform_data/gpio-omap.h | 1 +
> 2 files changed, 87 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 89675f8..90661f2 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -76,6 +76,7 @@ struct gpio_bank {
> int context_loss_count;
> int power_mode;
> bool workaround_enabled;
> + bool is_aggressive_pm;
>
> void (*set_dataout)(struct gpio_bank *bank, int gpio, int enable);
> int (*get_context_loss_count)(struct device *dev);
> @@ -473,8 +474,15 @@ static void _disable_gpio_module(struct gpio_bank
> *bank, unsigned offset)
> static int gpio_is_input(struct gpio_bank *bank, int mask)
> {
> void __iomem *reg = bank->base + bank->regs->direction;
> + u32 val;
you see, your email it converting tabs into spaces and loosing all
formatting from the patch. There are lots of tips on how to configure
different emails clients under Documentation/email-clients.txt. You
might also want to use git send-email, which will make patch submission
a lot easier :-)
--
balbi
Attachment:
signature.asc
Description: Digital signature
