On Wed, Jan 14, 2015 at 3:32 AM, Yingjoe Chen <yingjoe.chen@xxxxxxxxxxxx> wrote:
> Let's me describe my problem more clearly. On our SoC, if a pin support
> interrupt it will have 2 different numbers for it. For examples, here's
> a partial list for the gpio and EINT number mappings on mt8135:
>
> gpio EINT
> 0 49
> 1 48
> ...........
> 36 97
> 37 19
> ...........
>
> To control interrupt related function, we'll need EINT number to locate
> corresponding register bits. When interrupt occurs, the interrupt
> handler will know which EINT interrupt occurs. In irq_chip functions,
> only .irq_request_resources and .irq_release_resources use gpio number
> to set pinmux to EINT mode and all the others need EINT number.
>
> Because EINT number is used more frequently in interrupt related
> functions, it make sense to use EINT number as hwirq instead of gpio
> number. That means irq_domain will translate EINT number to virq.
> So what mtk_gpio_to_irq actually do is translate gpio number to EINT
> number and use irq domain to translate it to virq.
But the EINT is not a hardware number is it?
That sounds like an abuse of the irqdomain framework.
The purpose of that code is to map hardware IRQs to Linux
IRQs nothing else.
This sounds more like mapping a Linux IRQ (the EINT) to
another Linux IRQ (whatever the irqdomain allocates for
you).
Since the EINTs are already Linux IRQs, these should be used
directly.
I would solve this by just having some cross-reference table
for mapping GPIOs to EINTs without involving the irqdomain
at all.
struct eint_map {
int gpio_offset;
int eint;
};
But also check with the irqdomain people.
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
