Hi Mark,
[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?
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@xxxxxxxxxxxxxxx
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
