Comments 20
Вроде бы казалось сколько уже нажёвано по этой теме, но нет:
Мы не используем sysfs для gpio для новых разработок (и нет это не вкусовщина):
Никто не гарантирует, что нумерация в "/sys/class/gpio/export" останется неизменной даже если мы ничего не меняем в ядре (конифиг, новая версия):
банальный пример - воткнули FTDI конвертер (есть которые с gpio на борту), нумерация съёхала
НЕОБХОДИМО упомянуть, что мы можем присваивать labels для gpiochips, gpiopins в device tree.
Если уж взялись приводить примеры, приведите СОВРЕМEННЫЙ ПРИМЕР, а не раскапывайте легаси наподобии omap.
Любой из:
$ git whatchanged --diff-filter=A --pretty=short origin/master -- drivers/gpio/
commit c4f8457d17ce590c71aef53d75d49c313eb72cbc
Author: Jim Liu <JJLIU0@nuvoton.com>
gpio: nuvoton: Add Nuvoton NPCM sgpio driver
:000000 100644 000000000000 d31788b43abc A drivers/gpio/gpio-npcm-sgpio.c
commit eee636bff0dcb52c39300dd88ff7e8ecaff4492a
Author: Tzuyi Chang <tychang@realtek.com>
gpio: rtd: Add support for Realtek DHC(Digital Home Center) RTD SoCs
:000000 100644 000000000000 a7939bd0aa56 A drivers/gpio/gpio-rtd.c
commit 659ad5f7efece8f92213ca069c494a37507c8c67
Author: Okan Sahin <okan.sahin@analog.com>
gpio: ds4520: Add ADI DS4520 GPIO Expander Support
:000000 100644 000000000000 1903deaef3e9 A drivers/gpio/gpio-ds4520.c
commit cd33f216d241520385a5166ae73a0771197a9f0b
Author: Asmaa Mnebhi <asmaa@nvidia.com>
gpio: mlxbf3: Add gpio driver support
:000000 100644 000000000000 e30cee108986 A drivers/gpio/gpio-mlxbf3.c
commit 57e30e00bd5baacdf99450d69981ec9192592e3c
Author: Jerome Neanne <jneanne@baylibre.com>
gpio: tps65219: add GPIO support for TPS65219 PMIC
:000000 100644 000000000000 7b38aa360112 A drivers/gpio/gpio-tps65219.c
...
И т.д.
static struct platform_driver omap_gpio_driver
Сразу нет.
spin_lock_irqsave(&gpio_lock, flags);
Нет. Смотри cleanup.h
pr_warn("%s: invalid GPIO %ld\n", __func__, gpio);
return -EINVAL;
Нет, смотри dev_err_probe
И т.д.
В качестве примера идеально подошёл бы универсальный https://elixir.bootlin.com/linux/v6.8-rc3/source/drivers/gpio/gpio-mmio.c, функционала которого хватает для большинства gpio драйверов:
```
$ grep -rwn linux/drivers/gpio/ -e bgpio_init | wc -l
56
```
А прерывания можно и отдельно разобрать.
Давайте по порядку.
1) безусловно, использование gpio из userspace - это в принципе не очень хорошая практика, независимо от способа доступа. GPIO должен быть завернут во что-то. gpio-keys, gpio-leds, что-то более другое.
2) да, вероятно, брать старые железки со старыми ядрами - не самый оптимальный вариант, и современный код изучать правильнее. Спасибо за ссылки, это полезная информация. Тем не менее, есть множество массово производимых и разрабатываемых устройств, где используются ядра 4.x и 5.x, где используется вендорский sdk именно с таким кодом, или около того.
Поэтому, вероятно, для авторов новых драйверов эта статья - пример того, как не надо делать. А вот для тех, кто применяет существующее - вполне может быть полезно.
3) Не совсем понял, что значит "сразу нет", применительно к процитированным участкам кода.
4) вы даете, безусловно, полезную информацию и комментарий очень по делу. Действительно ли присутствует необходимость делать это таким тоном, как будто я за последние три недели лично вам до смерти надоел, или это случайный огрех формулировки? :)
безусловно, использование gpio из userspace - это в принципе не очень хорошая практика, независимо от способа доступа. GPIO должен быть завернут во что-то. gpio-keys, gpio-leds, что-то более другое.
Откуда такой странный вывод ? Вы ознакомились хотя бы с презентацией Linus'а, который является мантейнером подсистемы аж с 2012 года ? Не вводите пожалуйста людей в заблуждение.
Прямой доступ к GPIO может использоваться например для концевых датчиков (и между прочим UAPI даёт для такого события timestamp максимально близский к получению прерывания).
да, вероятно, брать старые железки со старыми ядрами - не самый оптимальный вариант, и современный код изучать правильнее. Спасибо за ссылки, это полезная информация. Тем не менее, есть множество массово производимых и разрабатываемых устройств, где используются ядра 4.x и 5.x, где используется вендорский sdk именно с таким кодом, или около того.
GPIO UAPI был уже c 4.6-r1, в stable пошло ядро 4.19, так насколько легаси нам нужно ?
Не совсем понял, что значит "сразу нет", применительно к процитированным участкам кода.
Ещё раз вы приводите LEGACY код и LEGACY подход к разработке драйверов, которые в новом драйвере (если кто-то решит по вашей статье написать дравер) - просто попросят поменять или сделать по-другому.
вы даете, безусловно, полезную информацию и комментарий очень по делу. Действительно ли присутствует необходимость делать это таким тоном, как будто я за последние три недели лично вам до смерти надоел, или это случайный огрех формулировки? :)
Только если вы не можете отделить себя от самой статьи, мой негатив направлен исключительно на вашу статью, а не на вас конкретно.
Хорошо. А почему вы считаете, что это статья "как надо писать драйверы", а не "как устроены драйверы для распространенных чипов"? Пользуясь вашей тональностью - вы бы хотя бы прочитали заголовок, который приведен аж в самом начале строки :)
GPIO UAPI был уже c 4.6-r1, в stable пошло ядро 4.19, так насколько легаси нам нужно ?
Вот я беру и делаю что-то на Allwinner. Вижу в доступном мне SDK именно такой драйвер. Да, легаси. И что, теперь надо переписать драйвер, или реализовывать все же свою задачу?)
У меня сложилось впечатление, что вы пытаетесь перевести обсуждение самой статьи в личностную плоскость, мне это не интересно.
Из рекомендаций могу еще добавить, что неплохо было бы, прикладывать список использованных материалов.
Опять же по пунктам, от сути к восприятию:
1) Что касается сути замечаний - повторюсь, они приняты и я за них благодарен, они действительно по делу. Статья будет как минимум дополнена замечаниями, что здесь рассмотрен легаси и что так не надо писать новые драйверы.
2) Мне, раз уж дискуссия есть, хотелось бы получить ваше мнение: полезна ли статья тем, кто вынужден работать с готовым легаси-кодом, например, с SDK от того же allwinner? Или эту задачу она не решает?
3) Список использованных материалов не был приведен, т.к. их особо, кроме исходников, и не использовалось. Сейчас, после дополнений, вероятно, стоит его написать.
4) я охотно принимаю замечания и не пытаюсь перейти на личности. просто аллергия на тональность "о госссподи, да все же знают, что...". Потому что "все знают", но мало кто этим знанием делится в понятной форме. А когда начинаешь копать условно с нуля - всей этой информации остро не хватает. И, так уж складывается, найти все это легко только тогда, когда уже знаешь, что именно искать. Возможно, вы не до конца осознаете, но воспринимается написанное вами именно как тот самый тон. Может, конечно, это я излишне снежинка. Но обычно мои ощущения меня не обманывают. Поэтому я пытаюсь попросить высказываться немного нейтральнее.
Мне, раз уж дискуссия есть, хотелось бы получить ваше мнение: полезна ли статья тем, кто вынужден работать с готовым легаси-кодом, например, с SDK от того же allwinner? Или эту задачу она не решает?
В том то и дело, что на мой взгляд - нет. Как дергать ножки через sysfs написано не много, а ОЧЕНЬ много. К тому же есть куча библиотек, чтобы не заниматься этой этой галиматьёй в сотый раз:
найди эту ножку
экспортни ножку
выставь вход/выход
запиши/считай значение
сделай lseek
Brrrrr....
Можно понять тех кто сидит на старой версии ядра до 4.6-r1 (я даже сделал программу которая работает и с SYSFS и c GPIO UAPI v1, в том числе и одновременно). Но они уже для себя давно уже всё сделали и проблемы свои решили.
Вот статья как перестать "страдать" с sysfs gpio и начать "наслаждаться" UAPI gpio - на отдельно взятом SDK (и как прописать ножки в device tree) - вот это ДА (к тому же сейчас уже есть V2 GPIO UAPI) !
Список использованных материалов не был приведен, т.к. их особо, кроме исходников, и не использовалось. Сейчас, после дополнений, вероятно, стоит его написать.
Список материалов всегда нужен, так как это хлебные крошки, по которым может пойти человек в поисках решения своей проблемы.
я охотно принимаю замечания и не пытаюсь перейти на личности. просто аллергия на тональность "о госссподи, да все же знают, что...". Потому что "все знают", но мало кто этим знанием делится в понятной форме. А когда начинаешь копать условно с нуля - всей этой информации остро не хватает.
Может я конечно сижу в своём поисковом пузыре, но та самая перезентация Linus'a у меня элементарно находится на первых местах.
Да и цитируя официальную документацию ядра
https://www.kernel.org/doc/html/latest/driver-api/gpio/using-gpio.html
The userspace ABI is a character device for each GPIO hardware unit (GPIO chip). These devices will appear on the system as /dev/gpiochip0 thru /dev/gpiochipN. Examples of how to directly use the userspace ABI can be found in the kernel tree tools/gpio subdirectory.
For structured and managed applications, we recommend that you make use of the libgpiod library. This provides helper abstractions, command line utilities and arbitration for multiple simultaneous consumers on the same GPIO chip
Её может быть мало на русском языке, что безусловно плохо, но тогда мы должны обеспечить читалей лучшим и современным материалом !
//Так или иначе в процессоре есть контроллер выводов GPIO
Множество Gpio достаточно широкое, это и SuperIO, и I2C-GpioExpander и прочие...
Спасибо, интересно было почитать. Не подскажите как программно задать имя gpio линии. (То которое первая колонка после номера gpio в выводе утилиты gpioinfo.) В raspbery pi например эта колонка заполняется из дерева устройств (dts файл). Было бы классно когда процесс занял линии подписать их назначение. Спасибо.
Это интересный вопрос. Сходу точно не отвечу, надо смотреть и изучать. Запланирую :) либо дополню сюда, либо в следующей статье.
Если речь именно о gpio-line-names, то из userspace никак - они задаются либо из драйвера, либо из dt (причем оно приоритетней драйверного списка).
Если же речь идет о том, чтобы их поименовать в принципе, то подойдет поле consumer:
https://elixir.bootlin.com/linux/v6.8-rc4/source/include/uapi/linux/gpio.h#L179
Единственное, для того, чтобы КАЖДАЯ линия имела уникальное значение consumer, придется запрашивать каждую линию отдельно.
Жаль. Подождем v3
Ну во-первых не жаль, а вполне логично. Во-вторых откуда информация, что это будет в v3 ?
Спасибо большое за статью!!! Версия устройства, с которым я работаю, 4.4.19 (это для @maquefel чтобы знали, что есть люди, которым полезны такие статьи найти на русском:) )
Устройство GPIO-драйверов в Linux