[Yra 4]

Здравствуйте. Такой вопрос. Есть pci плата, работающая как slave. Необходимо под WinXP написать драйвер для неё, использующий dma. Насколько я понял для такой платы нужно использовать системный контроллер dma. Но прочитав описание в DDK, я не нашёл, как dma контроллеру передать адрес платы откуда забирать данные. Или я что-то не понял фундаментально?

[vshemm 0]

Инициализация дма осуществляется с помощью функции IoGetDmaAdapter. Там же и указываются параметры физического устройства.

В результате получаете структуру DMA_ADAPTER, в которой, есть структура DMA_OPERATIONS с указателями на функции для работы с дма.

В частности, AllocateCommonBuffer выделяет нужную память (в первом 16Мб, физ. непрерывную и пр.), MapTransfer стартует дма и т.д.

 

http://msdn.microsoft.com/en-us/library/ms806363.aspx

[Yra 4]

В функцию IoGetDmaAdapter передается 3 параметра:

-указатель на DeviceObject там адрес платы не указывается

-Количество Map регистров это тоже не то

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

 

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

[vshemm 0]

Стандартному (8237 который) контроллеру нужно задавать только адрес буфера в памяти, а адресация устройства - географическая, т.е. не по адресу порта, а по номеру канала. Устройство должно быть настроено для работы с нужным каналом, естесственно.

 

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

[zltigo 0]

Насколько я понял для такой платы нужно использовать системный контроллер dma.

Это не контроллер, это отрыжка со старых времен. Считайте, что DMA у Вас нет :(.

[xvr 12]

Здравствуйте. Такой вопрос. Есть pci плата, работающая как slave. Необходимо под WinXP написать драйвер для неё, использующий dma. Насколько я понял для такой платы нужно использовать системный контроллер dma. Но прочитав описание в DDK, я не нашёл, как dma контроллеру передать адрес платы откуда забирать данные. Или я что-то не понял фундаментально?

Стандартный DMA (8237) не умеет пересылать память->память :( Так что можете расслабится - не получится :crying:

[WitFed 1]

Народ, за 15 лет произошли какие-то сдвиги ?

Появилось системное средство, чтобы без самописного DMA что-то быстро (burst-) писать/читать в PCIe ?

[makc 192]

1 минуту назад, WitFed сказал:

Народ, за 15 лет произошли какие-то сдвиги ?

Появилось системное средство, чтобы без самописного DMA что-то быстро (burst-) писать/читать в PCIe ?

Нет, на сколько мне известно. Каждое устройство делает своё DMA для себя.
Универсального варианта для платформы x86 не завезли по всей видимостью за ненадобностью, т.к. кому оно нужно - тот уже сам давно его для себя реализовал.

[WitFed 1]

Обидно. Всем нужно, у всех есть, и никто не хочет "вынести за скобки" или поделиться.

Видеокарты ведь качают большие объёмы данных к себе и обратно, как GPU.

Это тоже всё изнутри делается, а не снаружи, от CPU, только по его командам ?

И никакого API не экспортируется для любой пары физических адресов ?

[makc 192]

25 минут назад, WitFed сказал:

Обидно. Всем нужно, у всех есть, и никто не хочет "вынести за скобки" или поделиться.

Был бы платежеспособный спрос - сделали бы давно. Но его нет и никто не хочет делать за бесплатно.

26 минут назад, WitFed сказал:

Видеокарты ведь качают большие объёмы данных к себе и обратно, как GPU.

Это тоже всё изнутри делается, а не снаружи, от CPU, только по его командам ?

Видеокарты работают в режиме master на шине PCIe, но дескрипторы для передачи (откуда брать, куда класть) даёт драйвер (CPU). Точно так же работают все сетевые карты, дисковые контроллеры, USB хосты и т.д.

27 минут назад, WitFed сказал:

И никакого API не экспортируется для любой пары физических адресов ?

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

[WitFed 1]

К конкретному устройству привязываться неправильно, даже если его и расковырять, нужен стандартный метод.

В книге "Михаил Гук. Интерфейсы ПК" в разделе "6.2.5. Пропускная способность шины" про PCI говорится, что:

> при записи массива данных в устройство PCI (передача с последовательно нарастающим адресом) мост может пытаться организовать пакетные циклы.

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

Если использовать "REP MOVSD", где счётчик повторений известен, то современный процессор порождает burst операцию, кто-то пробовал ?

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

[makc 192]

16 минут назад, WitFed сказал:

Если использовать "REP MOVSD", где счётчик повторений известен, то современный процессор порождает burst операцию, кто-то пробовал ?

Нет, не порождает. Для получения burst'ов приходится использовать команды с длинными регистрами MMX/SSE/AVX, которые могут записать по адресу в память за раз больше 4 или 8 байт данных. Но это кривой костыль, который требует определённых возможностей от процессора и всё равно не позволяет получить максимальную скорость обмена по шине.

18 минут назад, WitFed сказал:

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

Да, но это так не работает. Для процессора это просто повторение MOV для DWORD в цикле. 😞

[Flood 12]

On 11/27/2023 at 12:48 PM, WitFed said:

Обидно. Всем нужно, у всех есть, и никто не хочет "вынести за скобки" или поделиться.

Если речь о ПЛИС, то многие производители делятся бесплатными вариантами реализации для своих платформ. У AMD/Xilinx вообще целая жизнь вокруг DMA-контроллеров выстроена - есть и драйверы, и сами ядра - только бери. И сами они в своих "готовых" продуктах используют те же самые решения. Правда, все максимально заточено под Linux.

[makc 192]

6 минут назад, Flood сказал:

Если речь о ПЛИС, то многие производители делятся бесплатными вариантами реализации для своих платформ. У AMD/Xilinx вообще целая жизнь вокруг DMA-контроллеров выстроена - есть и драйверы, и сами ядра - только бери. И сами они в своих "готовых" продуктах используют те же самые решения. Правда, все максимально заточено под Linux.

Опять же нужна отдельная плата с ПЛИС, которая имея на борту PCIe не будет дешёвой. Поэтому и был вопрос: можно ли добиться такого эффекта (а-ля DMA) чисто системными средствами.

[WitFed 1]

Да, для ПЛИС меня это и интересует, уже сколько лет мучаемся с тормозными разовыми обращениями.
По 8, 16 байт оно, конечно, немного быстрее. Но "продвинутые" мосты пока не попадались, чтобы совсем до кучи слепить хотя бы запись.
Она же эффективнее, чем чтение из самого устройства. В инете гуглилось, что в GPU данные закачиваются медленнее, чем выгружаются обратно, это лишнее подтверждение, что там на борту тоже своё DMA.
Реализация DMA в плате у нас в конце концов и делается, но это криво, с моей точки зрения.
Какие могут быть разумные аргументы для отсутствия в архитектуре Intel прямого DMA для любых пересылок, и в первую очередь -- записи наружу ?
Пнул и отвлёкся, ещё кого-то стартовал через FIFO запросов большой глубины, занимаешься другими добрыми делами, а потом как-то узнал, что всё закончилось.. Это же очень удобно.
В https://electronix.ru/forum/topic/174010-api-dlya-bystrogo-kopirovaniya-bolshih-obyomov-dannyh-v-ustroystvo-dma/ я спрашивал -- там знатоки молчат.
В книге Guk-M.-Entsiklopediya.-SHiny-PCI-USB-i-FireWire-2005.pdf прямо сказано:

Quote

На шине PCI все транзакции трактуются как пакетные: каждая транзакция начинается фазой адреса, за которой может следовать одна или несколько фаз данных. Количество фаз данных в пакете явно не указывается, но в такте последней фазы данных ведущее устройство при введенном сигнале IRDY# снимает сигнал FRAME#. В одиночных транзакциях сигнал FRAME# активен лишь в течение одного такта. Если устройство не поддерживает пакетные транзакции в ведомом режиме, то оно должно потребовать прекращения пакетной транзакции в течение первой фазы данных (выставив сигнал STOP# одновременно с TRDY#).

Т.е. мы в устройстве на чтении даже не знаем, какая будет длина транзакции, открываем страницу и читаем сразу большой кусок памяти, а начинаем отдавать -- и после первого обмена облом.
Похоже, это только со стороны Intel осмысленная недоработка, которую легко исправить, учитывая обычную сверхсложность решений этой фирмы, просто ещё добавить арифметики в реализацию REP MOVS*.
Мы же знаем сразу, какой объём последовательных данных предстоит передать, и по аналогии с обращением через SSE/AVX регистры можем подать в PCI запрос W/R именно на этот размер.
Доброе дело тормозится по политическим причинам, как обычно ? А другие архитектуры бывают посолиднее ?
В PCI Express тоже всё нормально в архитектуре заложено, там копия PCI, для совместимости.
Большим пакетом можно всё сложить и послать при записи REP MOVS*, а на чтении -- один пакет запроса с общей длиной и обоими адресами.
Или как ?