Как узнать irq клавиатуры

Как узнать irq клавиатуры

Михаил Тычков aka Hard

Доброго времени суток.

Давайте рассмотрим такую вот ситуевину: процессор обрабатывает какие-то данные, не важно какие. В этот момент у какого-нить устройства тоже появились данные для обработки. Че делать? Надо просить процессор, что бы тот соизволил обратить на просьбу внимание и решил бы, сейчас обрабатывать эти данные или потом. Так вот эта просьба и есть IRQ или прерывания (вообще-то существуют два типа прерываний: аппаратные (внешние) и программные (внутренние), но поскольку мой раздел называется «Железо и сети», то разговор я буду вести только об аппаратных прерываниях). Строго говоря IRQ – это каналы запросов прерывания, которые используются всевозможными девайсами для того, что бы сообщить процессору о том, что необходимо обработать определенный запрос. Физически, IRQ представляют собой отдельно проложенные линии (проводники) и соответствующие этим линиям контакты в интерфейсах. Все это находится, ессесно на материнской плате. Линии IRQ предназначены только для передачи запросов прерывания.

А ну-ка разберемся, как вся эта фигня с IRQ происходит. Итак, после получения запроса прерывания, камень сохраняет в стеке содержимое регистров. Затем он обращается к таблице векторов прерываний, где есть список адресов памяти программ, соответствующих определенным номерам прерываний. От номера прерывания зависит, какая программа будет запущена. В основном этими программами являются драйвера, относящиеся к устройствам, пославшим запрос (а уж драйвера туго знают свое дело и разберутся, что дальше делать). После всего этого, процедура обработки возвращает из стека то, с чем работал камень, а проще говоря, отдается управление системой той программе, что работала до запроса прерывания. И так постоянно. Сама таблица находится в оперативной памяти и состоит из 256 элементов по 4 байта и начинается с адреса 0000:0000. Занимает она 1024 Кбайт. Надеюсь, что Вы усвоили простую истину: если необходимо обработать хотя бы один новый байт от какого-либо устройства, необходимо сначала обработать IRQ этого устройства.

Что бы не было путаницы у IRQ есть иерархия или говоря другим языком – приоритеты. Чем меньше номер прерывания, тем выше приоритет и наоборот, чем больше номер прерывания, тем ниже приоритет. IRQ всего 16. Самый высокий приоритет у IRQ 0, а самый низкий у IRQ 15. Приведу таблицу иерархии:

Программируемый контроллер прерываний

Последовательный порт COM 2

Последовательный порт COM 1

Звуковая или сетевая карты или свободен

Стандартный контроллер гибких дисков

Параллельный порт LPT

Звуковая или сетевая карты или свободен

USB или SCSI или свободен

PS/2 совместимый порт мыши

Основной контроллер IDE

Дополнительный контроллер IDE

А хотите посмотреть свои прерывания? Выберите «Пуск – Выполнить», наберите «msinfo32». В появившимся окне «Сведения о системе», слева, выберите вкладку «Ресурсы аппаратуры – Прерывания IRQ».

Двигаемся дальше. Вообще, следует отметить, что каналы запросов прерывания относятся к системным ресурсам. Дам короткое но очень меткое определение: системными ресурсами называются коммуникационные каналы, адреса и сигналы, используемые узлами компьютера для обмена данными с помощью шин. Вот так вот просто и понятно. К системным ресурсам кроме IRQ относятся: адреса памяти, каналы прямого доступа к памяти и адреса портов ввода/вывода. Но об этом в других статьях. А на сегодня все. Удачи в Ваших начинаниях.

Источник

2 Клавиатура

Программа может использовать клавиатуру по-разному. Она может задерживать свое выполнение до тех пор, пока пользователь не введет какое-нибудь число или пока не нажмет какую-нибудь клавишу. Выполняя некоторую работу, программа может периодически проверять, была ли нажата клавиша, изменяющая режим работы программы. Резидентные программы могут активизироваться, когда пользователь нажимает заранее определенную комбинацию. Можно использовать прерывание, вырабатываемое клавиатурой, например, для завершения работы программы.

Что же касается методики работы с клавиатурой в операционных системах Microsoft Windows, то она была описана в 11 томе «Библиотеки системного программиста», который называется «Операционная система Microsoft Windows для программиста».

Как работает клавиатура

Клавиатура выполнена, как правило, в виде отдельного устройства, подключаемого к компьютеру тонким кабелем. Малогабаритные блокнотные компьютеры содержат встроенную клавиатуру.

Что же находится внутри клавиатуры?

Оказывается, там есть компьютер! Только этот компьютер состоит из одной микросхемы и выполняет специализированные функции. Когда вы нажимаете на клавиши, он посылает номер нажатой клавиши в центральный компьютер.

Клавиатурная матрица

Если рассмотреть сильно упрощенную принципиальную схему клавиатуры, представленную на рисунке, можно заметить, что все клавиши находятся в узлах матрицы (рис. 2.1).

Рис.2.1. Упрощенная схема клавиатуры

Устанавливая по очереди на каждой из вертикальных линий уровень напряжения, соответствующий логическому нулю, клавиатурный компьютер опрашивает состояние горизонтальных линий. Если ни одна клавиша не нажата, уровень напряжения на всех горизонтальных линиях соответствует логической единице (так как все эти линии подключены к источнику питания +5 В через резисторы).

Если вы нажмете на какую-либо клавишу, то соответствующая вертикальная и горизонтальная линии окажутся замкнутыми. Когда на этой вертикальной линии процессор установит значение логического нуля, то уровень напряжения на горизонтальной линии также будет соответствовать логическому нулю.

Как только на одной из горизонтальных линий появится уровень логического нуля, клавиатурный процессор фиксирует нажатие на клавишу. Он посылает в центральный компьютер запрос на прерывание и номер клавиши в матрице. Аналогичные действия выполняются и тогда, когда вы отпускаете нажатую ранее клавишу.

Скан-код клавиши

Номер клавиши, посылаемый клавиатурным процессором, однозначно зависит от схемы клавиатурной матрицы, но не от обозначений, нанесенных на поверхность клавиш. Этот номер называется скан-кодом (Scan Code). Слово scan («сканирование»), подчеркивает тот факт, что клавиатурный компьютер сканирует клавиатуру для поиска нажатой клавиши.

Код ASCII нажатой клавиши

Обычно программе нужен не порядковый номер нажатой клавиши, а код, соответствующий обозначению на этой клавише (код ASCII).

Код ASCII не связан напрямую со скан-кодом, так как одной и той же клавише могут соответствовать несколько значений кода ASCII в зависимости от состояния других клавиш. Например, клавиша с обозначением «1» используется еще и для ввода символа «!» (если она была нажата вместе с клавишей ).

Поэтому все преобразования скан-кода в код ASCII выполняются программно. Как правило, в операционной системе MS-DOS эти преобразования выполняют модули BIOS. Для использования символов кириллицы эти модули расширяются клавиатурными драйверами, как входящими в состав локализованных версий MS-DOS, так и созданными в виде отдельных программ.

Режим автоповтора

Если нажать на клавишу и не отпускать ее, клавиатура перейдет в режим автоповтора. При этом в компьютер автоматически через некоторый период времени, называемый периодом автоповтора, посылается код нажатой клавиши. Режим автоповтора облегчает ввод с клавиатуры большого количества одинаковых символов.

Следует отметить, что клавиатура содержит внутренний 16-байтовый буфер, через который она осуществляет обмен данными с компьютером.

Типы клавиатур

До недавнего времени существовали три различных типа клавиатуры. Это клавиатура для компьютеров IBM PC/XT, 84-клавишная клавиатура для IBM PC/AT и 101-клавишная (расширенная) клавиатура для IBM PC/AT. Некоторые клавиатуры имеют переключатель режима работы (XT/AT), расположенный на нижней крышке. Он должен быть установлен в правильное положение.

После того как операционная система Microsoft Windows получила широкое распространение, специально для нее был создан новый тип клавиатуры. К обычной клавиатуре типа IBM PC/AT были добавлены две кнопки, первая из которых дублирует вызов меню Start, выполняемый при помощи левой клавиши мыши, а вторая – вызов того же меню при помощи правой клавиши мыши.

Порты для работы с клавиатурой

Назначение портов, предназначенных для работы с клавиатурой, зависят от типа компьютера.

Компьютер IBM PC/XT

Для работы с клавиатурой типа IBM PC/XT используются порты с адресами 60h и 61h.

Порт 60h доступен только для чтения. После выполнения этой операции он содержит скан-код последней нажатой клавиши.

Так как порт 61h управляет не только клавиатурой, при изменении содержимого старшего бита необходимо сохранить состояние остальных битов этого порта. Для этого можно сначала выполнить чтение содержимого порта в регистр, изменить состояние старшего бита, затем выполнить запись нового значения в порт:

Современные компьютеры

Современные компьютеры позволяют управлять скоростными характеристиками клавиатуры, а также зажигать или гасить светодиоды Scroll Lock, Num Lock и Caps Lock, расположенные на лицевой панели клавиатуры.

Для расширенного управления клавиатурой применяется порт 60h в режиме записи. Этот порт служит для управления подчиненным процессором Intel 8042, ответственным за обмен данными с клавиатурным компьютером, или его аналогом, установленным на системной плате компьютера.

При использовании порта 60h на запись программа дополнительно получает следующие возможности:

· установка времени ожидания перед переходом клавиатуры в режим автоповтора;

· установка периода генерации скан-кода в режиме автоповтора;

· управление светодиодами, расположенными на лицевой панели клавиатуры.

Процессор 8042 обслуживает не только клавиатуру, но и другие системы компьютера. Через порт 64h, например, выполняется сброс (отключение) процессора 80286 для возврата из защищенного режима работы в реальный. Подробности об этом вы можете узнать из 6 тома «Библиотеки системного программиста», который называется «Защищенный режим процессоров Intel 80286/80386/80486».

Перед тем как посылать команду процессору 8042, необходимо убедиться в том, что его внутренняя очередь команд пуста. Это можно сделать, прочитав слово состояния 8042 из порта с адресом 64h. Бит с номером 1 должен быть равен нулю.

Приведем фрагмент программы, составленной на языке ассемблера, проверяющий состояние очереди команд процессора 8042:

После того, как программа дождется готовности процессора 8042, она может послать ему команду, записав ее в порт с адресом 60h:

Некоторые команды состоят более чем из одного байта. Второй и следующие байты таких команд необходимо записывать в порт 60h, предварительно убедившись в готовности процессора 8042 с помощью приведенной выше последовательности команд. В большинстве случаев можно также использовать простую временную задержку:

Для установки характеристик режима автоповтора в порт 60h необходимо записать код команды 0F3h, затем байт, определяющий характеристики режима. Ниже вы найдете описание полей байта режима автоповтора:

Период автоповтора, который определяет количество посылок скан-кода, генерируемых процессором клавиатуры в одну секунду. Можно использовать не только те значения, которые приведены ниже, но и промежуточные, например, 9 или 15h.

Задержка включения режима автоповтора, mc:

Зарезервировано и должно быть равно нулю

Первоначально при инициализации системы BIOS устанавливает период задержки для включения режима автоповтора равным 500 мс при периоде автоповтора, равным 10 повторам в секунду. Если это слишком медленно для вас, вы можете установить другие значения.

Для управления светодиодами, расположенными на лицевой панели клавиатуры, используйте команду 0EDh. Вслед за этой командой в порт 60h необходимо записать байт, имеющий следующий формат:

1 – включить светодиод Scroll Lock;

0 – выключить светдиод Scroll Lock

1 – включить светодиод Num Lock;

0 – выключить светодиод Num Lock

1 – включить светодиод Caps Lock;

0 – включить светодиод Caps Lock

Программа KBDLED

Приведем пример простейшей программы KBDLED, управляющей светодиодами, расположенными на лицевой панели клавиатуры (листинг 2.1). Такое управление может выполняться только при использовании порта 60h, так как BIOS не содержит никаких подходящих для этого функций. Наша программа после запуска включит все светодиоды и будет ожидать, пока вы не нажмете любую клавишу. Затем программа выключит светодиоды.

Заметим, что программа KBDLED может не работать на виртуальной машине DOS, создаваемой, например, в операционной системе Microsoft Windows NT.

Листинг 2.1. Файл kbdled\kbdled.c

Аппаратное прерывание клавиатуры

Клавиатура подключена к линии прерывания IRQ1. Этой линии соответствует прерывание INT 09h.

Клавиатурное прерывание обслуживается BIOS, однако драйверы клавиатуры и резидентные программы могут организовывать дополнительную обработку прерывания INT 09h. Для этого может быть использована цепочка обработчиков прерывания.

Стандартный обработчик прерывания INT 09h

Как работает стандартный обработчик клавиатурного прерывания, входящий в состав BIOS?

Этот обработчик выполняет следующие действия:

· читает из порта 60h скан-код нажатой клавиши;

· записывает вычисленное по скан-коду значение кода ASCII нажатой клавиши в специальный буфер клавиатуры, расположенный в области данных BIOS;

· устанавливает в единицу бит 7 порта 61h, разрешая дальнейшую работу клавиатуры;

· возвращает этот бит в исходное состояние;

· записывает в порт 20h значение 20h для правильного завершения обработки аппаратного прерывания.

Буфер клавиатуры

Буфер клавиатуры имеет длину 32 байта и расположен в компьютере IBM PC/XT по адресу 0000h:041Eh.

В компьютерах моделей IBM PC/AT и IBM PS/2 расположение клавиатурного буфера задается содержимым двух слов памяти с адресами 0000h:0480h (смещение адреса начала буфера) и 0000h:0482h (смещение конца буфера). Обычно эти ячейки памяти содержат значения, соответственно, 001Eh и 003Eh. Так как смещения заданы относительно сегментного адреса 0040h, то стандартное расположение клавиатурного буфера в IBM PC/AT и IBM PS/2 соответствует его расположению в IBM PC/XT.

Буфер клавиатуры организован циклически. Это означает, что при его переполнении самые старые значения будут потеряны. Две ячейки памяти, находящиеся в области данных BIOS с адресами 0000h:041Ah и 0000h:041Ch содержат, соответственно, указатели на начало и конец буфера. Если значения этих указателей равны друг другу, буфер пуст.

Заметим, что вы можете удалить все символы из буфера клавиатуры, установив оба указателя на начало буфера. Однако есть более предпочтительный способ с использованием прерывания BIOS INT 16h, функции которого мы опишем позже в этой главе.

Указателями на начало и конец клавиатурного буфера обычно управляют обработчики прерываний INT 09h и INT 16h. Программа извлекает из буфера коды нажатых клавиш, используя различные функции прерывания INT 16h.

При переполнении внутреннего буфера клавиатуры или буфера, расположенного в области данных BIOS программа-обработчик прерывания INT 09h генерирует звуковой сигнал.

Переключающие клавиши

Источник

Клавиатурное прерывание

Клавиатура подключена к линии прерывания IRQ1. Этой линии соответствует прерывание INT 09h.

Клавиатурное прерывание обслуживается модулями BIOS. Драйверы клавиатуры и резидентные программы могут организовывать дополнительную обработку прерывания INT 09h. Для этого может быть использована цепочка обработчиков прерывания. В первой книге первого тома мы приводили примеры расширения обработчика прерывания INT 09h.

Как работает стандартный обработчик клавиатурного прерывания, входящий в состав BIOS?

Этот обработчик выполняет следующие действия:

Обработчик прерывания INT 09h не просто записывает значение ASCII-кода в буфер клавиатуры. Дополнительно отслеживаются нажатия таких комбинаций клавиш, как Ctrl-Alt-Del, обрабатываются специальные клавиши PrtSc и SysReq. При вычислении кода ASCII нажатой клавиши учитывается состояние клавиш Shift и CapsLock.

Буфер клавиатуры имеет длину 32 байта и расположен по адресу 0000h:041Eh для машин IBM PC/XT.

