Иногда лучше молчать



Ваша нелюбовь ко всему что связано с linux мне известна, но иногда раскрывайте глаза - легкость написания драйверов никак не связана со скоростью работы устроств. С spi так получилось что атмеловский контроллер не поддерживает CS обоих уровней, что для универсальной ОС как linux неприемлемо, поэтому в угоду универсальности атмеловские драйверы написаны далеко не оптимально с точки зрения скорости. Я бы еще закрыл на это глаза но там не оказалось того функционала который предусмотрен ядром linux а у атмел просто не был реализован.

Работа с периферией в линуксе через самописный драйвер - не такая сложная задача (на уровне принять отправить)

Автору - посмотрите в сторону SMC - широкая (относительно) шина, сигналы управления (RD, WR, CS)... но на ПЛИСине придется реализовывать ФИФО...

а что это за шина? я пока толкового описания о ней найти не могу....

Сообщение отредактировал stas17 - Aug 20 2010, 07:32

SMC - Static Memory Controller
Загляните в даташит

UPD: SMC был на SAM9260... тут другая... EBI однако

У меня тут вопрос возник - как корректно работать с DMA (aka PDC) в юзерспейсе. Ведь DMA требует физический адрес, а в юзерспейсе у нас только виртуальные, да еще принадлежащие контексту конкретного процесса (что значит не в любой момент могут быть физически отображены). Получив буфер от malloc() в юзерспейсе нельзя даже быть уверенным что этот буфер физически непрерывен, а не надерган менеджером памяти из нескольких разнесенных физических страничек В ядре то понятно - получили буфер, конвертнули его в список дескрипторов физических страниц и поехали. Неужто в Линуксе есть API для руления физической памятью из юзерспейса? (Сомнение есть, потому как это хорошая дыра в безопасности)

Честно говоря не могу придумать для чего это все делать в userspace я работал на уровне ядра. Мало того что буфер непрерывный, нужно чтобы еще и память была некешируемая иначе в устройство может улететь совсем не то что хочется

Ясно, значит меня просто ввела в заблуждение Ваша фраза про "юзерспейс не успеет забрать данные".
Про кеш, то понятно. В некоторых процессорах есть очень зачетная фича - поддержка когерентности кеша и памяти - ядро снупит шину и инвалидирует/флашит кеш при необходимости. В тех же MPC83xx от Фрискейла, например, такое сделано.

По моему это стандартная фича всех MMU.
В ARM-ах, естественно, такое тоже есть, но далее нюансы.
Надо ли проходить по всем линиям кэша чтобы их очистить либо только по грязным. Второй метод быстрее но есть не во всех ARM-ах.
Помимо кэширования для DMA важно определенное выравнивание, поэтому просто очистка кэша еще не все.

В 83xx это сделано именно на уровне интерфейса ядра с шиной, про кэш и MMU при разработке программы можно вообще не вспоминать - никаких инструкций инвалидации вызывать не надо. Эта фишка вообще стала только недавно появляться и заточена она не столько под DMA как под многопроцессорные системы. Ядро следит за шиной, и если по ней проходит транзакция записи каким-то другим мастером (не данным ядром) и адрес приемника совпадает с закэшированным, то эта строка кэша автоматом инвалидируется. Если же кто-то хочет читать по шине данные, а они еще не записаны из кэша (Writeback кэш, например), то ядро ставит abort/retry, забирает шину, флашит данные из кэша, и отдает шину обратно. Потом жаждущий данных сторонний мастер делает retry и забирает свеженькую информацию. Не думаю что такое возможно на ARM-ах, сейчас тут писк моды Multilayer Bus Matrix - замучается ядро такое снупить. Хотя, может я и не в курсе - АРМы разные бывают.

P.S. Извините за оффтопик.