* Alemao | 2009-09-04 16:29:15 [-0300]: >On Fri, Sep 4, 2009 at 4:28 PM, Alemao<xcarand...@gmail.com> wrote: >> I've read some posts in the list, and about: >> >> irq_of_parse_and_map() >> irq_create_map() >> >> But Im still trying to understand MPC85xx TSEC1 dts. >> >> Gianfar driver is using request_irq(), and request_irq() uses virtual >> irq, right? Yes. request_irq() expects a linux-irq-number. irq_of_parse_and_map() provides such a number.
>> >> Thats why in dts all irqs for TSEC1 are "offseted" of 16? >> >> Manual ?| ?DTS >> ---------------------- >> 13 ? ? ? ? 29 >> 14 ? ? ? ? 30 >> 18 ? ? ? ? 34 >> > >This makes no sense. > >CPM2-PIC, in MPC8555ERM, its on 30. In DTS is on 46. Offset of 16. >But my platform code use irq_of_parse_and_map()! > >So why this offset?!?! irq_of_parse_and_map() creates a mapping between the hardware irq number as specified in the device tree and the linux number (virq) which is used within the linux api in request_irq() for instance. irq_of_parse_and_map() is essential to create a mapping between those two. The interrupt controller on the MPC8555 (mpic) specifies the first few interrupt numbers as external sources followed by internal sources. Now, during the init sequenze of the mpic every interrupt source (internal and external) becomes its uniqe vector number which identifies the source by a number. This number is the hardware interrupt number i.e. that thing in the device tree. The init sequence is a for loop which starts at 0 for the first interrupt source which happens to be external interrupt 0, 1 for external interrupt 1 and so on. At the time it reaches the first internal interrupt source the vector number is 16. That's why you always have an offset of 16 between every internal interupt source number in the MPC855ERM document and those weired numbers in the device tree :) >Alemao Sebastian _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev