Всем привет.

Долго рылся в интернете и здесь, но то ли гугл забанил, то ли реально инфа где-то глубоко зарыта - я так ни чего и не нашёл по своей проблеме : \

Есть свой девайс с процом OMAP 3530 (ARM V7), к одному из его GPIO пинов подключен сенсор. Сенсор запускается, почуяв уровень на своём пине.

Задача №1 - включать из драйвера сенсор, устанавливая на GPIO ножке логическую единицу. Эта задача практически выполнена, сенсор включается.

Задача №2 - сделать всё это более детерминированным, то есть после вызова gpio_set_value(...) необходимо _подождать_ когда _реально_ на GPIO пине изменится это значение, ну или точнее когда _реально_ GPIO контроллер попытается его изменить (придёт ему эта команда).

На blackfin процах юзал ssync инструкцию. А вот что в моём нынешнем случае посоветуете? Поидее всё должно быть в даташите к процессору, но каюсь - не нашёл : \

Всем привет.

Есть проблема с девайсом, который я собрал на основе Gumstix микрокомпьютера. Сделал борд с smc911x сетевым чипом и активным Ethernet портом, всё сразу завелось, Angstrom linux загрузился, сеть поднялась. Если ничего не делая отключать/подключать сетевой кабель к девайсу, то он подхватывается каждый раз отлично, но стОит заюзать его в моей программе (небольшой сервер на tcp соккетах) и переподключение кабеля уже не работает, т.е. линукс не видит сеть + собсно сами светодиоды на ethernet разъёме не загораются сразу, а лишь по прошествии длительного времени (несолько часов ожидания) или после ребута.

Алгоритм действий проявления бага: включаю девайс с сетью, включаю серверное приложение, отсоединяю кабель, отключаю/не отключаю серверное приложение, вставляю сетевой кабель обратно, сеть не заводится.

Сначала после завершения серверного приложения я наблюдал висящие соккеты на TIME_WAIT, после чего сконфигурил до старта сервера систему так:

echo 4 > /proc/sys/net/ipv4/tcp_fin_timeout

echo 1 > /proc/sys/net/ipv4/tcp_orphan_retries

echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle

echo 2 > /proc/sys/net/ipv4/tcp_keepalive_time

echo 1 > /proc/sys/net/ipv4/tcp_keepalive_intvl

echo 2 > /proc/sys/net/ipv4/tcp_keepalive_probes

соккеты стали почти сразу удаляться, но это никак не решило проблему - сеть заводится только после перезагрузки или очень долгого простоя. Не верится, что это хардварный баг ибо схемотехника - копия с рабочего борда для Gumstix-а, с тем же контроллером и т.п. + сеть же работает и переподключается, если не юзать TCP.

Есть какие-нибудь мысли по это теме?

Пробовал перезапускать сеть в системе - не помогло ( system(«/etc/init.d/networking restart»);

пробовал только eth0 перезапускаь - и это не помогло.

Всем привет.

Написал драйвера девайсов, сделал автоматическую загрузку при старте системы.

После её окончательной загрузки запускается постоянно крутящееся юзермодное приложение. Ему перед стартом необходимо узнать - загрузились ли дрова? (например драйвер сенсора камеры не грузится если сенсор не найден, т.е. возвращает код ошибки).

Вот и вопрос - как проверить из C кода? Сразу оговорюсь - познания линукса весьма скромные, посему не судите строго.

Так вот, пока идея только через system вызов lsmod-а получить список дров и тупо пробежаться по нему сверяя имя. Как вариант, да. А если ли более идеологически верный? Например нормальная функция доступная в С, возвращающая этот список или функция, проверяющая на загруженность указанный драйвер?

Спасибо.

Всем привет.

Пишу драйвер, так вышло, что в нём необходимо организовать простые TCP серверы для закидывания конфигурации драйвера в рантайме по сети. Да, именно в драйвере это надо делать, есть различные причины для этого, выбор сделан и пересмотру не подлежит.

Итак, в драйвере создаются 4 инстанса «сервера» - каждый на свой порт и для них отдельный поток, проверяющий входящие соединения на соккетах раз в 500 мс.

Ещё есть в драйвере основной поток, в котором производится некая обработка данных (позднее он будет выпилен и обработка будет сделано по прерыванию на GPIO но сейчас именно так).

Оба потока создаются так:

kthread_run( thread_func, thread_param, thread_name);

Потоки отлично создаются и работают за исключением 1 момента! Они работают не параллельно а «последовательно». 1-2 секунды на поток! Сначала один поток работает 1-2 секунды а второй «спит», потом первый «засыпает» а второй начинает работать так же 1-2 секунды.

Такая работа не преемлима. Вопрос в том - как заставить их работать «параллельно». Никогда с таким не сталкивался (раньше на Windоws работал), идей нет и гугл не помог.

Буду признателен за помощь.

p.s. юзаю OE Linux, ядро 3.2.0 (собирал всё сам), проц OMAP3530

Всем привет.

Разрабатываю железку, которую планируется массово продавать. В первый раз имею дело с Linux и его драйверами : ) Посему не судите строго за, возможно, нубские вопросы. Тему предварителько пытался понять из гуглопоиска, но что-то вот не понял ничего из прочитанного. Везде по-разному пишут.

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

И тут встаёт вопрос - как лицензировать драйвер? В нём используются функции, экспортируемые ядром через EXPORT_SYMBOL_GPL (например platform_device_register), которые, как я понял, могут использоваться _только_ GPL драйверами.

Собственно, как обычно делается в таких случаях? Как, например, NVIDIA разрабатывает свои проприетарные драйвера?

Можно ли сделать какой-то GPL загрузчик нашего основного проприетарного модуля? Или какие вообще есть варианты?

Заранее большое спасибо.