Page 1 of 2

Обработка IRQ

Posted: Wed May 02, 2007 3:29 pm
by diamond
Сейчас существуют два механизма обработки IRQ. Первый - механизм 3-кольца, системные функции 41,42,44,45. Второй - драйверный механизм, экспортируемая ядром AttachIntHandler. Так вот, проблема заключается в том, что они несовместимы: для конкретного IRQ либо его можно обрабатывать первым механизмом, либо его можно обрабатывать вторым механизмом. Какая из ситуаций реализуется, определяется таблицей в sys32.inc: входы irq_serv.irq_<n> передают управление зарегистрированным в attach_int_handler обработчикам, входы p_irq<n> - на irqhandler, реализующему первый механизм. Для справки список программ, использующих вышеупомянутые сисфункции: входящие в дистрибутив terminal и ppp.asm и входящие в папку develop исходников дистрибутива (читай - примеры программирования) ir и rtdata. В результате уже сейчас, например, либо потенциально работает ppp.asm, либо потенциально работает драйвер uart.asm (конфликт на COM1). Внимание, вопрос: что вы обо всём этом думаете?

Posted: Wed May 02, 2007 3:41 pm
by Mario79
Нужен один вариант. Вопрос только который лучше и проще.

Posted: Wed May 02, 2007 4:52 pm
by Serge
Если оставить первый вариант то про звук можно будет забыть до тех пор пока не появятся user-mode драйверы способные работать отдельным потоком в режиме реального времени. Пока таких не предвидется.
Первый вариант похож на обработку IRQ в микроядре только реализован очень криво, особенно бестолковая ф.44. Второй расчитан на драйверы работающие в режиме ядра. При желании его можно объеденить с первым если вызывать irqhandler в тех случаях когда драйверный обработчик прерывания не установлен.

Posted: Wed May 02, 2007 5:42 pm
by Serge
Кстати первый вариант в существующем виде не годится для обработки PCI IRQ. Они выставлены по уровню, а не по фронту как ISA. Поэтому надо или обработать прерывание или маскировать линию в PIC (как в minix3) до того как отправлять EOI.

Posted: Tue May 08, 2007 3:51 pm
by diamond
Мне кажется, пора бы уже определиться. Конечно, сейчас это ещё не очень актуально, но лучше решать проблемы в момент возникновения, а не когда они начинают действовать на нервы.
Я тоже предпочитаю драйверный подход, но переписывать ppp.asm не готов...

Posted: Tue May 08, 2007 4:53 pm
by Serge
diamond

Тогда надо определиться каким должно быть ядро монолитным или микро. Потому что получается странно - половину прерываний обрабатывает ядро, другую могут обработать приложения, это IRQ 2,5,7,8,9,10,11 и 3 и 4 если не подключена СОМ-мышь. О проблемах с IRQ от PCI устройств я уже писал. Обработать проерывание от USB или AC97 в программе не получится.

Posted: Sat May 19, 2007 7:54 pm
by SPraid
мне хотелась ускорить работу сети.. как я понял нало переходить на прерывания. Насколько это реально в сетевом драйвере использовать?

Posted: Sat May 19, 2007 9:27 pm
by Serge
SPraid

Вполне реально. Для примера посмотри drivers/sceletone.asm - там заготовка для драйвера и код поиска нужного устройства на шине PCI и drivers/sound.asm - пример драйвера PCI устройства.

Re: Обработка IRQ

Posted: Tue Aug 16, 2011 3:49 pm
by Serge
Четыре года достаточный срок, чтобы определиться.

Поэтому в ближайшем будущем функции 41,42,44,45 будут удалены из ядра и вся обработка прерываний будет происходить только в ядре. Если вам необходимо отреагировать на Irq в user-mode, есть подсистема событий и функции create_event, raise_event, sys_getevent. Используйте их для доставки сообщения из обработчика прерываний.

Вводятся разделяемые обработчики прерываний для правильной работы с устройствами PCI. (Не прошло и ...)
Функция int attach_int_handler(int irq_line, void (*handler)(void), int access);
меняется на int attach_int_handler(int irq_line, int (*handler)(void*), void *user_data); где user_data - данные пользователя, обычно указатель.
возвращаемое значение - логичический номер обработчика.

меняется формат обработчка прерываний
вместо текущего void irq_handler(void);
на int __cdecl irq_handler(void *user_data);
Spoiler:К.О. напоминает что соглашение __cdecl требует сохранения регистров ebx, esi, edi, ebp
Обработчик должен возвратить ненулевое значение если прерывание было от устройства, в противном случае 0. Обработчики прерыванией ISA устройств должны всегда возвращать ненулевое значение. Для каждой линии irq будет вестись подсчёт числа необработанных прерываний. При превышении некоторого лимита линия будет маскироваться.

Заглушка
void detach_int_handler(void){};
меняется на
int detach_int_handler(unsigned int handle);
где handle логический номер обработчика, установленного функцией attach_int_handler

Детали реализации.
Для хранения информации об обработчиках вводится структура

Code: Select all

