Определение источника IRQ прерывания Опции

[Kirill_Good]

Добрый день, помогите с определением источника прерывания в системе. В драйвере есть handler, который регистируется при probe драйвера. Как узнать того кто спровоцировал это прерывание? Схематики платы нет, информации по тому какие пины, какая именно модель микросхемы привязана нет. Можно ли начать плясать от исходников драйвера? Как и куда смотреть дальше чем код драйвера? Может из комментариев в коде можно понять. Где табличка с IRQ. Знания в этой области размазанные, не получается выстроить логическую дорожку. Есть документация на проц.

Спасибо!

[kurtis]

В случае с ARM платформой.
фунция request_irq имеет следующий прототип

request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags, const char *name, void *dev)

где IRQ это источник вашего прерывания, NAME, то что отображается в /proc/interrupts. Например, у меня ?proc/interrupts выдает следующее

62: 20932 MXC_TZIC imx-i2c
63: 1146 MXC_TZIC imx-i2c
64: 0 MXC_TZIC imx-i2c

Т.е. например, imx-i2c это NAME, а прерывание это 62. Если посмотреть документацию на чип imx507, то действительно, номеру 62 соответствует I2C1 Interrupt Request.

Если же нужно прерывание от GPIO, то там все немного более хитро и нужно использовать функцию (макрос) gpio_to_irq(ВАШ_ПИН), там тоже будет присвоен какой-то номер, но это уже сильно зависит от архитектуры чипа.
.

[Kirill_Good]

Т.е. например, imx-i2c это NAME, а прерывание это 62. Если посмотреть документацию на чип imx507, то действительно, номеру 62 соответствует I2C1 Interrupt Request.

Если же нужно прерывание от GPIO, то там все немного более хитро и нужно использовать функцию (макрос) gpio_to_irq(ВАШ_ПИН), там тоже будет присвоен какой-то номер, но это уже сильно зависит от архитектуры чипа.
.

Вы прямо в точку, там как раз фигурирует gpio_to_irq. Есть ощущение, что он подключен к user defined какого-нибудь пину. Просто возникает во время работы системы прерывание, которое обслуживает обработчик, который не должен по идее вызываться. Он должен срабатывать только по подключению внешнего модуля к плате. Но этот обработчик каким то боком вызывается. Кто его вызывает не совсем понятно. Мысль что по линии помеха возникает очень сомнительно, потому что он вызывается не случайно, а в так сказать в детерминированный момент. Кто может в системе ещё вызвать прерывание , чтобы обработчик сработал? Может он делит одно прерывание с другим устройством? Флаг SHARED? Но я читал, что linux разруливает эту ситуацию через один из параметров irq_request, вроде dev.

kurtis, можете как нибудь прокомментировать мысли.