1

As a newbie on this topic, I am trying to change the dts of an optical port to IRQ_TYPE_EDGE_BOTH to catch the event when a port is plugged (EDGE_RISING) or removed (EDGE_FALLING). however, the kernel complains when set irq mode to IRQ_TYPE_EDGE_BOTH, which is (IRQ_TYPE_EDGE_RISING|IRQ_TYPE_EDGE_FALLING):

genirq: Setting trigger mode 3 for irq 47 failed (gic_set_type+0x0/0x98)

After a short look at the irq-gic.c file, it says:

  /* SPIs have restrictions on the supported types */
  if (gicirq >= 32 && type != IRQ_TYPE_LEVEL_HIGH &&
          type != IRQ_TYPE_EDGE_RISING)
    return -EINVAL;

Is there anyway to set the interrupt to IRQ_TYPE_EDGE_BOTH? our arm is armv7ahf neon 32-bits.

pepero
  • 7,095
  • 7
  • 41
  • 72
  • You might be able to work around it with state - after a plug id is added or removed, swap which event you are looking for. Not great, but should be functional, especially if you have another port that tells you if something is connected. – Michael Dorgan Sep 14 '20 at 23:00
  • @MichaelDorgan, do you mean i use a state variable to cache and compare if the event changes the state? The problem is that it only allows level high or edge rising, which can work for the port plug event but not for port remove event. am i right? – pepero Sep 14 '20 at 23:13
  • Once it is plugged in, swap the interrupt for edge falling. If anything goes wrong, it can get out of sync (say plugged in already on power up), hence the ask if there is a secondary way to see if something is plugged in or not. – Michael Dorgan Sep 14 '20 at 23:16
  • @MichaelDorgan, sorry but how to swap the interrupt for edge falling at run time? could you please elaborate more? (is the trigger mode from dts changeable? also is the edge falling allowed?) – pepero Sep 14 '20 at 23:25
  • That I don't know - I'm just looking at this from a high level engineering POV. I assumed that you had a way of runtime modifying the interrupt vector or the mask which the system is viewing. Something as simple as `*myIRQPort ^= IRQ_TYPE_EDGE_BOTH;` (assuming that the port has already been set to either rising or falling earlier...) If that is not possible, then I would wait for a deeper expert :) – Michael Dorgan Sep 14 '20 at 23:30
  • Will also add if it helps: https://developer.arm.com/documentation/ihi0048/b/Interrupt-Handling-and-Prioritization – Michael Dorgan Sep 14 '20 at 23:38
  • What chip is this (note: arm does not make chips)? Does it support both directions, perhaps this is a hardware limitation for this chip. – old_timer Sep 15 '20 at 00:58

0 Answers0