Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Ср дек 13, 2017 4:06 pm

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 26 сообщений ]  На страницу 1 2 След.
Автор Сообщение
 Заголовок сообщения: Обработка IRQ
СообщениеДобавлено: Ср май 02, 2007 3:29 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
Сейчас существуют два механизма обработки 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). Внимание, вопрос: что вы обо всём этом думаете?

_________________
Ушёл к умным, знающим и культурным людям.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср май 02, 2007 3:41 pm 
Нужен один вариант. Вопрос только который лучше и проще.


Вернуться к началу
   
 Заголовок сообщения:
СообщениеДобавлено: Ср май 02, 2007 4:52 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
Если оставить первый вариант то про звук можно будет забыть до тех пор пока не появятся user-mode драйверы способные работать отдельным потоком в режиме реального времени. Пока таких не предвидется.
Первый вариант похож на обработку IRQ в микроядре только реализован очень криво, особенно бестолковая ф.44. Второй расчитан на драйверы работающие в режиме ядра. При желании его можно объеденить с первым если вызывать irqhandler в тех случаях когда драйверный обработчик прерывания не установлен.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Ср май 02, 2007 5:42 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
Кстати первый вариант в существующем виде не годится для обработки PCI IRQ. Они выставлены по уровню, а не по фронту как ISA. Поэтому надо или обработать прерывание или маскировать линию в PIC (как в minix3) до того как отправлять EOI.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Вт май 08, 2007 3:51 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
Мне кажется, пора бы уже определиться. Конечно, сейчас это ещё не очень актуально, но лучше решать проблемы в момент возникновения, а не когда они начинают действовать на нервы.
Я тоже предпочитаю драйверный подход, но переписывать ppp.asm не готов...

_________________
Ушёл к умным, знающим и культурным людям.


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Вт май 08, 2007 4:53 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
diamond

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


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Сб май 19, 2007 7:54 pm 
Не в сети
Kernel Developer

Зарегистрирован: Пт фев 23, 2007 11:55 pm
Сообщения: 63
мне хотелась ускорить работу сети.. как я понял нало переходить на прерывания. Насколько это реально в сетевом драйвере использовать?


Вернуться к началу
 Заголовок сообщения:
СообщениеДобавлено: Сб май 19, 2007 9:27 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
SPraid

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


Вернуться к началу
 Заголовок сообщения: Re: Обработка IRQ
СообщениеДобавлено: Вт авг 16, 2011 3:49 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
Четыре года достаточный срок, чтобы определиться.

Поэтому в ближайшем будущем функции 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);
Спойлер: Показать
К.О. напоминает что соглашение __cdecl требует сохранения регистров ebx, esi, edi, ebp
Обработчик должен возвратить ненулевое значение если прерывание было от устройства, в противном случае 0. Обработчики прерыванией ISA устройств должны всегда возвращать ненулевое значение. Для каждой линии irq будет вестись подсчёт числа необработанных прерываний. При превышении некоторого лимита линия будет маскироваться.

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

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


Вернуться к началу
 Заголовок сообщения: Re: Обработка IRQ
СообщениеДобавлено: Вт авг 16, 2011 4:27 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Чт сен 03, 2009 1:52 pm
Сообщения: 1601
Хорошо, давно пора. В транке это будет и если да, то когда?

_________________
Сделаем мир лучше!


Вернуться к началу
 Заголовок сообщения: Re: Обработка IRQ
СообщениеДобавлено: Вт авг 16, 2011 4:32 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
Изменения будут вводится постепенно. Сначала будут исправлены обработчики прерываний у существующих драйверов. Потом удалены функции 41,42,44,45 и добавлены расшареные обработчики. Через некоторое время будет сделано маскирование линий. Предварительная версия залита в бранч kolibri-acpi. У себя проверял совместную работу usb и видеоплеера с акселерацией. Всё нормально.


Вернуться к началу
 Заголовок сообщения: Re: Обработка IRQ
СообщениеДобавлено: Вт авг 16, 2011 5:32 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Serge
Правильно, сейчас обработка IRQ - это смесь шарады с лотереей.
Только надо не забывать, что еще есть мультивекторные устройства, и [по мере роста популярности MSI] их будет все больше и больше.
Serge писал(а):
Если вам необходимо отреагировать на Irq в user-mode, есть подсистема событий и функции create_event, raise_event, sys_getevent. Используйте их для доставки сообщения из обработчика прерываний.
Для обработки MSI одного факта события мало - нужно еще и передать обработчику сам 16-битный мессидж.
Или предусмотреть для каждого устройства импорт списка обработчиков всех возможных векторов.
Serge писал(а):
Для каждой линии irq будет вестись подсчёт числа необработанных прерываний. При превышении некоторого лимита линия будет маскироваться.
При заморочках с MSI-запросами (а они могут быть совершенно феерические!) надо маскировать всё устройство, причем не только в APIC, но еще и в PCI-конфигспейсе. Операция примитивная, но для этого надо знать bdf-адрес устройства.

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


Вернуться к началу
 Заголовок сообщения: Re: Обработка IRQ
СообщениеДобавлено: Вт авг 16, 2011 6:56 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
art_zh

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


Вернуться к началу
 Заголовок сообщения: Re: Обработка IRQ
СообщениеДобавлено: Ср авг 17, 2011 12:52 am 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
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
СообщениеДобавлено: Ср авг 17, 2011 10:09 am 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
art_zh
Думаю пока не надо мешать всё в одну кучу.
Со стороны железки понятно, программируются регистры в pcicfg куда писать и что писать. А что происходит со стороны процессора ? Каким образом msi принимается контроллером прерываний ?

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


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 26 сообщений ]  На страницу 1 2 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB