[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130924154048.GM2684@atomide.com>
Date: Tue, 24 Sep 2013 08:40:48 -0700
From: Tony Lindgren <tony@...mide.com>
To: Javier Martinez Canillas <javier.martinez@...labora.co.uk>
Cc: Santosh Shilimkar <santosh.shilimkar@...com>,
Kevin Hilman <khilman@...aro.org>,
Linus Walleij <linus.walleij@...aro.org>,
Stephen Warren <swarren@...dotorg.org>,
Lars Poeschel <larsi@....tu-dresden.de>,
Grant Likely <grant.likely@...aro.org>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ian.campbell@...rix.com>,
Kumar Gala <galak@...eaurora.org>,
Pawel Moll <pawel.moll@....com>,
Tomasz Figa <tomasz.figa@...il.com>,
Enric Balletbo i Serra <eballetbo@...il.com>,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
Balaji T K <balajitk@...com>,
Jon Hunter <jgchunter@...il.com>, linux-gpio@...r.kernel.org,
linux-omap@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, r.sricharan@...com,
holler@...oftware.de
Subject: Re: [RFC v2] gpio/omap: auto-setup a GPIO when used as an IRQ
* Javier Martinez Canillas <javier.martinez@...labora.co.uk> [130924 01:06]:
> The OMAP GPIO controller HW requires a pin to be configured in GPIO
> input mode in order to operate as an interrupt input. Since drivers
> should not be aware of whether an interrupt pin is also a GPIO or not,
> the HW should be fully configured/enabled as an IRQ if a driver solely
> uses IRQ APIs such as request_irq(), and never calls any GPIO-related
> APIs. As such, add the missing HW setup to the OMAP GPIO controller's
> irq_chip driver.
>
> Since this bypasses the GPIO subsystem we have to ensure that another
> caller won't be able to request the same GPIO pin that is used as an
> IRQ and set its direction as output. Requesting the GPIO and setting
> its direction as input is allowed though.
Also please mention the regression that this fixes. So far we know
that smsc911x for tobi and igep boards in mainline, and also the
MMC card detect for omap4 boards.
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -63,6 +63,7 @@ struct gpio_bank {
> struct gpio_chip chip;
> struct clk *dbck;
> u32 mod_usage;
> + u32 irq_usage;
> u32 dbck_enable_mask;
> bool dbck_enabled;
> struct device *dev;
> @@ -86,6 +87,9 @@ struct gpio_bank {
> #define GPIO_BIT(bank, gpio) (1 << GPIO_INDEX(bank, gpio))
> #define GPIO_MOD_CTRL_BIT BIT(0)
>
> +#define BANK_USED(bank) (bank->mod_usage || bank->irq_usage)
> +#define LINE_USED(line, offset) (line & (1 << offset))
Hmm this patch is hard to read, maybe break it into two patches?
First you could do a patch to prepare thing by introducing
BANK_USED and LINE_USED.
> +static int gpio_is_input(struct gpio_bank *bank, int mask)
> +{
> + void __iomem *reg = bank->base + bank->regs->direction;
> +
> + return __raw_readl(reg) & mask;
> +}
And also move gpio_is_input() around in the first patch.
Then the second patch for the fix would probably be much
easier to read.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists