Драйвер, написать самому Опции

[Dubov]

Стало необходимо написать свой драйвер SPI устройства. Драйвер для работы из пользовательского пространства не годится, так как данные нужно принимать от АЦП по SPI в DMA буфер непрерывно(пропуски в данных недопускаются) со скоростью 100К семплов в секунду, чего нельзя добится из user space. Из пользовательского пространства я планирую только забирать блоками через драйвер.
Для моей платформы есть файлы для работы с spi в папке /drivers/spi/

Вопрос:
файлы в /drivers/spi - это всё что нужно для написания своего драйвера(модуля ядра)?

Просто ранее я писал только standalone приложения и смущает отсутствие в Linux процедур прямого обращения к регистрам (здесь всё через обёртки какие то мудрёные).
В линукс смущает то что нету так привычных мне *.h файлов где через дефайны описаны адреса всех регистров (по мануалу).

Сообщение отредактировал Dubov - Nov 12 2012, 10:27

[Idle]

Просто ранее я писал только standalone приложения и смущает отсутствие в Linux процедур прямого обращения к регистрам (здесь всё через обёртки какие то мудрёные).

Это не так, именно через прямое обращение к регистрам SoC в адресном пространстве и происходит взаимодействие с железом.

В линукс смущает то что нету так привычных мне *.h файлов где через дефайны описаны адреса всех регистров (по мануалу).

Они как правило есть, но не всегда на _все_ регистры.

Для написания драйвера _устройства_ подключённого через spi слейвом, обращаться напрямую к железу не надо - это делает драйвер spi контроллера (мастера).

[Dubov]

Это не так, именно через прямое обращение к регистрам SoC в адресном пространстве и происходит взаимодействие с железом.


Они как правило есть, но не всегда на _все_ регистры.

Для написания драйвера _устройства_ подключённого через spi слейвом, обращаться напрямую к железу не надо - это делает драйвер spi контроллера (мастера).

так вот этот драйвер мастера, насколько я могу понять, не может складывать данные в буфер произвольной длины, а только работает через read() или write(). Таким образом считать данные из ацп в пространстве пользователя нельзя, точнее можно, но данные будут не нерпрерывные, а спотреями, ввиду латентности операционки.

Выход: написать драйвер "с нуля" на уровне ядра.
как? пока сложно себе представляю... увидеть бы пример работы с SPI через DMA в драйвере.

Сначала ознакомьтесь с принципами функционирования подсистемы SPI в ОС GNU/Linux. Инфа есть в каталоге Documentation/spi исходников ядра или например в книге Essential Linux Device Drivers.
Также для примера можете подсмотреть как соведуют делать для семейства чипов AT91SAM9X link

подсистема iio - мутная вещь. По моему намного проще обращаться к регистрам как в standalone приложении. Как раз для SAM9260 писал именно "напрямую" через SPI DMA, взяв пример кода из проекта плейера (тоже без ос).
Получилось просто и быстро: standalone процедура превратилась в драйвер уровня ядра. Тем более, в книге Linux Device drivers написано что на уровне ядра к регистрам можно обращаться напрямую.

IIO выдумали якобы для унифицирования, но мне показалось там слишком всё усложнено.Тем более из общения с разработчиками драйверов из AD я так и не смог выяснить зачем они написали софтовое тактирование АЦП из юзерспейс. Это же идиотизм: тактировать промышленный АЦП клоком с непредсказуемым джиттером.

Отвлёкся от темы.

[Idle]

так вот этот драйвер мастера, насколько я могу понять, не может складывать данные в буфер произвольной длины, а только работает через read() или write()

а как должно происходить чтение? вот есть, например, spi_w8r16 два байта читает - почему она не подходит?

Сообщение отредактировал Idle - Nov 12 2012, 13:25

[Dubov]

а как должно происходить чтение? вот есть, например, spi_w8r16 два байта читает - почему она не подходит?

Вообще планировалось сделать так:
завести на уровне ядра большущий буфер(около 1 МБ), а чтение происходит в самом драйвере, пусть по 2 байта, но складываться всё должно тоже в буфер на уровне ядра (в тот самый большой буфер).
В приложении же отобразить буфер в юзерспейс и читать указатель, который возвращает драйвер.

Иными словами: User mode SPI device driver support - не подходит.

P.S. Возможно я чего-то не понимаю.

Все реализации что я до этого видел предлагают править файл борды и активировать User mode SPI device driver support. Но это не подходит.

а как должно происходить чтение? вот есть, например, spi_w8r16 два байта читает - почему она не подходит?

и это как я понял, не DMA чтение

[Idle]

Вообще планировалось сделать так:
завести на уровне ядра большущий буфер(около 1 МБ), а чтение происходит в самом драйвере, пусть по 2 байта, но складываться всё должно тоже в буфер на уровне ядра (в тот самый большой буфер).

тогда можно выделить в драйвере буфер, периодически дёргать (через таймер, например) чтение по spi, складывать полученные данные в буфер
создать в драйвере chardev и отдавать буфер при чтении из созданного файла
как такой вариант?

[Dubov]

[quote name='Idle' date='Nov 12 2012, 18:04' post='1110736']
тогда можно выделить в драйвере буфер, периодически дёргать (через таймер, например) чтение по spi, складывать полученные данные в буфер
создать в драйвере chardev и отдавать буфер при чтении из созданного файла
как такой вариант?и(получается никаких spi_write()).
Насколько я понял мне все пытаются объяснить что линукс предоставляет независимость от платформы даже в таких задачах (чтиение зSPI по DMA в модуле ядра).

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

[Idle]

Насколько я понял мне все пытаются объяснить что линукс предоставляет независимость от платформы даже в таких задачах (чтиение зSPI по DMA в модуле ядра).

нет, пишу как я бы это делал

А мне нужно потоковое накопление в буфере и периодическая отдача в юзерспейс.

ну вот и накапливайте в буфере периодически читая при помощи дравера мастера, а в чём разница при чтении из полностю своего кода и при использовании драйвера?


upd
я понял - вы хотите зарядить dma на чтение по spi
тогда линуксовая подсистема spi тут не нужна совсем, смотрите на реализацию мастера для своего SoC и пишите что нужно
работа с регистрами происходит так же как и на bare metal - они в памяти
работа с dma - через линуксовый api, с ним мне работать не приходилось

Сообщение отредактировал Idle - Nov 12 2012, 15:26