В IBM AT и PS/2 расположение клавиатурного буфера задается содержимым двух слов памяти с адресами 0000h:0480h (компонента смещения адреса начала буфера) и 0000h:0482h (смещение конца буфера). Обычно в IBM AT эти ячейки памяти содержат значения, соответственно, 001Eh и 003Eh. Так как смещения заданы относительно сегментного адреса 0040h, то видно, что обычное расположение клавиатурного буфера в IBM AT и PS/2 соответствует его расположению в IBM PC/XT.

Клавиатурный буфер организован циклически. Это означает, что при его переполнении самые старые значения будут потеряны. Две ячейки памяти, находящиеся в области данных BIOS с адресами 0000h:041Ah и 0000h:041Ch содержат, соответственно, указатели на начало и конец буфера. Если значения этих указателей равны друг другу, буфер пуст. (Можно удалить все символы из буфера клавиатуры, установив оба указателя на начало буфера. Однако есть более предпочтительный способ с использованием прерывания BIOS INT 16h).

Указателями на начало и конец клавиатурного буфера обычно управляют обработчики прерываний INT 09h и INT 16h.

Программа извлекает из буфера коды нажатых клавиш, используя различные функции прерывания INT 16h.

Формат байта 0000h:0417h:

Формат байта 0000h:0418h:

Если вы изменяете состояние светодиодов на панели клавиатуры, не забывайте устанавливать соответствующие биты в байтах состояния клавиатуры.

Программой обработки прерывания INT 09h отслеживаются некоторые комбинации клавиш. В таблице приведены эти комбинации и действия, выполняемые обработчиком прерывания при их обнаружении:

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Источник

Linux, отложенная загрузка драйверов и неработающие прерывания

Сегодня я расскажу о неожиданных проблемах, которые возникли при подключении матричной клавиатуры к ARM-борде под управлением Linux в приборе Беркут-ETN (ETN — новая аппаратная ревизия Беркут-ET). А конкретно о том, почему драйвер adp5589 не захотел получать прерывания и как мы смогли заставить его это делать.

Кому интересно — добро пожаловать под кат.

У самой клавиатуры контроллера нет — она подключена по шине I2C с помощью специального контроллера матричной клавиатуры — микросхемы adp5589. У микросхемы есть линия прерывания, заведённая на один из GPIO пинов ARM SoCа. В итоге схема подключения выглядит примерно так:

portb — это порт, на пин которого заведено прерывание от контроллера клавиатуры;
intc — главный контроллер прерываний;
i2c0 — контроллер шины i2c.

Драйвер adp5589 по каким-то причинам упорно не хочет получать номер прерывания. Что же может быть причиной такого поведения? Возможно, для загрузки драйвера клавиатуры не хватает каких-то ресурсов. Может быть не успели загрузиться устройства, от которых он зависит? Давайте посмотрим, от каких устройств он может зависеть:

Во-первых — от контроллера шины I2C, к которой он подключен.
Во-вторых — от контроллера порта, на пин которого у нас заведена линия прерывания.

Теперь посмотрим в каком порядке загружаются драйвера этих устройств:

gic
designware-i2c
adp5589
dw-apb-gpio-port

Ага! Вот и причина — когда загружается драйвер клавиатуры, его interrupt-parent ещё не загружен. Как результат — драйвер клавиатуры не получает номер прерывания. Стандартное решение этой проблемы — механизм отложенной загрузки драйверов.

Его суть в том, что драйвер может потребовать повторной загрузки, если какой-нибудь нужный ему ресурс ещё не доступен. А потребовать он это может, вернув значение -EPROBE_DEFER из своей функции probe. Тогда этот драйвер будет повторно загружен позже. К тому времени или нужный ресурс уже будет доступен, или загрузка драйвера снова будет отложена.

Добавляем проверку в функцию probe драйвера клавиатуры:

В надежде смотрим на новый порядок загрузки:
gic
adp5589
designware-i2c
dw-apb-gpio-port
(deferred)adp5589
(deferred)adp5589
(deferred)adp5589

Что-то пошло не так — драйвер клавиатуры повторно загрузился после драйвера GPIO, но прерывания так и не получил. Похоже, придётся зарываться в исходный код глубже, чем ожидалось.

Напрашивается три возможных пути решения:

Вариант рабочий, но не желательный. Подойдёт в качестве временного, но если что-нибудь поменять в аппаратной части (например выход прерывания подключить к другому порту GPIO), то изменения придётся вносить не только в Device Tree, но и в исходный код драйвера.

