Оборудование GPIO watchdog в ядре linux ... Autorun

Question

Просто столкнулся с интересным случаем использования аппаратного GPIO сторожевого таймера. Я генерирую 5Hz сигнал (меандр) для внешнего управления системой с помощью gpio watchdog. Чтобы он работал, я пишу некоторые данные в файл/dev/watchdog1 каждые 30 секунд. Наша конфигурация - 60 секунд для сторожевого таймера, после которого сигнал будет остановлен. Итак, все в порядке, но система работает медленно, и пользовательское приложение готово только через ~ 40 секунд после запуска. Однако сторожевой драйвер готов уже через 5 секунд. Для всей системы этот сигнал должен появиться после запуска как можно скорее.

Итак, я бы хотел, чтобы драйвер сторожевого таймера запускал gpio-сигнал, как только функция func вызывалась, а затем у нас есть ~ 60 секунд, чтобы взять управление из пользовательского приложения (начните писать smth в/dev/watchdog1).

Вопрос: Правильно ли менять сторожевой драйвер, чтобы запустить его непосредственно из функции func? Или, может быть, есть какой-то трюк для запуска gpio watchdog хотя бы один раз, прямо из драйвера? Или, возможно, есть еще одно решение этой проблемы ...

P.S. Я использую CONFIG_GPIO_WATCHDOG

Answer 1

Я решил аналогичную проблему в прошлом, обслуживая сторожевой таймер в загрузчике.

Мы использовали U-Boot, у которого в его источнике есть сторожевые крючки (в частности, его источник декомпрессии ядра uImage). Это означало, что мы могли бы подключить некоторый дополнительный код для обслуживания сторожевого таймера, пока изображение ядра распаковывалось, когда ни ядро, ни драйверы не были загружены.

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