Всем доброго времени суток!

Имеется плата с ARM, АЦП и ДСП на борту. При получении данных от АЦП вырабатывается аппаратное прерывание, по которому нужно передать данные в ДСП, как это реализовать?

Первое что приходит голову, написать общий драйвер АЦП-ДСП, и в обработчике прерывания «отправить» данные.
Однако, хочется, чтобы драйвера были независимые, тогда, получается нужен посредник, например демон, который будет передавать данные из одного драйвера в другой, но не пойму как ему сообщить о готовности данных. Думаю использовать raise_softirq в драйвере АЦП, а в демоне сделать его обработчик(open_softirq), но чувствую open_softirq работает только в пространстве ядра.

Подскажите, как обычно решают такую задачу, заранее спасибо.

Ваше описание слишком запутано, чтоб можно было давать какой-то определённый совет. Ну, по крайней мере мне ничего не понятно. Куда подключен АЦП? Где выхотите получить данные от него? При чём здесь ARM? Попробуйте более чётко описать задачу и, возможно, тогда быстрее получите ответ.

Наиболее распространённым способом отложенной обработки прерываний являются тасклеты(tasklet), но, опять же, из описания задачи не понятно какой из этих механизмов будет удобнее. В одном Вы правы - это механизм пространства ядра. Если нужно получить данные в пространстве пользователя, то придётся дополнительно подумать и над этим.

АЦП подключён к процессору(ARM), через специальный интерфейс uPP(Universal Parallel Port), который оснащён ПДП, т. е. данные АЦП автоматически копируются в ОЗУ, после чего выдаётся прерывание. В одном чипе(OMAP-L138) с ARM находится ДСП, которому нужно сообщить, что данные готовы и по какому адресу можно их забрать.

Соответственно, пишу драйвера для ДСП и АЦП. Вопрос как передать данные из драйвера АЦП драйверу ДСП, при условии что они независимы, и друг о друге не знают, т. е. из драйвера АЦП нельзя напрямую использовать функции, файлы ДСП.

Если коротко, то вопрос следующий: как драйвер сигнализирует приложению пользователя, что есть данные для обработки?
Например в Windows при работе с камерой передавал драйверу указатель на callback-функцию, которая вызывалась каждый кадр.

Мне кажется, что в данном случае удобнее воспользоваться сигналами из драйвера. Вот тут показан примерный сценарий использования:
http://www.friendlyarm.net/forum/topic/893
Заодно посмотрите обзорную статью о доступных механизмах взаимодействия с пространством пользователя:
http://wiki.tldp.org/static/kernel_user_space_howto.html
Может быть найдёте что-то более подходящее.

А ARM на этой платформе не имеет доступа к адресному пространству DSP? Было бы логично напрямую писать данные в его память, минуя лишнее копирование в пространство пользователя, и потом запускать обработку.

У них почти все ресурсы общие, в частности ОЗУ. В пространстве пользователя будет работать демон, ждущий, когда появятся данные АЦП, после чего он запросит физический адрес и размер буфера у драйвера АЦП, и передаст их драйверу ДСП, ну а последний уже передаст указатель на обработку в сам ДСП, т.е копирования не происходит.

Как вариант, без промежуточного звена в виде демона, надумал воспользоваться softirq. В драйвере АЦП - вызов, а в ДСП - обработка. Номер отложенного прерывания будет задаваться драйверам при загрузке. Но не представляю как в обработчик передать адрес и размер буфера.

Поэтому пока буду делать через «демон», спасибо за наводку на сигналы.

Демоны в ядре не живут. Живут потоки (threads).

Посмотрите на notifier chain facility. Возможно это то, что вам надо.
https://people.cs.clemson.edu/~westall/853/...es/notifier.pdf

http://www.linuxjournal.com/article/8144

Вот здесь в конце описаны типичные ошибки при переключении потока в ожидание:
https://whatilearned2day.wordpress.com/2006...kernel-threads/

Mistakes that I made and rectified to make it work (..arrgh confessions are painful !)

> used schedule() without changing the task state, task state remained TASK_RUNNING and hence the thread got scheduled again.

> did not wak up the process and hence threads did not get rescheduled, leading to output only upto the counter 10 for both the threads.

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

Избыточность пофиг, но там в приведенных ссылках есть еще два механизма waiting queues и усыпление/пробуждение потоков. Любой из методов вам подойдет. Последний самый простой.