Нам нужно поговорить про Linux IIO

[monah_tuk]

IIO это очень хорошо, но существует ли способ эту инфраструктуру использовать внутри ядра?

Я столкнулся с тем, что доступ к Xilinx AMS представлен в виде драйвера IIO, из пользовательского пространства проблем нет, можно запросить температуру ядра, температуру PL. У меня же была задача контроля оборотов вентилятора, в PL был добавлен таймер, который умеет в PWM. Нужно, по сути, было написать платформенный драйвер, который мониторит температуру, и уже по какому-то алгоритму регулирует PWM. Так вот, драйвер вроде есть, для получения данных о температуре, но как к нему достучаться из ядра — хз. Сейчас это сделано сервисом в user-space, под контролем svc.

[MinimumLaw]

Подождите… Что-то мне подсказывает, что вашего слона надо есть частями. Я, правда, сразу предупрежу — у меня с Xilinx не очень… Но все же — вопрос первый он простой. А зачем брать в ядро, то что вполне накрывается userspace демоном? В этом есть какой-то потаенный смыл (кроме явного переусложнения системы и ее обслуживания)? Второй: а в чем проблема внутриядерной коммуникации? В крайнем случае По моим мироощущениям IIO всегда можно заменить на HWMON и THERMAL DEVICE (он, к слову, лучше подходит по духу для температуры ядра и PLL и умеет управлять устройствами).

[monah_tuk]

Начну с конца: уже есть драйвер IIO от Xilinx. Точнее так, есть AMS блок через него много чего прочитать можно и Xilinx для всего этого богатства сделал драйвер, IIO драйвер. Потому и был направлен взор на него.

THERMAL DEVICE

Собственно Thermal device framework и хотелось изначально использовать, подсунув ему каким-то образом данные от уже существующего сенсора, описав всё это дело через DT. Пока я вижу только вариант со своими мини-драйвером, который сможет загрузиться после инициализации AMS драйвера (что бы IOMEMORY ресурсы смогли зашарить) и вычитывать только нужную информацию

А зачем брать в ядро, то что вполне накрывается userspace демоном? В этом есть какой-то потаенный смыл (кроме явного переусложнения системы и ее обслуживания)?

Выше написал уже про Thermal device. Собственно потому и брать. Потому как DT и ядро для нашего устройства контролируются командой приближенной к железячникам, а демон пользовательского пространства могут позабыть включить (user-space под другой командой, собранное ядро, dt и модули мы им даём).

Кроме того, были следующие факторы:

1. сомнения в надёжности схемы с пользовательским демоном: его может OOM отстрелить, к примеру, или если система уйдёт в IO wait. Можно поиграться с ionice и приоритетами конечно.
2. есть неприятный опыт работы по I2C из пользовательского пространства, тут не тот случай (весь доступ через IOMEM), но осадочек остался.

В любом случае сейчас это демон в пользовательском пространстве :)

[MinimumLaw]

Я не представляю объем работ. Но идеологически правильнее выкинуть IIO и перейти на Thermal. Благо Linux, благо OpenSource. В простейшем случае есть EXPORT_SYMBOL. Эта штука специально сделана для обеспечения межмодульной связи. Можно экспортировать данные и получить их в модуле Thermal. Но, откровенное говоря, это костыль. Для проекта пойдет, но шансов попасть в mainline ноль.

[monah_tuk]

Про mainline речи не идёт. У меня ощущения, что другие решения используют внешний сенсор и не парятся. Просто взыграл праздный интерес: есть подсистема, есть драйвер для этой подсистемы, есть полезные мне данные, есть ли возможность дёшево получить эти данные для своих нужд? Судя по всему нет.

[maquefel]

Вот, как то я не подскажу. Документация явно намекает, что можно
https://www.kernel.org/doc/html/latest/driver-api/iio/hw-consumer.html, но сам я такого не делал, поэтому что-либо утверждать не берусь.

[monah_tuk]

Нужно посмотреть. Но похоже нужное нашёл: iio-hwmon и generic-adc-thermal. Нужно будет раскурить.

[Alor]

Вроде fancontrol из lm-sensors есть для такого?

[mrFieldy]

У данного способа много недостатков, я перечислю те которые считаю основными:
1) нет прерываний

…

Собственно IIO даёт нам во-первых универсальность, во-вторых возможность poll по поступлению новых данных.

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

[monah_tuk]

Ты про сам sdpidev или i2c-n? Там вроде нет прерываний, если чип висит на шине, пусть I2C, от него может идти нога прерывания на GPIO. Если gpiochip есть и можно получить нужный GPIO, то вполне poll'ом можно организовать прерывание. Но блин, как это неудобно и гиморно (прошёл через это управляя ITE IT6663 из user-space, в результате написал драйвер).

Другое дело, что активное дёргание шины I2C из user-space очень мешает устройствам другим: шина может вернуть EBUSY, а как оказалось, мало кто это обрабатывает корректно :-\ Ну и реакция на прерывание очень сильно становится размазанной.

[edo1h]

Все наверняка встречали/пользовались конструкциями типа:

# https://www.kernel.org/doc/Documentation/i2c/dev-interface
open("/dev/i2c-1", O_RDWR);

предлагается вместо этого всё-всё-всё тащить в ядро. ИМХО с текущей архитектурой ядра это «не особо».

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

[MinimumLaw]

В Linux ядро МОДУЛЬНОЕ. Оно не монолит, но и не микроядро. Практически все IIO компоненты могут собираться в виде подгружаемых модулей. Как и USB, как и PCI, и прочие-прочие-прочие. В чем проблема-то? Только в том, что Linux не классическое микроядро? Так есть Hurd и QNX. Они микроядерные.