Примечание: многое из этого предваряется моими главными комментариями, поэтому я постараюсь не повторять их дословно.

О буферах для DMA, доступа к ядру и доступа к пользовательскому пространству. Буферы могут быть выделены любым подходящим механизмом.

Как уже упоминалось, используя mem=512M и /dev/mem с mmap в пользовательском пространстве, драйвер mem может не задавать оптимальную политику кэширования. Кроме того, mem=512M обычно используется для указания ядру просто никогда не использовать память (например, мы хотим тест с меньшим объемом системной памяти), и мы не собираемся использовать верхний 512M для чего-либо.

Лучший способ может оставить mem=512M и использовать CMA, Как вы упомянули. Другой способ может заключаться в привязке драйвера к ядру и резервировании полного блока памяти во время запуска системы [возможно, с помощью CMA].

Область памяти может быть выбрана с помощью параметров командной строки ядра [из grub.cfg], таких как mydev.area= и mydev.size=. Это полезно для" связанного " водителя, который должен знать эти значения на "ранних" этапах запуска системы. Итак, теперь у нас есть "большая" область. Теперь нам нужно иметь способ для устройства, чтобы получить доступ и приложение, чтобы получить его сопоставление. Драйвер ядра может сделать это. Когда устройство открыто, ioctl может настроить сопоставления с правильной политикой ядра. Таким образом, в зависимости от механизма распределения, ioctl может быть дано address/length приложением, или оно может передать их обратно приложению [соответствующим образом отображенный]. Когда мне пришлось это сделать, я создал структуру, которая описывала область памяти/буфер. Это может быть целая область или большая область может быть разделена по мере необходимости. Вместо использования динамической схемы переменной длины, эквивалентной malloc [как то, что вы писали], я обнаружил, что субпулы фиксированного размера работают лучше. В ядре это называется распределителем "сляба". Структура имела "идентификационный" номер для данной области. Он также имел три адреса: адрес приложение может использовать, адрес драйвер ядра может использовать, и адрес, который будет дан H / W устройству. Кроме того, в случае нескольких устройств он может иметь идентификатор, с которым он в данный момент связан. Итак, вы берете большую область и подразделяете ее вот так. 5 устройств. Dev0 нужно 10 1K буферов, Dev1 нужно 10 20k буферов, Dev3 нужно 10 2K буферов, ...

Приложение и драйвер ядра будут хранить списки этих структур дескрипторов. Приложение запустило бы DMA с другим ioctl для этого потребуется идентификационный номер дескриптора. Повторите это для всех устройств.

Затем приложение может выдать ioctl, которое ожидает завершения. Драйвер заполняет дескриптор только что завершенной операции. Приложение обрабатывает данные и циклы. Он делает это "на месте" - см.

Вы беспокоитесь о том, что скорость будет медленной. Как мы уже обсуждали, это может быть связано с тем, как вы использовали mmap на /dev/mem.

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

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

Наугад, прямо сейчас, у вас есть ваш memcpy "гонки" против устройства. То есть, вы должны скопировать данные быстро, так что вы можете запустить следующий DMA без потери каких-либо данных.

"большая" область должна быть разделена [как упоминалось выше], и драйвер ядра должен знать о разделах. Итак, драйвер начинает DMA с id 0. Когда это завершается, он немедленно [в ISR] запускает DMA к id 1. Когда это завершается, он переходит к следующему в своем субпуле. Это можно сделать аналогичным образом для каждого устройства. Приложение может опрос для завершения с помощью ioctl

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

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

В моем конкретном случае, в rev 1 из H/W регистры DMA были не дважды буферизованы.

Таким образом, после запуска DMA в буфере 0 драйвер должен был дождаться прерывания завершения для буфера 0, прежде чем настроить регистры DMA для следующей передачи в буфер 1. Таким образом, водитель должен был "мчаться", чтобы сделать настройку для следующего DMA [и имел очень короткое окно времени, чтобы сделать это]. После запуска буфера 0, если бы драйвер изменил регистры DMA на устройстве, это нарушило бы уже активный буфер. запрос.

Мы исправили это в rev 2 с двойной буферизацией. Когда драйвер настроит DMA regs, он ударит по порту" пуск". Все порты DMA были немедленно защелкнуты устройством. В этот момент драйвер был свободен выполнить полную настройку буфера 1, и устройство автоматически переключится на него [без вмешательства драйвера], когда буфер 0 будет завершен. Драйвер получит прерывание, но может занять почти все время передачи, чтобы настроить следующий запрос.

Итак, с системой стилей rev 1 подход uio мог бы не работать-это было бы слишком медленно. С rev 2, uio возможно, но я не фанат, даже если это возможно.

Примечание: в моем случае мы сделали не использовать read(2) или write(2) к устройству чтения/записи обратных вызовов вообще. Все обрабатывалось с помощью специальных вызовов ioctl, которые принимали различные структуры, подобные упомянутой выше. В какой-то момент на ранней стадии мы действительно использовали чтение / запись таким образом аналогично тому, как их использует uio. Но мы обнаружили, что отображение является искусственным и ограниченным [и хлопотным], поэтому мы перешли к подходу "только ioctl".

Более того, каковы требования? Количество передаваемых данных в секунду. Количество устройств, которые делают что? Являются ли они все входными или есть и выходные?

В моем случае [который делал R/T обработку широковещательного качества hidef H. 264 video], мы смогли сделать обработку в драйвере и пространство приложения, а также пользовательская логика FPGA. Но мы использовали полный подход [не uio] драйвера, хотя, архитектурно это выглядело как uio в некоторых местах.

У нас были жесткие требования к надежности, предсказуемости R/T, гарантированной задержке. Нам пришлось обработать видео 60 кадров / секунду. Если мы сбегали, хотя бы на долю секунды, наши клиенты начинали кричать. uio не смог бы сделать этого для нас. Итак, вы начали с простого подхода. Но я могу сделать шаг назад. и посмотрите на требования, возможности устройства / ограничения, альтернативные способы получения непрерывных буферов, пропускную способность R/T и задержку, а также переоцените вещи. Действительно ли ваше текущее решение удовлетворяет все потребности? В настоящее время вы уже сталкиваетесь с горячими точками [гонки данных между приложением и устройством] и/или ограничениями. Или, может быть, вам будет лучше с родным водителем, который дает вам больше гибкости (т. е. может быть еще неизвестный, который заставит родного водителя).

Вероятно, Ксилинкс предоставляет подходящий скелет полный драйвер в их SDK, который вы могли бы взломать довольно быстро.