struc IRQH
{
   .list            LHEAD  ; linux like list head
   .handler         dd ?   ;handler roututine
   .data            dd ?   ;user-specific data
   .sizeof:
}
Обработчики прерываний для одной линии объединяются в двусвязные списки. При наступлении прерывания ядро устанавливает флаг необработанного irq в битовой маске и последовательно вызывает каждый обработчик из списка. Если обработчик возвращает ненулевое значение ядро сбрасывает флаг irq. После того, как были вызваны все обработчики, ядро проверяет флаг irq и увеличивает счётчик ошибок если флаг не сброшен.

Re: Обработка IRQ

Posted: Tue Aug 16, 2011 4:27 pm
by CleverMouse
Хорошо, давно пора. В транке это будет и если да, то когда?

Re: Обработка IRQ

Posted: Tue Aug 16, 2011 4:32 pm
by Serge
Изменения будут вводится постепенно. Сначала будут исправлены обработчики прерываний у существующих драйверов. Потом удалены функции 41,42,44,45 и добавлены расшареные обработчики. Через некоторое время будет сделано маскирование линий. Предварительная версия залита в бранч kolibri-acpi. У себя проверял совместную работу usb и видеоплеера с акселерацией. Всё нормально.

Re: Обработка IRQ

Posted: Tue Aug 16, 2011 5:32 pm
by art_zh
Serge
Правильно, сейчас обработка IRQ - это смесь шарады с лотереей.
Только надо не забывать, что еще есть мультивекторные устройства, и [по мере роста популярности MSI] их будет все больше и больше.
Serge wrote:Если вам необходимо отреагировать на Irq в user-mode, есть подсистема событий и функции create_event, raise_event, sys_getevent. Используйте их для доставки сообщения из обработчика прерываний.
Для обработки MSI одного факта события мало - нужно еще и передать обработчику сам 16-битный мессидж.
Или предусмотреть для каждого устройства импорт списка обработчиков всех возможных векторов.
Serge wrote:Для каждой линии irq будет вестись подсчёт числа необработанных прерываний. При превышении некоторого лимита линия будет маскироваться.
При заморочках с MSI-запросами (а они могут быть совершенно феерические!) надо маскировать всё устройство, причем не только в APIC, но еще и в PCI-конфигспейсе. Операция примитивная, но для этого надо знать bdf-адрес устройства.

Так что не забудь включить в attach_int_handler еще и bdf.
Впрочем, ты же это делаешь для ACPI-ядра? Там ведь и bdf может измениться на лету!

Re: Обработка IRQ

Posted: Tue Aug 16, 2011 6:56 pm
by Serge
art_zh

Это для всех. На acpi пока проверяю.
Ты меня озадачил. С msi нет проблемы дописать, обработчик __cdecl. А bdf добавить сложнее потому что attach_int_handler stdcall. Это придётся менять всё одновременно - ядро все драйверы и номер драйверной модели.

Re: Обработка IRQ

Posted: Wed Aug 17, 2011 12:52 am
by art_zh
Serge
Наверное, для MSI нужен будет отдельный формат запроса и хэндла. Я сейчас вообще не представляю как можно унифицировать обработчики MSI-запросов - они будут очень специфическими для разных устройств.

Кстати, еще совсем недавно MSI ненавидели не только программисты, но и электронщики. В раннем стандарте PCI Express даже пришлось разрабатывать отдельные типы запросов - специально для эмуляции IRQ и INTA.

Сейчас генеральная линия партии PCI-SIG называет эти запросы не иначе как "Legacy PCI interrupt" и настоятельно рекомендует разработчикам отказаться от них (также как и от портов ввода/вывода) и всюду переходить на MSI. В новых чипсетах, FPGA-ядрах и эндпойнт-чипах поддержка MSI реализована довольно удобно (с точки зрения электронщика), но программистам от этого легче не стало...
Стало хуже - мы (разработчики) теперь совсем страх потеряли и можем запросто навесить на MSI-канал по 8, 32, а иногда даже 128 векторов! На каждый чих - свой мессидж; RT-шиза рулит. Очень удобно, и главное - думать не надо.
Последний писк - устройства не только без IO-портов, но даже без MMIO. Все BARы пустые, управление - через регистры конфигспейса, данные грузятся сами собой (по DMA), а дополнительные функции настраиваются программно, через MSI-обработчики.
И еще есть устройства, в которых MSI вообще не отображается на APIC, а просто пишет свои мессиджи в программно-доступный буфер. С ними ядру вообще ничего делать не надо, но с ACPI заморочки будут обязательно: энумератор для них развесит целую гирлянду APIC-каналов, а потом драйвер перемаппит мессиджи в свой буфер... или наоборот.

В общем, делай как решил, под PCIe все равно перепиливать нужно очень многое, одной драйверной моделью здесь не обойдешься.

Re: Обработка IRQ

Posted: Wed Aug 17, 2011 10:09 am
by Serge
art_zh
Думаю пока не надо мешать всё в одну кучу.
Со стороны железки понятно, программируются регистры в pcicfg куда писать и что писать. А что происходит со стороны процессора ? Каким образом msi принимается контроллером прерываний ?

Зашёл на сайт Intel поискать pdf-ы. Что они сделали с документацией ? Просто нет приличных слов.