Question about shared interrupts in devicetree

[Geert Uytterhoeven]

On Tue, Apr 7, 2015 at 7:06 PM, Stefan Wahren <stefan.wahren at i2se.com> wrote:
> [add some possible interested developer in CC]
>
>> Mark Rutland <mark.rutland at arm.com> 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 at 80044000 {
>> > compatible = "fsl,imx28-power", "syscon";
>> > reg = <0x80044000 0x2000>;
>> > interrupts = <6>;
>> >
>> > reg_vddd: regulator at 1 {
>> > compatible = "fsl,imx28-vddd";
>> > };
>> >
>> > pswitch: pswitch at 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 at 80044000 {
>> > compatible = "fsl,imx28-power", "syscon";
>> > reg = <0x80044000 0x2000>;
>> >
>> > reg_vddd: regulator at 1 {
>> > compatible = "fsl,imx28-vddd";
>> > interrupts = <6>;
>> > };
>> >
>> > pswitch: pswitch at 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 at linux-m68k.org

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