On Thu, Oct 3, 2013 at 7:42 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> This patch adds support for interrupts in a way that
> should be pretty generic, and works for the omaps that
> support wake-up interrupts. On omaps, there's an
> interrupt enable and interrupt status bit for each pin.
So to be clear: is this enable and status bit in the *same*
register as all other settings? Then it warrants having this
under pinctrl-single still and I feel a bit better about this.
Second: how does this relate to the case where say
gpio-omap is using the same pins as a back-end (this
is a real usecase right)?
So gpio-omap already supports gpio_to_irq() and
it does not support enable_irq_wake() on the GPIO
lines as well.
How does this play together? Is it like the pins have a set
of wakeup IRQs and then the GPIO block has *another*
set of wakeup IRQs?
And if you do enable_irq_wake() on the GPIO line,
should this not fall through to the pinctrl driver, so we
should add pinctrl_gpio_enable_wake() and
pinctrl_gpio_disable_wake() just like we have
pinctrl_gpio_direction_input() and friends today,
so that this request falls through to the pinctrl driver
when a wakeup on a certain GPIO line is requested?
Now gpio-omap.c does not seem to use the pinctrl
back-end commands, instead of using e.g.
pinctrl_gpio_request() and GPIO to pin ranges it
seems to use this hack:
static void _enable_gpio_module(struct gpio_bank *bank, unsigned offset)
{
if (bank->regs->pinctrl) {
void __iomem *reg = bank->base + bank->regs->pinctrl;
/* Claim the pin for MPU */
__raw_writel(__raw_readl(reg) | (1 << offset), reg);
}
Can't we please make the OMAP GPIO driver use the
pinctrl back-end with gpio ranges properly *before* we proceed
to doing this kind of stuff? I think it is already looking
like a bit of layered hacks :-(
Haojian is already using the pinctrl-single as backend to
another GPIO controller (I think it's pinctrl-pl061.c) so surely
this should be possible to do right.
IIRC there are also other OMAP GPIO blocks so we need
to look at the large picture here, for all of them.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