Явно задать порядок загрузки драйверов возможности нет. Так что этот вариант не подходит.

Самый правильный. Его и будем рассматривать.

Здесь, пожалуй, стоит кратко рассказать про такую вещь как Device Tree, так как далее будут отсылки к ней.

Device Tree — это одна из форм описания аппаратной части устройства, на котором мы хотим использовать Linux. Представляется в виде дерева узлов, в которых задаётся нужная информация. DT существует в виде текстовых человекочитаемых файлов (.dts; .dtsi) и собираемого из них бинарного файла (.dtb).

(Не интересующие нас сейчас узлы и свойства вырезаны для облегчения понимания)

i2c0, keybs, inc и portb — узлы, всё остальное — их свойства. Из кода сразу становится видно что чип контроллера клавиатуры подключен к I2C шине. В свойстве compatible — строка, которая описывает производителя и модель устройства. Именно по этому свойству ОС понимает какой драйвер нужно связать с этим устройством.

interrupt-controller — свойство, указывающее, что это устройство может являться контроллером прерываний, а interrupt-parent указывает к кому подключено прерывание от текущего устройства.

#interrupt-cells — свойство, указывающее на количество параметров, которыми описываются прерывания данного контроллера прерываний, а interrupts — свойство, в котором задаются параметры для данного прерывания.

Здесь описываются два параметра. Первый — это номер пина в порте portb, на который у нас заведена линия прерывания от контроллера клавиатуры. Второй — тип прерывания (по низкому или высокому уровню). Как узнать сколько для контроллера прерываний нужно описывать параметров, и что каждый из них значат? Обычно про это написано в документации. Так, про portb написано в этом файле: Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt.

&portb — ссылка на узел portb (в нашем случае ссылка на portb будет равна /soc/gpio@ff709000/gpio-controller@0)
Остальные свойства нам пока не понадобятся, про них, и вообще про Device Tree, подробно можно почитать здесь: devicetree.org/Device_Tree_Usage.

Ещё не лишним будет упомянуть про процесс регистрации устройств и драйверов (не беспокойтесь, к основной теме мы вернёмся уже в следующем абзаце). Согласно Linux Device Model:

Устройство — физический или виртуальный объект, который подключен к шине(возможно тоже виртуальной)
Драйвер — программный объект, который может быть связан с устройством и может выполнять какие-либо функции управления.
Шина — устройство, предназначенное быть “точкой крепления” других устройств. Базовая функциональность всех шин, поддерживаемых ядром, определяется структурой bus_type. В этой структуре объявлена вложенная структура subsys_private, в которой объявлены два списка: klist_devices и klist_drivers.
klist_devices — список устройств, которые подключены к шине.
klist_drivers — список драйверов, которые могут управлять устройствами на этой шине.
Устройства и драйвера добавляются в эти списки с помощью функций device_register и driver_register. Кроме того, device_register и driver_register связывают устройство с подходящим драйвером. device_register проходит по списку драйверов и пытается найти драйвер, подходящий для данного устройства. (driver_register проходит по списку устройств и пытается найти устройства, которыми он может управлять) Проверка подходит ли драйвер для устройства производится с помощью функции match(dev, drv), указатель на которую есть в структуре bus_type.

Теперь можно перейти и к основной теме — реализации механизма отложенной загрузки драйверов. Заглянем в файл drivers/base/dd.c Вот краткое описание того, что мы там увидим:

Для управления повторной загрузкой драйверов имеются два списка — deferred_probe_pending_list и deferred_probe_active_list.

deferred_probe_pending_list — список устройств, для загрузки драйвера которых не хватает каких-то ресурсов.
deferred_probe_active_list — список устройств, драйвер которых можно попробовать запустить повторно.

В функции really_probe вызывается функция probe для шины, на которой расположено устройство. В нашем случае это функция i2c_device_probe и выглядит это так dev->bus->probe(dev). Возвращаемое значение проверяется на ошибки, и, если оно равно -EPROBE_DEFER, то устройство добавляется в deferred_probe_pending_list.

