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

Спасибо!

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

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


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

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

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

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

Я так понимаю, что вам известен номер прерывания и по нему нужно определить какой это пин?

Думаю что это сильно зависит от архитектуры процессора, например для процессоров от freescale, макрос gpio_to_irq() выглядит так

где MXC_GPIO_IRQ_START это


Т.е. грубо говоря, gpio_to_irq(pin) это равно (#ЧИСЛО + pin), и дальше уже нужно смотреть как представляются пины в вашей конкретной архитектуре, например e freescale, регистры gpio разбиваются на банки по 32 gpio. Если нужно обратиться к 5-му пину, 4-ого банка, то значение Pin будет равно ((4-й банк-1)*32 + 5-й пин) = (3 * 32 + 5) = 101. Но, например, для самсунгов, там уже как-то по другому.

По этому, если вам нужно определить pin, то нужно посмотреть в каком виде и как пины представляются для вашей архитектуры.


Вы бы сообщили о какой платформе речь идет? Я не уверен, но мне кажется что флаг SHARED характерен для x86 артитектуры, на arm я с ним не сталкивался, как на других - не знаю.

Платформа ST если не ошибаюсь или SH , на счет флага разделения можно наверно в документе найти. На самом деле волнует вопрос кто может быть еще источником прерывания, кроме пина? Кто может еще заставить выполниться обработчику? А если речь идет gpio to irq, то получается что есть пин у SoC внешний, к нему от девайса тянется дорожка , у последнего это тоже выделенный пин, который занимается только генерацией прерывания. Просто девайс в моем случае это ИК приемник, неужели у него столько выводов ? Или же просто шлется какой то код по линии дата, SoC складывает это в регистр и генерит прерывание по внутренней линии что есть какие то даные, хотя у меня это ошибочное событие возникает один раз. Макрос gpio to irq точно говорит о том что внешний девайс должен иметь выделенный пин прерывания?

Или меня не туда несет?

В тех решениях с которыми я сталкивался, идет какой-то интерфейс передачи данных и паралелько с ним, идет линия прерывания, т.е. ведомое устройство выставляет логический уровень на линии перываний, которая заведена на gpio процессора, а процессор на это дело каким-то образом реагирует.


Теоретически, никто. Линия прерывания она одна и она или срабаывает, или нет. Я конечно допускаю, что где-то могут писаться данные напрямую в регистр, но как-то это слишком сложно выглядит.

спасибо за диалог! появилась пища для размышления)