On Thu, 2015-01-15 at 18:30 +0100, Linus Walleij wrote:
> 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?
It is a hardware number. eg, to mask irq for the gpio 0 above, we have
to set bit49 in EINT mask_set register. When this irq triggered, it is
reported using EINT status register bit49.
We can find out EINT number for a GPIO using mtk_desc_pin tables. In
drivers/pinctrl/mediatek/pinctrl-mtk-mt8135.h, for GPIO0, we can see its
EINT is 49 and must set to function 2 for EINT. I believe this is
similar to sunxi.
MTK_PIN(
PINCTRL_PIN(0, "MSDC0_DAT7"),
"D21", "mt8135",
MTK_EINT_FUNCTION(2, 49),
MTK_FUNCTION(0, "GPIO0"),
MTK_FUNCTION(1, "MSDC0_DAT7"),
MTK_FUNCTION(2, "EINT49"),
MTK_FUNCTION(3, "I2SOUT_DAT"),
MTK_FUNCTION(4, "DAC_DAT_OUT"),
MTK_FUNCTION(5, "PCM1_DO"),
MTK_FUNCTION(6, "SPI1_MO"),
MTK_FUNCTION(7, "NALE")
),
Joe.C
--
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
