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@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
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@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
participants (2)
-
Geert Uytterhoeven -
Stefan Wahren