Question about shared interrupts in devicetree

Question about shared interrupts in devicetree

[Stefan Wahren]

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?

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);

Best regards
Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Question about shared interrupts in devicetree

[Stefan Wahren]

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?

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);

Best regards
Stefan

Re: Question about shared interrupts in devicetree

[Mark Rutland]

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,
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);
> 
> Best regards
> Stefan
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Question about shared interrupts in devicetree

[Mark Rutland]

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,
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);
> 
> Best regards
> Stefan
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Question about shared interrupts in devicetree

[Stefan Wahren]

Hi Mark,

[add some possible interested developer in CC]

> Mark Rutland <mark.rutland@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?

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);
> >
> > Best regards
> > Stefan
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

Question about shared interrupts in devicetree

[Stefan Wahren]

Hi Mark,

[add some possible interested developer in CC]

> Mark Rutland <mark.rutland@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?

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);
> >
> > Best regards
> > Stefan
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >

Re: Question about shared interrupts in devicetree

[Geert Uytterhoeven]

On Tue, Apr 7, 2015 at 7:06 PM, Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org> wrote:
> [add some possible interested developer in CC]
>
>> Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> 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@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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Question about shared interrupts in devicetree

[Geert Uytterhoeven]

On Tue, Apr 7, 2015 at 7:06 PM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> [add some possible interested developer in CC]
>
>> Mark Rutland <mark.rutland@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

Re: Question about shared interrupts in devicetree

[Stefan Wahren]

Hi Geert,

Am 08.04.2015 um 21:20 schrieb Geert Uytterhoeven:
> On Tue, Apr 7, 2015 at 7:06 PM, Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org> wrote:
>> [...]
>>
>> 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?

Could you please explain the benefit / reason of this approach?

>
> Can they be disabled/enabled individually?

Yes. What are the consequences?

Thanks Stefan

>
>> Thanks Stefan
>>
>> [1] - http://cache.freescale.com/files/dsp/doc/ref_manual/MCIMX28RM.pdf
>>
>> Document Number: MCIMX28RM
>> Rev 2, 08/2013
>>
>>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Question about shared interrupts in devicetree

[Stefan Wahren]

Hi Geert,

Am 08.04.2015 um 21:20 schrieb Geert Uytterhoeven:
> On Tue, Apr 7, 2015 at 7:06 PM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>> [...]
>>
>> 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?

Could you please explain the benefit / reason of this approach?

>
> Can they be disabled/enabled individually?

Yes. What are the consequences?

Thanks Stefan

>
>> Thanks Stefan
>>
>> [1] - http://cache.freescale.com/files/dsp/doc/ref_manual/MCIMX28RM.pdf
>>
>> Document Number: MCIMX28RM
>> Rev 2, 08/2013
>>
>>
> 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

Re: Question about shared interrupts in devicetree

[Geert Uytterhoeven]

Hi Stefan,

On Thu, Apr 9, 2015 at 9:24 AM, Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org> wrote:
> Am 08.04.2015 um 21:20 schrieb Geert Uytterhoeven:
>> On Tue, Apr 7, 2015 at 7:06 PM, Stefan Wahren <stefan.wahren-TePAdz2rOow@public.gmane.orgm> wrote:
>>> [...]
>>>
>>> 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?
>
> Could you please explain the benefit / reason of this approach?

Since you have different logical modules in the subsystem, this allows to model
the subsystem as separate modules and a separate interrupt controller, and
have separate drivers for all modules.

Look at da9063 for an example (there are more according to "git grep irq_chip
-- drivers/mfd", but not all of them may have DT bindings).

>> Can they be disabled/enabled individually?
>
> Yes. What are the consequences?

If they cannot be disabled/enabled individually, it's more difficult to handle
by implementing an interrupt-controller.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Question about shared interrupts in devicetree

[Geert Uytterhoeven]

Hi Stefan,

On Thu, Apr 9, 2015 at 9:24 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> Am 08.04.2015 um 21:20 schrieb Geert Uytterhoeven:
>> On Tue, Apr 7, 2015 at 7:06 PM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>>> [...]
>>>
>>> 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?
>
> Could you please explain the benefit / reason of this approach?

Since you have different logical modules in the subsystem, this allows to model
the subsystem as separate modules and a separate interrupt controller, and
have separate drivers for all modules.

Look at da9063 for an example (there are more according to "git grep irq_chip
-- drivers/mfd", but not all of them may have DT bindings).

>> Can they be disabled/enabled individually?
>
> Yes. What are the consequences?

If they cannot be disabled/enabled individually, it's more difficult to handle
by implementing an interrupt-controller.

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

Re: Question about shared interrupts in devicetree

[Stefan Wahren]

Hi Geert,

> Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org> hat am 9. April 2015 um 09:37
> geschrieben:
>
> [...]
> 
> >
> > Could you please explain the benefit / reason of this approach?
>
> Since you have different logical modules in the subsystem, this allows to
> model
> the subsystem as separate modules and a separate interrupt controller, and
> have separate drivers for all modules.
>
> Look at da9063 for an example (there are more according to "git grep irq_chip
> -- drivers/mfd", but not all of them may have DT bindings).
>

thanks for the hint, but this makes my patch series not really smaller. I
invested a lot of time (started in September 2014) and i want to submit at least
1 of the 3 drivers soon as possible.

I think the best approch would be to submit my series with option B as a
proposal. In the discussion about the patch it would be easier to decide if a
interrupt controller is really necessary.

> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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

Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Question about shared interrupts in devicetree

[Stefan Wahren]

Hi Geert,

> Geert Uytterhoeven <geert@linux-m68k.org> hat am 9. April 2015 um 09:37
> geschrieben:
>
> [...]
> 
> >
> > Could you please explain the benefit / reason of this approach?
>
> Since you have different logical modules in the subsystem, this allows to
> model
> the subsystem as separate modules and a separate interrupt controller, and
> have separate drivers for all modules.
>
> Look at da9063 for an example (there are more according to "git grep irq_chip
> -- drivers/mfd", but not all of them may have DT bindings).
>

thanks for the hint, but this makes my patch series not really smaller. I
invested a lot of time (started in September 2014) and i want to submit at least
1 of the 3 drivers soon as possible.

I think the best approch would be to submit my series with option B as a
proposal. In the discussion about the patch it would be easier to decide if a
interrupt controller is really necessary.

> 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

Stefan

Re: Question about shared interrupts in devicetree

[Stefan Wahren]

> Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> 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.

Just for the records. I asked this question in the Freescale Community and
a Freescale employee reported that the interrupts are generated by the
subsystem as a whole and there is no logical grouping.

Thanks

Stefan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Question about shared interrupts in devicetree

[Stefan Wahren]

> Mark Rutland <mark.rutland@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.

Just for the records. I asked this question in the Freescale Community and
a Freescale employee reported that the interrupts are generated by the
subsystem as a whole and there is no logical grouping.

Thanks

Stefan