Но самое интересное — как и когда драйвер вызывается заново. Пока драйверы возвращают -EPROBE_DEFER, устройства последовательно добавляются в deferred_probe_pending_list. Но как только для какого-либо драйвера функция probe завершилась успешно, все устройства из deferred_probe_pending_list переносятся в deferred_probe_active_list. Выглядит логично — возможно, того драйвера, который у нас последний был успешно загружен, и не хватало для нормальной загрузки отложенных драйверов. Повторная попытка запуска драйверов из deferred_probe_active_list производится функцией deferred_probe_work_func. В ней вызывается bus_probe_device для каждого устройства из списка.

Вызов bus_probe_device в конечном итоге снова приведёт нас к функции really_probe для пары из нашего устройства и его драйвера (см. выше).

Но подождите! Мы сейчас говорили о вызове функции probe для шины, на которой расположено устройство. То есть о i2c_device_probe. А как же функция probe драйвера клавиатуры? Нет, про неё мы не забыли, она как раз будет вызвана из i2c_device_probe. В этом можно убедиться, взглянув на её код в файле drivers/i2c/i2c-core.с:

Ладно, повторная загрузка вроде бы работает, почему же тогда драйвер клавиатуры не получает номера прерывания?
Попробуем отследить то, как номер прерывания должен попасть в наш драйвер.

В функцию adp5589_probe(struct i2c_client *client, const struct i2c_device_id *id) передаётся структура client, одно из полей которой — irq — номер прерывания, которое будет генерировать наше устройство (контроллер клавиатуры). adp5589_probe вызовется из функции i2c_device_probe(struct device * dev). В неё передаётся структура device, из указателя на которую вычисляется указатель на структуру i2c_client (с помощью магии макроса container_of).

Этот макрос принимает на вход указатель на поле структуры, тип этой структуры и имя поля на которое указывает указатель, а возвращает указатель на саму структуру.

Про его работу хорошо расписано здесь.

Значит нужно найти где заполняется структура i2c_client. Заполняется она в функции i2c_new_device(struct i2c_adapter * adap, struct i2c_board_info const * info); Конкретно поле irq копируется из одноимённого поля структуры i2c_board_info.

Структура i2c_board_info заполняется в функции of_i2c_register_devices(struct i2c_adapter * adap).

irq_of_parse_and_map — это обёртка для цепочки из двух функций — of_irq_parse_one и irq_create_of_mapping; функция of_irq_parse_one пытается найти узел, который заявлен в device tree как interrupt-controller для текущего устройства.
Помните эти несколько строчек в device tree?

Именно portb и ищет of_irq_parse_one, а по результатам своей работы заполняет структуру of_phandle_args, которая передаётся функции irq_create_of_mapping. irq_create_of_mapping уже и возвращает искомый номер прерывания.

В первый раз of_irq_parse_one не находит порт GPIO, на что ругается в лог:

irq: no irq domain found for /soc/gpio@ff709000/gpio-controller@0!

А что происходит при повторной загрузке драйвера? А ничего. Вызываются то только i2c_device_probe и adp5589_probe.
Вот в чём и проблема. Прерывание устанавливается только в первый раз и остаётся таким навечно, сколько бы мы не выполняли повторную загрузку нашего драйвера.

Проблему нашли, но как её исправить?

Можно попробовать перенести код получения прерывания в i2c_device_probe. До этого нам номер прерывания нигде не требуется, так что проблем возникнуть не должно.

Но лучше давайте заглянем в исходники более свежей версии ядра (у нас установлена версия 3.18) Вот что мы там увидим:
Установку прерывания i2c клиента перенесли в функцию i2c_device_probe.

В структуре i2c_board_info хоть и осталось поле irq но оно не используется. Так что в новых версиях ядра проблема исправлена.

Осталось всего лишь перенести изменения в нашу версию. Все изменения коснутся файла drivers/i2c/i2c-core.c
Добавим в нашу i2c_device_probe установку прерывания клиента i2c, что появилась в свежей версии, а в функции of_i2c_register_devices удаляем установку прерывания.

Проверяем — клавиатура работает. Смотрим в /proc/interrupt:

Источник