[serg_Fry 0]

в процессе работы возник следубщий вопрос:

есть master/target устройство.

Мастер - для DMA , Target - для управления им.

Есть 1 прерывание.

Прерывание одно на несколько устройств(interrupt share). Когда любое из устройств, висящих на этом прерывании его вызывает, контроллер по очереди передает управление всем драйверам этих самых устройств. Те в свою очередь обращаютя к своим устройствам, проверяют им ли предназначено прерывание, если да, тогда они позволяют устройству снять запрос на прерывание.

Собственно вопрос такой: другие устройства могут выставить прерывание в произвольный момент времени, если мое устройство в этот момент будет передавать по DMA(в режиме мастера), то оно не сможет ответить на запрос обработчика прерывания(в драйвере) о том ему адресовано прерывание или нет(так как это чтение из порта, а оно возможно только в target режиме). Как организовать постоянный доступ к портам таргета при DMA?

Я полагаю чистых Мастеров не делают(или оч. редко) значит ситуация расхожая, но я нигде не нашел ничего об этом.

[line 0]

Собственно вопрос такой: другие устройства могут выставить прерывание в произвольный момент времени, если мое устройство в этот момент будет передавать по DMA(в режиме мастера), то оно не сможет ответить на запрос обработчика прерывания(в драйвере) о том ему адресовано прерывание или нет(так как это чтение из порта, а оно возможно только в target режиме).

Все по-порядку. PCI-ядро выставляет прерывание. Обработчик прерывания в драйвере считывает регистр состояния прерывания PCI-ядра - этот регистр доступен для чтения обработчиком независимо от наличия/отсутствия передачи данных по ДМА (шина не грузится мастером на 100%).

 

Как организовать постоянный доступ к портам таргета при DMA?

Ну, а после обработки прерывания, организация потока для записи в порт уже дело программистов. При необходиомости мнгновенной реакции системы на прерывание, можно и из обработчика в порт данные слать (если их немного, конечно) - но, по-моему, это не есть хорошо.

[serg_Fry 0]

Все по-порядку. PCI-ядро выставляет прерывание. Обработчик прерывания в драйвере считывает регистр состояния прерывания PCI-ядра - этот регистр доступен для чтения обработчиком независимо от наличия/отсутствия передачи данных по ДМА (шина не грузится мастером на 100%).

как раз это и непонятно: как регистр может быть всегда доступен?(где бы он ни находился: в пр-ве портов или в конфигурационном пространстве)

Предположим ДМА передает burst'ом 100 фаз данных.В это время обработчик получил прерывание(не от нашего устройства) , он говорит драйверу, что нужно считать регистр состояния, драйвер в свою очередь вызывает ф-ю ReadPort , далее комп в роли мастера пытается инициировать транзакцию чтения, НО

1 он не получит доступа к шине пока текущая транзакция не закончится, а она может тянуться долго.

+как выяснилось время отпущенное каждому драйверу на определение принадлежности ему прерывания ограничено.

2 как устройство поймет, что надо переводит буферы сигналов на прием?(например TRDY для мастера вх., для таргета - вых.)

 

----------------

я свою проблему решил следующим образом:

Если мы выставили прерывание, тогда ДМА ждет пока драйвер не попросит его(прерывание) снять.

Если прерывание выставлено не нами, тогда ф-я read_Port возвращает все '1' для значения регистра состояния.(~реально один бит у меня всегда '0') - как раз случай когда времени на опр. принадлежности прер-я не хватает.

Таким образом для обработчика это значит, что прерывание адресовано не нам.

----------------

Но я все же не понимаю, как др. устройства-мастера решают эту проблему.

Изменено 24 ноября, 2005 пользователем qwqw

[line 0]

Предположим ДМА передает burst'ом 100 фаз данных.В это время обработчик получил прерывание(не от нашего устройства) , он говорит драйверу, что нужно считать регистр состояния, драйвер в свою очередь вызывает ф-ю ReadPort , далее комп в роли мастера пытается инициировать транзакцию чтения, НО

1 он не получит доступа к шине пока текущая транзакция не закончится, а она может тянуться долго.

Долго - понятие относительное. По спецификации время передачи 64 фаз данных burst'ом составляет 2,16 мкс.

 

+как выяснилось время отпущенное каждому драйверу на определение принадлежности ему прерывания ограничено.

Как то не бло проблем с этим... И сколько составляет это время и кем ограничивается?

 

2 как устройство поймет, что надо переводит буферы сигналов на прием?(например TRDY для мастера вх., для таргета - вых.)

----------------

я свою проблему решил следующим образом:

Если мы выставили прерывание, тогда ДМА ждет пока драйвер не попросит его(прерывание) снять.

Если прерывание выставлено не нами, тогда ф-я read_Port возвращает все '1' для значения регистра состояния.(~реально один бит у меня всегда '0') - как раз случай когда времени на опр. принадлежности прер-я не хватает.

Таким образом для обработчика это значит, что прерывание адресовано не нам.

----------------

Но я все же не понимаю, как др. устройства-мастера решают эту проблему.

Наверное, лучше всего на эти вопросы ответит спецификация PCI - главы по арбитражу шины

[VslavX 0]

я свою проблему решил следующим образом:

Если мы выставили прерывание, тогда ДМА ждет пока драйвер не попросит его(прерывание) снять.

Если прерывание выставлено не нами, тогда ф-я read_Port возвращает все '1' для значения регистра состояния.(~реально один бит у меня всегда '0') - как раз случай когда времени на опр. принадлежности прер-я не хватает.

Таким образом для обработчика это значит, что прерывание адресовано не нам.

----------------

Но я все же не понимаю, как др. устройства-мастера решают эту проблему.

Прерывания и бас-мастеринг абсолютно несвязанные вещи.

На сегмента PCI всегда есть арбитр. Допустим, Ваш мастер выставил арбитру REQ# и получил от него GNT# и начал свою "долгую песню" - burst transfer. Теперь допустим Ваше устройство выставляет прерывание, оно попадает на процессор, вызывается обработчик в драйвере, где, допустим, инициируется чтение регистра из Вашего тагета. В этот момент на арбитр сегмента будет выставлен REQ# со стороны другого мастера - некоторого моста в чипсете, через который PCI привязан к ЦП, (ведь доступом к тагет всегда кто-то рулит).

Как точно поступит арбитр - зависит от многих условий (от конфигурации полей MIN_GNT, MAX_LAT всех устройств на сегменте, и от реализации самого арбитра), но все равно он в какое-то конечное время снимет GNT# Вашему мастеру, в ответ мастер освободит шину и арбитр отдаст ее мосту "ЦП-PCI" который собственно и выполнит чтение регистра в Вашем тагете. Далее, шина опять освободится, и ее могут отдать опять Вашему мастеру для "солирования".

[serg_Fry 0]

2line:

Как то не бло проблем с этим... И сколько составляет это время и кем ограничивается?

если честно, то я ничего конкретного об этом не нашел.

Как не нашел и описание механизма работы связки windows - pci абонент на стороне компа(тот что на чипсете), но опыт показал, что несмотря на длительные транзакции, при штатной работе запись/чтение моего таргета всегда происходит, а вот обработчик прерывания вероятно из-за своего выского приоритета ограничен по времени и может не дождаться своей очереди.

2VslavX: примерно так я себе и представляю с той лишь разницей, что снятием #GNT арбитр не заставит меня закончить мою "долгую песню" :) , а всего навсего не даст начать еще одну. Как я понимаю арбитр управляет доступом только между транзакциями, но не может их останавливать или приостанавливать.

Изменено 27 ноября, 2005 пользователем qwqw

[line 0]

2line:

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

