Comments 12
IIO это очень хорошо, но существует ли способ эту инфраструктуру использовать внутри ядра?
Я столкнулся с тем, что доступ к Xilinx AMS представлен в виде драйвера IIO, из пользовательского пространства проблем нет, можно запросить температуру ядра, температуру PL. У меня же была задача контроля оборотов вентилятора, в PL был добавлен таймер, который умеет в PWM. Нужно, по сути, было написать платформенный драйвер, который мониторит температуру, и уже по какому-то алгоритму регулирует PWM. Так вот, драйвер вроде есть, для получения данных о температуре, но как к нему достучаться из ядра — хз. Сейчас это сделано сервисом в user-space, под контролем svc.
Начну с конца: уже есть драйвер IIO от Xilinx. Точнее так, есть AMS блок через него много чего прочитать можно и Xilinx для всего этого богатства сделал драйвер, IIO драйвер. Потому и был направлен взор на него.
THERMAL DEVICE
Собственно Thermal device framework и хотелось изначально использовать, подсунув ему каким-то образом данные от уже существующего сенсора, описав всё это дело через DT. Пока я вижу только вариант со своими мини-драйвером, который сможет загрузиться после инициализации AMS драйвера (что бы IOMEMORY ресурсы смогли зашарить) и вычитывать только нужную информацию
А зачем брать в ядро, то что вполне накрывается userspace демоном? В этом есть какой-то потаенный смыл (кроме явного переусложнения системы и ее обслуживания)?
Выше написал уже про Thermal device. Собственно потому и брать. Потому как DT и ядро для нашего устройства контролируются командой приближенной к железячникам, а демон пользовательского пространства могут позабыть включить (user-space под другой командой, собранное ядро, dt и модули мы им даём).
Кроме того, были следующие факторы:
- сомнения в надёжности схемы с пользовательским демоном: его может OOM отстрелить, к примеру, или если система уйдёт в IO wait. Можно поиграться с ionice и приоритетами конечно.
- есть неприятный опыт работы по I2C из пользовательского пространства, тут не тот случай (весь доступ через IOMEM), но осадочек остался.
В любом случае сейчас это демон в пользовательском пространстве :)
Вот, как то я не подскажу. Документация явно намекает, что можно
https://www.kernel.org/doc/html/latest/driver-api/iio/hw-consumer.html, но сам я такого не делал, поэтому что-либо утверждать не берусь.
Вроде fancontrol из lm-sensors есть для такого?
У данного способа много недостатков, я перечислю те которые считаю основными:
1) нет прерываний
…
Собственно IIO даёт нам во-первых универсальность, во-вторых возможность poll по поступлению новых данных.
Прерывания там есть. Там всегда есть возможность получить дескриптор файла, который будет отвечает за поступления новых данных и повесить на него тот-же poll.
Ты про сам sdpidev или i2c-n? Там вроде нет прерываний, если чип висит на шине, пусть I2C, от него может идти нога прерывания на GPIO. Если gpiochip есть и можно получить нужный GPIO, то вполне poll'ом можно организовать прерывание. Но блин, как это неудобно и гиморно (прошёл через это управляя ITE IT6663 из user-space, в результате написал драйвер).
Другое дело, что активное дёргание шины I2C из user-space очень мешает устройствам другим: шина может вернуть EBUSY, а как оказалось, мало кто это обрабатывает корректно :-\ Ну и реакция на прерывание очень сильно становится размазанной.
Все наверняка встречали/пользовались конструкциями типа:
# https://www.kernel.org/doc/Documentation/i2c/dev-interface open("/dev/i2c-1", O_RDWR);
предлагается вместо этого всё-всё-всё тащить в ядро. ИМХО с текущей архитектурой ядра это «не особо».
правильнее было бы сделать в этой части что-то вроде микроядерной ахитектуры, когда не критичные к производительности драйвера вынесены в userspace.
сделали же fuse, и активно используется, надо заметить.
Нам нужно поговорить про Linux IIO