linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 08/13] gpio/omap: remove redundant decoding of gpio offset
Date: Wed, 07 Mar 2012 13:00:13 +0100	[thread overview]
Message-ID: <4F574DCD.4000507@ti.com> (raw)
In-Reply-To: <1331118963-26364-9-git-send-email-tarun.kanti@ti.com>

On Wednesday 07 March 2012 12:15 PM, Tarun Kanti DebBarma wrote:
> In gpio_get(), _get_gpio_datain() and _get_gpio_dataout() get rid of
> un-necessary operation to compute gpio mask. The gpio offset passed
> to gpio_get() is sufficient to do that.
> 
> Here is Russell's original comment:
> Can someone explain to me this:
> #define GPIO_INDEX(bank, gpio) (gpio % bank->width)
> #define GPIO_BIT(bank, gpio) (1 << GPIO_INDEX(bank, gpio))
> 
> static int _get_gpio_datain(struct gpio_bank *bank, int gpio)
> {
>        void __iomem *reg = bank->base + bank->regs->datain;
> 
>        return (__raw_readl(reg) & GPIO_BIT(bank, gpio)) != 0;
> }
> 
> static int gpio_get(struct gpio_chip *chip, unsigned offset)
> {
>        struct gpio_bank *bank = container_of(chip, struct gpio_bank, chip);
>        void __iomem *reg = bank->base;
>        int gpio = chip->base + offset;
>        u32 mask = GPIO_BIT(bank, gpio);
> 
>        if (gpio_is_input(bank, mask))
>                return _get_gpio_datain(bank, gpio);
>        else
>                return _get_gpio_dataout(bank, gpio);
> }
> 
> Given that bank->width on OMAP is either 32 or 16, and GPIO numbers for
> any GPIO chip are always aligned to 32 or 16, why does this code bother
> adding the chips base gpio number and then modulo the width?
> 
> Surely this means if - for argument sake - you registered a GPIO chip
> with 8 lines followed by one with 16 lines, GPIO0..7 would be chip 0
> bit 0..7, GPIO8..15 would be chip 1 bit 8..15, GPIO16..23 would be
> chip 1 bit 0..7.
> 
> However, if you registered a GPIO chip with 16 lines first, it would
> mean GPIO0..15 would be chip 0 bit 0..15, and GPIO16..31 would be
> chip 1 bit 0..15.
> 
> Surely this kind of behaviour is not intended?
> 
> Is there a reason why the bitmask can't just be (1 << offset) where
> offset is passed into these functions as GPIO number - chip->base ?
> 
> Reported-by: Russell King - ARM Linux <linux@arm.linux.org.uk>
> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Looks good.
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

Regards
Santosh

  reply	other threads:[~2012-03-07 12:00 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-07 11:15 [PATCH v3 00/13] gpio/omap: Some more driver cleanup and fixes Tarun Kanti DebBarma
2012-03-07 11:15 ` [PATCH v3 01/13] gpio/omap: remove saved_fallingdetect, saved_risingdetect fields Tarun Kanti DebBarma
2012-03-07 11:15 ` [PATCH v3 02/13] gpio/omap: fix wakeup_en register update in _set_gpio_wakeup() Tarun Kanti DebBarma
2012-03-07 11:59   ` Santosh Shilimkar
2012-03-07 11:15 ` [PATCH v3 03/13] gpio/omap: remove suspend_wakeup field from struct gpio_bank Tarun Kanti DebBarma
2012-03-07 11:15 ` [PATCH v3 04/13] gpio/omap: remove saved_wakeup " Tarun Kanti DebBarma
2012-03-07 11:15 ` [PATCH v3 05/13] gpio/omap: get rid of retrigger variable in gpio_irq_handler Tarun Kanti DebBarma
2012-03-09  8:46   ` DebBarma, Tarun Kanti
2012-03-12 18:53     ` Kevin Hilman
2012-03-12 18:52   ` Kevin Hilman
2012-03-07 11:15 ` [PATCH v3 06/13] gpio/omap: fix trigger type to unsigned Tarun Kanti DebBarma
2012-03-07 11:15 ` [PATCH v3 07/13] gpio/omap: fix _set_gpio_irqenable implementation Tarun Kanti DebBarma
2012-03-07 11:15 ` [PATCH v3 08/13] gpio/omap: remove redundant decoding of gpio offset Tarun Kanti DebBarma
2012-03-07 12:00   ` Santosh Shilimkar [this message]
2012-03-07 11:15 ` [PATCH v3 09/13] gpio/omap: remove suspend/resume callbacks Tarun Kanti DebBarma
2012-03-07 12:01   ` Santosh Shilimkar
2012-03-07 11:16 ` [PATCH v3 10/13] gpio/omap: fix missing dataout context save in _set_gpio_dataout_reg Tarun Kanti DebBarma
2012-03-07 12:03   ` Santosh Shilimkar
2012-03-08  3:34     ` DebBarma, Tarun Kanti
2012-03-07 11:16 ` [PATCH v3 11/13] gpio/omap: fix dataout register overwrite in _set_gpio_dataout_* Tarun Kanti DebBarma
2012-03-07 12:04   ` Santosh Shilimkar
2012-03-12 21:54   ` Kevin Hilman
2012-03-13  6:03     ` DebBarma, Tarun Kanti
2012-03-13  6:33       ` DebBarma, Tarun Kanti
2012-03-13  6:52         ` DebBarma, Tarun Kanti
2012-03-13 16:27           ` Kevin Hilman
2012-03-14  1:53             ` DebBarma, Tarun Kanti
2012-03-07 11:16 ` [PATCH v3 12/13] gpio/omap: fix incorrect context restore logic in omap_gpio_runtime_resume Tarun Kanti DebBarma
2012-03-07 12:07   ` Santosh Shilimkar
2012-03-08  3:58     ` DebBarma, Tarun Kanti
2012-03-08  7:19       ` Shilimkar, Santosh
2012-03-09  9:25         ` DebBarma, Tarun Kanti
2012-03-07 11:16 ` [PATCH v3 13/13] gpio/omap: fix incorrect update to context.irqenable1 Tarun Kanti DebBarma
2012-03-07 12:09   ` Santosh Shilimkar
2012-03-12 22:09   ` Kevin Hilman
2012-03-13  5:31     ` DebBarma, Tarun Kanti
2012-03-12 18:54 ` [PATCH v3 00/13] gpio/omap: Some more driver cleanup and fixes Kevin Hilman
2012-03-12 19:53   ` DebBarma, Tarun Kanti
2012-03-12 20:08     ` DebBarma, Tarun Kanti
2012-03-12 20:27       ` DebBarma, Tarun Kanti
2012-03-12 22:17         ` Kevin Hilman
2012-03-12 22:28         ` Kevin Hilman
2012-03-13  3:57           ` Grant Likely
2012-03-13  4:35             ` DebBarma, Tarun Kanti

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=4F574DCD.4000507@ti.com \
    --to=santosh.shilimkar@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).