Драйвер прерывание обрабатывает? DPC вызывается? Частота прерываний какая? На каком месте вашей цепочки Вы пропускаете прерывание? Не должно быть пропуска прерываний, если все правильно сделано (если Вы увспеваете обработать прерывание до поступления следующего).

[Tosha 0]

VslavX: примерно так я себе и представляю с той лишь разницей, что снятием #GNT арбитр не заставит меня закончить мою "долгую песню" , а всего навсего не даст начать еще одну. Как я понимаю арбитр управляет доступом только между транзакциями, но не может их останавливать или приостанавливать.

 

Как раз-таки арбитр может остановить ваше устройство, если оно соответствует стандарту PCI. Устройство может передавать данные по шине либо пока установлен #GNT, либо пока не истек Latency timer. Поэтому если арбитр забирает #GNT и таймер истек, мастер должен сразу прекратить передачу.

[serg_Fry 0]

Да, насчет арбитра - я невнимательно прочитал спецификацию,

спасибо, что поправили.

[serg_Fry 0]

еще такой вопрос:

В новых материнских платах в биосе есть параметр Latency timer, какой в нем смысл, если каждое устройство само определяет для себя это значение(рекамендованое в MIN_GNT)?

Вообще весь механизм не очень понятен:

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

[VslavX 0]

ИМХО, не совсем так.

Latency Timer в BIOS - это параметр записываемый в Config Space всех мастеров, именно данный параметр может ограничивать длительность одной транзакции, выполняемой мастером.

Посмотрите главы PCI22: "3.5.4.1. Bandwidth and Latency Considerations" и "6.2.4. Miscellaneous Registers".

Насколько я понимаю стандарт:

Latency Timer - максимальное время транзакции для данного мастера. Может программироваться.

MIN_GNT - прописывается readonly в Config Space мастера - это минимальное время, на которое арбитр должен предоставлять шину данному мастеру. Например Вам надо передавать пачками минимум по четыре слова (типа строка кеша заполняется), по три уже - никак - то и прописываете, что надо получить шину минимум на время для передачи четырех слов (тактовую полагаем 33 МГц).

MAX_LAT - прописывается readonly в Config Space мастера - максимальное время которое арбитр может "не пускать" мастера к шине. Например, с "пользовательского конца" устройства прилетают данные, устройство должно их записать в системную память - запрашивает шину PCI у арбитра, ему пока не дают, а данные пользователя продолжают приходить. Ну, ясно - надо класть в буфер, но он же не бесконечный. То есть, время в течение которого должны выдать шину ограничено, иначе в устройстве пропадут данные. Вот MAX_LAT и вводит это ограничение, которое в идеале должно использоваться при конфигурировании арбитра.

[serg_Fry 0]

читая регистры конфигурационного пространства своего и прочих устройств я пришел к выводу, что моя материнка игнорирует все мои MIN_GNT и MAX_LAT и жестко всем выдает одинаковое значение layency timer=20

И это значение не меняется ни при изменении кол-ва мастеров на шине, ни при изменении нагрузки со стороны мастеров.

Вероятно это все и объясняет: производители конроллеров PCI ограничиваются констанстой для layency timer'а (которую иногда позволяют менять в биосе)

[MarkOne 0]

Да ...

и материнка A8N на чипсете nForce4 - это образец политики производителя, сознательно исключившего, из настроек PCI контролера на этом семействе плат, возможность подстройки параметра "PciLatencyTimer"

 

что автоматически исключает возможность для пользователя устанавливать на эти материнки TV PCI и DVB PCI платы, требующие подстройки этого параметра ...

 

хочешь, не хочешь - а покупай все "новые" девайсы

[vladec 9]

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

[serg_Fry 0]

Я позже разобрался в проблеме прерываний: некорректно переводил буферы устройства со входа на выход(мастер-таргет)

Сделал следующим образом: устройство переводит буферы в режим мастера только когда получает #GNT, таким образом исключается вероятность обращения к таргету во время работы мастера (те самые 1-и, которые возвращала ф-я чтения порта обработчика прерывания).