From: "DebBarma, Tarun Kanti" <tarun.kanti@ti.com>
To: Kevin Hilman <khilman@ti.com>
Cc: linux-omap@vger.kernel.org, grant.likely@secretlab.ca,
tony@atomide.com, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 3/6] gpio/omap: remove suspend_wakeup field from struct gpio_bank
Date: Tue, 28 Feb 2012 16:45:21 +0530 [thread overview]
Message-ID: <CAC83Zv+fiObi8n4OEBeeuP-iPVasipe0N9yNSn-yZXtv5FMgaQ@mail.gmail.com> (raw)
In-Reply-To: <CAC83ZvJ97uRSLU-JmO2mnaOuziU=SotghASSJjPvESWL+eATuQ@mail.gmail.com>
On Tue, Feb 28, 2012 at 3:09 PM, DebBarma, Tarun Kanti
<tarun.kanti@ti.com> wrote:
> On Tue, Feb 28, 2012 at 5:24 AM, Kevin Hilman <khilman@ti.com> wrote:
>> Tarun Kanti DebBarma <tarun.kanti@ti.com> writes:
>>
>>> Since we already have bank->context.wake_en to keep track
>>> of gpios which are wakeup enabled, there is no need to have
>>> this field any more.
>>>
>>> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
>>
>> I'm not crazy about this change...
>>
>>> ---
>>> drivers/gpio/gpio-omap.c | 11 +++++------
>>> 1 files changed, 5 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>>> index 64f15d5..b62e861 100644
>>> --- a/drivers/gpio/gpio-omap.c
>>> +++ b/drivers/gpio/gpio-omap.c
>>> @@ -53,7 +53,6 @@ struct gpio_bank {
>>> void __iomem *base;
>>> u16 irq;
>>> u16 virtual_irq_start;
>>> - u32 suspend_wakeup;
>>> u32 non_wakeup_gpios;
>>> u32 enabled_non_wakeup_gpios;
>>> struct gpio_regs context;
>>> @@ -497,9 +496,9 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int gpio, int enable)
>>>
>>> spin_lock_irqsave(&bank->lock, flags);
>>> if (enable)
>>> - bank->suspend_wakeup |= gpio_bit;
>>> + bank->context.wake_en |= gpio_bit;
>>> else
>>> - bank->suspend_wakeup &= ~gpio_bit;
>>> + bank->context.wake_en &= ~gpio_bit;
>>
>> The bank->context values are expected to be copies of the actual
>> register contents, and here that is clearly not the case.
> Right, it should have been this:
>
> if (enable)
> - bank->suspend_wakeup |= gpio_bit;
> + bank->context.wake_en |= gpio_bit;
> else
> - bank->suspend_wakeup &= ~gpio_bit;
> + bank->context.wake_en &= ~gpio_bit;
> +
> + __raw_writel(bank->context.wake_en, bank->base + bank->regs->wkup_en);
>
>>
>> With this change, you're using the context register to track changes
>> that you *might* eventually write to the register.
> The above change ensures that bank->context.wake_en reflects the
> latest register value.
> There are two distinct paths through which bank->context.wake_en is
> updated now, viz:
> Path1:-
> chip.irq_set_type() --> gpio_irq_type() --> _set_gpio_triggering() -->
> set_gpio_trigger()
>
> Path2:-
> chip.irq_set_wake() --> gpio_wake_enable() --> irq_set_wake()
Sorry, it should have been:
chip.irq_set_wake() --> gpio_wake_enable() --> _set_gpio_wakeup()
>
>>
>> IMO, this is more confusing than having a separate field to track this.
> So, there is no need have a separate field to keep track of this.
> I hope my understanding is right.
> --
> Tarun
>
>>
>> Kevin
>>
>>> spin_unlock_irqrestore(&bank->lock, flags);
>>>
>>> @@ -772,7 +771,7 @@ static int omap_mpuio_suspend_noirq(struct device *dev)
>>>
>>> spin_lock_irqsave(&bank->lock, flags);
>>> bank->context.wake_en = __raw_readl(mask_reg);
>>> - __raw_writel(0xffff & ~bank->suspend_wakeup, mask_reg);
>>> + __raw_writel(0xffff & ~bank->context.wake_en, mask_reg);
>>> spin_unlock_irqrestore(&bank->lock, flags);
>>>
>>> return 0;
>>> @@ -1137,12 +1136,12 @@ static int omap_gpio_suspend(struct device *dev)
>>> if (!bank->mod_usage || !bank->loses_context)
>>> return 0;
>>>
>>> - if (!bank->regs->wkup_en || !bank->suspend_wakeup)
>>> + if (!bank->regs->wkup_en || !bank->context.wake_en)
>>> return 0;
>>>
>>> spin_lock_irqsave(&bank->lock, flags);
>>> _gpio_rmw(base, bank->regs->wkup_en, 0xffffffff, 0);
>>> - _gpio_rmw(base, bank->regs->wkup_en, bank->suspend_wakeup, 1);
>>> + _gpio_rmw(base, bank->regs->wkup_en, bank->context.wake_en, 1);
>>> spin_unlock_irqrestore(&bank->lock, flags);
>>>
>>> return 0;
next prev parent reply other threads:[~2012-02-28 11:15 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-23 12:10 [PATCH 0/6] gpio/omap: Some more driver cleanup and fixes Tarun Kanti DebBarma
2012-02-23 12:10 ` [PATCH 1/6] gpio/omap: remove saved_fallingdetect, saved_risingdetect fields Tarun Kanti DebBarma
2012-02-23 12:28 ` Felipe Balbi
2012-02-23 12:10 ` [PATCH 2/6] gpio/omap: remove saved_wakeup field from struct gpio_bank Tarun Kanti DebBarma
2012-02-23 12:28 ` Felipe Balbi
2012-02-27 23:50 ` Kevin Hilman
2012-02-28 5:08 ` DebBarma, Tarun Kanti
2012-02-23 12:10 ` [PATCH 3/6] gpio/omap: remove suspend_wakeup " Tarun Kanti DebBarma
2012-02-23 12:29 ` Felipe Balbi
2012-02-27 23:54 ` Kevin Hilman
2012-02-28 9:39 ` DebBarma, Tarun Kanti
2012-02-28 11:15 ` DebBarma, Tarun Kanti [this message]
2012-02-28 18:45 ` Kevin Hilman
2012-02-29 4:18 ` DebBarma, Tarun Kanti
2012-02-23 12:10 ` [PATCH 4/6] gpio/omap: get rid of retrigger variable in gpio_irq_handler Tarun Kanti DebBarma
2012-02-23 12:30 ` Felipe Balbi
2012-02-28 0:02 ` Kevin Hilman
2012-02-28 5:11 ` DebBarma, Tarun Kanti
2012-02-23 12:10 ` [PATCH 5/6] gpio/omap: fix trigger type to unsigned Tarun Kanti DebBarma
2012-02-23 12:30 ` Felipe Balbi
2012-02-23 12:39 ` Shubhrajyoti
2012-02-23 12:46 ` Russell King - ARM Linux
2012-02-23 12:10 ` [PATCH 6/6] gpio/omap: fix _set_gpio_irqenable implementation Tarun Kanti DebBarma
2012-02-23 12:31 ` Felipe Balbi
2012-02-28 0:11 ` Kevin Hilman
2012-02-23 12:26 ` [PATCH 0/6] gpio/omap: Some more driver cleanup and fixes Shilimkar, Santosh
2012-03-12 17:34 ` Grant Likely
2012-03-12 18:42 ` Kevin Hilman
2012-03-12 18:43 ` Grant Likely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAC83Zv+fiObi8n4OEBeeuP-iPVasipe0N9yNSn-yZXtv5FMgaQ@mail.gmail.com \
--to=tarun.kanti@ti.com \
--cc=grant.likely@secretlab.ca \
--cc=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).