* Question about shared interrupts in devicetree
@ 2015-04-04 21:40 ` Stefan Wahren
0 siblings, 0 replies; 16+ messages in thread
From: Stefan Wahren @ 2015-04-04 21:40 UTC (permalink / raw)
To: kernelnewbies
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
^ permalink raw reply [flat|nested] 16+ messages in thread* Question about shared interrupts in devicetree @ 2015-04-04 21:40 ` Stefan Wahren 0 siblings, 0 replies; 16+ messages in thread From: Stefan Wahren @ 2015-04-04 21:40 UTC (permalink / raw) To: kernelnewbies, devicetree 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Question about shared interrupts in devicetree @ 2015-04-07 11:29 ` Mark Rutland 0 siblings, 0 replies; 16+ messages in thread From: Mark Rutland @ 2015-04-07 11:29 UTC (permalink / raw) To: kernelnewbies 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 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about shared interrupts in devicetree @ 2015-04-07 11:29 ` Mark Rutland 0 siblings, 0 replies; 16+ messages in thread From: Mark Rutland @ 2015-04-07 11:29 UTC (permalink / raw) To: Stefan Wahren; +Cc: kernelnewbies, devicetree 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Question about shared interrupts in devicetree 2015-04-07 11:29 ` Mark Rutland @ 2015-04-07 17:06 ` Stefan Wahren -1 siblings, 0 replies; 16+ messages in thread From: Stefan Wahren @ 2015-04-07 17:06 UTC (permalink / raw) To: kernelnewbies 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 > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about shared interrupts in devicetree @ 2015-04-07 17:06 ` Stefan Wahren 0 siblings, 0 replies; 16+ messages in thread From: Stefan Wahren @ 2015-04-07 17:06 UTC (permalink / raw) To: Mark Rutland Cc: fabio.estevam, devicetree, marex, kernelnewbies, kernel, maxime.ripard, shawn.guo 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Question about shared interrupts in devicetree @ 2015-04-08 19:20 ` Geert Uytterhoeven 0 siblings, 0 replies; 16+ messages in thread From: Geert Uytterhoeven @ 2015-04-08 19:20 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about shared interrupts in devicetree @ 2015-04-08 19:20 ` Geert Uytterhoeven 0 siblings, 0 replies; 16+ messages in thread From: Geert Uytterhoeven @ 2015-04-08 19:20 UTC (permalink / raw) To: Stefan Wahren Cc: Mark Rutland, kernelnewbies, devicetree, Sascha Hauer, Fabio Estevam, Marek Vašut, Maxime Ripard, Shawn Guo 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Question about shared interrupts in devicetree @ 2015-04-09 7:24 ` Stefan Wahren 0 siblings, 0 replies; 16+ messages in thread From: Stefan Wahren @ 2015-04-09 7:24 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about shared interrupts in devicetree @ 2015-04-09 7:24 ` Stefan Wahren 0 siblings, 0 replies; 16+ messages in thread From: Stefan Wahren @ 2015-04-09 7:24 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Mark Rutland, kernelnewbies, devicetree, Sascha Hauer, Fabio Estevam, Marek Vašut, Maxime Ripard, Shawn Guo 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Question about shared interrupts in devicetree @ 2015-04-09 7:37 ` Geert Uytterhoeven 0 siblings, 0 replies; 16+ messages in thread From: Geert Uytterhoeven @ 2015-04-09 7:37 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about shared interrupts in devicetree @ 2015-04-09 7:37 ` Geert Uytterhoeven 0 siblings, 0 replies; 16+ messages in thread From: Geert Uytterhoeven @ 2015-04-09 7:37 UTC (permalink / raw) To: Stefan Wahren Cc: Mark Rutland, kernelnewbies, devicetree, Sascha Hauer, Fabio Estevam, Marek Vašut, Maxime Ripard, Shawn Guo 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Question about shared interrupts in devicetree @ 2015-04-09 17:02 ` Stefan Wahren 0 siblings, 0 replies; 16+ messages in thread From: Stefan Wahren @ 2015-04-09 17:02 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about shared interrupts in devicetree @ 2015-04-09 17:02 ` Stefan Wahren 0 siblings, 0 replies; 16+ messages in thread From: Stefan Wahren @ 2015-04-09 17:02 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Sascha Hauer, Shawn Guo, kernelnewbies, Maxime Ripard, Mark Rutland, Fabio Estevam, devicetree, "Marek Vašut" 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Question about shared interrupts in devicetree 2015-04-07 11:29 ` Mark Rutland @ 2015-04-22 18:18 ` Stefan Wahren -1 siblings, 0 replies; 16+ messages in thread From: Stefan Wahren @ 2015-04-22 18:18 UTC (permalink / raw) To: kernelnewbies > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Question about shared interrupts in devicetree @ 2015-04-22 18:18 ` Stefan Wahren 0 siblings, 0 replies; 16+ messages in thread From: Stefan Wahren @ 2015-04-22 18:18 UTC (permalink / raw) To: Mark Rutland; +Cc: kernelnewbies, devicetree > 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2015-04-22 18:18 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-04-04 21:40 Question about shared interrupts in devicetree Stefan Wahren 2015-04-04 21:40 ` Stefan Wahren 2015-04-07 11:29 ` Mark Rutland 2015-04-07 11:29 ` Mark Rutland 2015-04-07 17:06 ` Stefan Wahren 2015-04-07 17:06 ` Stefan Wahren 2015-04-08 19:20 ` Geert Uytterhoeven 2015-04-08 19:20 ` Geert Uytterhoeven 2015-04-09 7:24 ` Stefan Wahren 2015-04-09 7:24 ` Stefan Wahren 2015-04-09 7:37 ` Geert Uytterhoeven 2015-04-09 7:37 ` Geert Uytterhoeven 2015-04-09 17:02 ` Stefan Wahren 2015-04-09 17:02 ` Stefan Wahren 2015-04-22 18:18 ` Stefan Wahren 2015-04-22 18:18 ` Stefan Wahren
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.