Finding the interrupt vector of a given IRQ

[Arun KS]

Hi Anish,

On Sat, Oct 20, 2012 at 9:38 AM, anish kumar <anish198519851985 at gmail.com>wrote:

> On Fri, 2012-10-19 at 10:34 +0530, Arun KS wrote:
> > Hi Anish,
> >
> > On Mon, May 28, 2012 at 9:16 AM, anish singh
> > <anish198519851985 at gmail.com> wrote:
> >         On Mon, May 28, 2012 at 2:57 AM, richard -rw- weinberger
> >         <richard.weinberger at gmail.com> wrote:
> >         > On Sun, May 27, 2012 at 2:02 AM, Mark Farnell
> >         <mark.farnell at gmail.com> wrote:
> >         >> In the kernel, how can I find out the interrupt vector
> >         number of a
> >         >> given IRQ (for example, IRQ7)?
> >         >>
> >         >> Within the kernel module, I would like to manually set the
> >         IRQ using
> >         >> the assembly code:
> >         >>
> >         >> asm("int $<irq vector>");
> >         >>
> >         >> and let the IRQ handler installed by a different module
> >         catch that interrupt.
> >         >>
> >         >> Is this possible?
> >         >
> >         > No really because not all IRQ have an interrupt line to the
> >         CPU.
> >         > Linux can multiplex and emulate them. Think of GPIO drivers
> >         with
> >         > interrupt support.
> >
> >         Can you please describe this in detail?It would really help a
> >         lot of
> >         people like me.Does multiplex mean that all numbers starting
> >         from
> >         0,1,2,3,...... TOTAL-interrupt will have interrupt lines
> >         associated with it
> >         eventhough all interrupt numbers are not linear?
> >
> > GPIOs are grouped as banks. Let’s say 32 gpios are in a bank.
> > There will be only single interrupt line to interrupt controller for a
> > bank.
> >
> >
> > Consider that you have configured gpio1 and gpio16 as interrupts.
> > Even if interrupt happens on gpio 1 or gpio 16, the same interrupt
> > line will be triggered to
> >
> > Interrupt controller.
> >
> >
> > Now the gpio driver has to figure out reading the Interrupt status
> >
> > Register of GPIO to find which interrupt (gpio1 or gpio16) has really
> > fired.
> And this is done by this way:
> Suppose we have a chip(mfd-multi-funcion-driver) driver which is
> connected to processor using a gpio - this gpio line acts as interrupt
> line from the processor
>

Interrupt lines are to the interrupt controllor(IC) and only two interrupts
lines fom IC(irq and fiq in case of ARM) goes to processor.

>
> ++++++++++++              ++++++++++
> + Processor+              + Chip   +---->USB  interrupt handler
> +          +gpio--------->+ MFD    +---->dock interrupt handler
> ++++++++++++              +        +---->UART interrupt handler
>                           ++++++++++---->Factory cable interrupt handler
>
> So the code will be as follows:
>
> handler_function()
> {
>         /* find out which interrupt is triggered */
>         /* it can be usb,dock,uart or factory cable */
>         ret_irq = read_mfd_register();
>         /*
>         * ok we found out the interrupt line, get a corresponding
>         * software linux irq number by calling
>         * irq_domain_add_linear
>         * irq_create_mapping
>         * you would have made this calls in the probe probably
>         */
>         handle_nested_irq(ret_irq);
> }
>
> handle_nested_irq inturn will call all the irq_handlers in the system
> for your UART,usb and dock driver.
>
> mfd_driver()
> {
>         request_irq(gpio_to_irq(gpio), handler_function);
> }
>
> Yes. This is another example of interrupt multipexing...
Here you have two levels of multiplexing. One for the mfd devices functions
and other for gpio.

Thanks,
Arun

> Hope I have not missed anything.
> >
> > So in this case a single interrupt line is multiplex for 32 gpio
> > interrupts.
> >
> >
> > HTH.
> >
> > Thanks,
> > Arun
> >
> >         > Anyway, why to you think you need to trigger the raw IRQ
> >         manually?
> >         > This sounds really odd...
> >         >
> >         >
> >         > --
> >         > Thanks,
> >         > //richard
> >         >
> >         > _______________________________________________
> >         > Kernelnewbies mailing list
> >         > Kernelnewbies at kernelnewbies.org
> >         >
> >         http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
> >         _______________________________________________
> >         Kernelnewbies mailing list
> >         Kernelnewbies at kernelnewbies.org
> >         http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20121020/d7d34f5f/attachment.html