On Tue, Apr 7, 2015 at 7:06 PM, Stefan Wahren <stefan.wahren@xxxxxxxx> wrote: > [add some possible interested developer in CC] > >> Mark Rutland <mark.rutland@xxxxxxx> hat am 7. April 2015 um 13:29 geschrieben: >> >> >> On Sat, Apr 04, 2015 at 10:40:13PM +0100, Stefan Wahren wrote: >> > Hi, >> >> Hi, >> >> > i'm currently working on drivers (regulator and power switch) for a power >> > subsystem of a ARM9 processor (Freescale i.MX28). There are interrupts for >> > the >> > power subsystem which share the same interrupt line. This interrupt line is >> > needed by both drivers (regulator and power switch). >> > >> > Now the question what is the right way (tm) to specify the interrupt in the >> > devicetree and fetch the irq number during driver probe? >> >> If the interrupts are generated by the subsystem as a whole, then A >> would be more correct. If you can read some shared register to determine >> the particular sub-block which generated the interrupt, A would >> certainly be the right way of describing the HW. >> >> If the subsystem is just a logical grouping, and the two units generate >> separate interrupts which simply get muxed together (with nothing >> special done at the subsystem level), then B would seem more correct, as >> the two units are effectively independent. >> >> It really depends on way the HW is organised, and how the HW _could_ be >> organised if reused, so this is a grey area generally. >> >> It looks like it would be possible to support both styles if we need to >> (by checking the node first, then its parent), if we go for one option >> and later discover we need the other. > > thanks for the good explanation. After looking into the reference manual [1] of > the i.MX28 i still can't decide if the subsystem generate the interrupts as a > whole or > as a logical group. I only found this para in chapter 11.11: > > The VDDA_BO_IRQ, VDDD_BO_IRQ, VDDIO_BO_IRQ, and BATT_BO_IRQ each > have their own interrupt line back to the interrupt collector. > However, the remaining five interrupts—VDD5V_GT_VDDIO_IRQ, DC_OK_IRQ, > VBUSVALID_IRQ, LINREG_OK_IRQ and PSWITCH_IRQ—all share a single > interrupt line. In this case, software must read the interrupt status > bits to discover which event caused the interrupt. > > In my case DC_OK_IRQ and PSWITCH_IRQ are relevant. > > Maybe someone else has a idea? Perhaps you can implement an interrupt-controller to handle the multiplexing of the 5 remaining interrupts? Can they be disabled/enabled individually? > Thanks Stefan > > [1] - http://cache.freescale.com/files/dsp/doc/ref_manual/MCIMX28RM.pdf > > Document Number: MCIMX28RM > Rev 2, 08/2013 > >> >> Thanks, >> Mark. >> >> > >> > Option A (define interrupt in parent node): >> > >> > power: power@80044000 { >> > compatible = "fsl,imx28-power", "syscon"; >> > reg = <0x80044000 0x2000>; >> > interrupts = <6>; >> > >> > reg_vddd: regulator@1 { >> > compatible = "fsl,imx28-vddd"; >> > }; >> > >> > pswitch: pswitch@5 { >> > compatible = "fsl,mxs-pswitch"; >> > linux,code = <116>; >> > }; >> > } >> > >> > int irq = irq_of_parse_and_map(parent, 0); >> > >> > Option B (define interrupt for each child node): >> > >> > power: power@80044000 { >> > compatible = "fsl,imx28-power", "syscon"; >> > reg = <0x80044000 0x2000>; >> > >> > reg_vddd: regulator@1 { >> > compatible = "fsl,imx28-vddd"; >> > interrupts = <6>; >> > }; >> > >> > pswitch: pswitch@5 { >> > compatible = "fsl,mxs-pswitch"; >> > linux,code = <116>; >> > interrupts = <6>; >> > }; >> > } >> > >> > int irq = platform_get_irq(pdev, 0); Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
