toweroff

Итак, по результатам анализа эпюр, интерфейс SPI работает корректно, как с аппаратным CS0, так и с cs-gpio (CS1) проблема в конфигурировании устройства, сидящего на CS1, но это не проблема интерфейса SPI

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

не очень, да. И, как оказалось, вносит свой раздрай при обмене(( пока ищу, можно ли корректировать время активирования CS до начала такта и время деактивации после

Заработало. aaarrr, большое спасибо за помощь! это выборка с софтовым CS1 это с аппаратным CS0

Не хочет spidev1.1 поднимать( root@OpenWrt:~# dmesg | grep spi [ 0.336207] sun6i-spi 1c69000.spi: chipselect 0 already in use [ 0.354936] spi_master spi1: spi_device register error /soc/spi@1c69000/spidev@1 [ 0.354974] spi_master spi1: Failed to create SPI device for /soc/spi@1c69000/spidev@1 root@OpenWrt:~# ls /dev/spi* /dev/spidev1.0 root@OpenWrt:~# извиняюсь... почему-то опять всплыл reg = <0>; сейчас пересоберу, проверю

в sunxi-h3-h5.dtsi вот такое описание: r_pio: pinctrl@1f02c00 { compatible = "allwinner,sun8i-h3-r-pinctrl"; reg = <0x01f02c00 0x400>; interrupt-parent = <&r_intc>; interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>; clocks = <&r_ccu CLK_APB0_PIO>, <&osc24M>, <&rtc CLK_OSC32K>; clock-names = "apb", "hosc", "losc"; gpio-controller; #gpio-cells = <3>; interrupt-controller; #interrupt-cells = <3>; r_ir_rx_pin: r-ir-rx-pin { pins = "PL11"; function = "s_cir_rx"; }; r_i2c_pins: r-i2c-pins { pins = "PL0", "PL1"; function = "s_i2c"; }; r_pwm_pin: r-pwm-pin { pins = "PL10"; function = "s_pwm"; }; r_uart_pins: r-uart-pins { pins = "PL2", "PL3"; function = "s_uart"; }; }; т.е. у порта PL вообще отдельное описание и пин уже как бы занят

PL11 по идее.. да, точно. Поправил, но результат тот же

Пока вот такой результат (прототип на T113 до меня пока добирается, тестирую эту часть на NanopiNeoCore, там CS0 нативный, CS1 через GPIO): &spi1 { status = "okay"; cs-gpios = <0>, <&pio 11 11 GPIO_ACTIVE_LOW>; spidev@0 { compatible = "rohm,dh2228fv"; /* =spidev Kludge, workaround for "buggy DT: spidev listed directly in DT" */ spi-max-frequency = <5000000>; reg = <0>; }; spidev@1 { compatible = "rohm,dh2228fv"; /* =spidev Kludge, workaround for "buggy DT: spidev listed directly in DT" */ spi-max-frequency = <5000000>; reg = <0>; }; }; root@OpenWrt:~# dmesg | grep spi [ 0.317015] sun6i-spi 1c69000.spi: cannot register SPI master [ 0.341211] sun6i-spi 1c69000.spi: cannot register SPI master [ 0.344645] sun6i-spi 1c69000.spi: cannot register SPI master [ 0.361196] sun6i-spi 1c69000.spi: cannot register SPI master [ 0.362052] sun6i-spi 1c69000.spi: cannot register SPI master [ 0.404093] sun6i-spi 1c69000.spi: cannot register SPI master [ 0.415344] sun6i-spi 1c69000.spi: cannot register SPI master [ 1.413215] sun6i-spi 1c69000.spi: cannot register SPI master [ 1.423505] sun6i-spi 1c69000.spi: cannot register SPI master [ 1.468072] sun6i-spi 1c69000.spi: cannot register SPI master [ 1.474606] sun6i-spi 1c69000.spi: cannot register SPI master [ 1.520434] sun6i-spi 1c69000.spi: cannot register SPI master [ 1.527071] sun6i-spi 1c69000.spi: cannot register SPI master [ 5.636167] sun6i-spi 1c69000.spi: cannot register SPI master [ 20.326411] sun6i-spi 1c69000.spi: cannot register SPI master [ 20.332482] platform 1c69000.spi: deferred probe pending [ 26.551622] sun6i-spi 1c69000.spi: cannot register SPI master

ну вот нихрена не понял, где тут две CS линии ну и чуть выше по документу прибило совсем: точнее, тут понятно расположение значений для cs-gpio. Откуда "2 CS lines"? Где-то в драйвере sunxi видел, что cs >=4 вообще не будет рассматриваться завтра буду пробовать

нашёл вот так:

ну вот навскидку не понимаю. Тогда уж CS0 переписывается ногодрыгом но полез искать-читать...

с параметрами пытаюсь копаться, но пока всё равно нет понимания, как cs-gpios описывает виртуальные CSx посмотрю-попробую завтра с анализатором, но пока логики описания чип селектов не вижу, хоть тресни( гпио дескриптор -- это аппаратный SPI_CS, который мультиплексирован на GPIO? ну вот не увидел, хоть тресни, описание того, что это именно CS1. Или это просто выбор пина, а на пине мультиплексор привязан к именно CS1? тогда "софтовый" CSx как описать и какой он там по счёту будет? по факту описания? а если по ходу есть действительный аппаратный селект на конкретном пине? а аппаратный CS0 ещё вдобавок забыли убрать из контроллера и он просто не подключен никуда?

а зачем? к spidev могут обращаться разные процессы. Пусть в порядке очереди и лезут, зачем ещё и лишние сущности мониторить? ух.. тогда точно не понял. Объясните, пожалуйста

можно пояснить, моя нипанимай) параметром cs-gpios задаются CSx по порядку? <0> -- это аппаратный CS0, <gpio...> -- это ногодрыг условного CS1? если так, продолжу: таким же образом можно описывать другие GPIO как CSx? и ещё момент... на ножку вынесен только аппаратный CS1 у T113-S3. Если использовать ногодрыг, то получится так? cs-gpios = <&pio x y GPIO_ACTIVE_LOW>, <1>; правильно?

да, мастер. Но нет любимого Вами бареметала) так-то я и сам бы смог у линуха есть только драйверы, которым нужно правильно это сказать, а как -- не знаю(( тут получается же вот какая штука -- есть аппаратный CS (CS1) и (ибо другого нет на ножках МК) программный. И вот нет понимания, как срестить ужа и ежа

Ёмко) Можно подробнее? находил на просторах подобное, но там ядро вообще древнее, 3 версия. У меня 6.1 ((

похож на T113, если BGA, то покопайте в сторону T113i, у него как раз BGA, набортной памяти нет, только интерфейс к ней

Доброго времени! Есть на борту процессора аппаратный SPI1, у которого на ножки смаппирован только CS1 Как выяснилось после сборки прототипов, необходим ещё один CSx. Пусть он даже будет не аппаратным, а простым GPIO, самый главный вопрос -- как правильно сказать это драйверу? Софт работает с целевым устройством через spidev и, соответственно, через устройство /dev/spidev1.1 В результате нужно ещё одно устройство -- /dev/spidev1.2 (или любой другой номер). Возможно это сделать штатными средствами через дерево или придётся пилить драйверы?

отчего же? даже очень но нет такого пакета в OpenWRT, а саму кухню опиливать в пакет не есть хорошо в данный момент. Нужно быстро смастырить, показать, а потом уже разбираться, что там лучше, хуже и сколько затрат на улучшайзинг((

Доброго времени! Ну пусть даже будет модуль MangoPi с T113-S3 и AP6212A на борту. Блюпуп подключен по физическому UART. Возможно (и как) скрестить ужа и ежа, чтобы с того же телефона подключиться как к точке доступа с внутренним IP модуля? Интересуют именно максимально программные (готовые) решения, на основе того же bluez + прописать дерево с драйверами В силу разных причин заказчика именно точка доступа WiFi не подходит. Именно нативно через блюпуп сделать некий сетевой адаптер.

если OpenWRT не врёт, то 6.1.63 root@OpenWrt:/# dmesg | grep spi root@OpenWrt:/#

в том-то и дело, что.. просто ничего кстати, и сейчас то же самое)

root@OpenWrt:/# ls /dev bus mmcblk0p3 tty17 tty4 tty62 console mmcblk1 tty18 tty40 tty63 fd mmcblk1p1 tty19 tty41 tty7 full mmcblk1p2 tty2 tty42 tty8 gpiochip0 null tty20 tty43 tty9 gpiochip1 ppp tty21 tty44 ttyS0 hwrng psaux tty22 tty45 ttyS1 i2c-1 ptmx tty23 tty46 ttyS2 input pts tty24 tty47 ttyS3 kmsg random tty25 tty48 ttyS4 log shm tty26 tty49 ttyS5 loop-control spidev1.0 tty27 tty5 ttyS6 loop0 stderr tty28 tty50 ttyS7 loop1 stdin tty29 tty51 urandom loop2 stdout tty3 tty52 userio loop3 tty tty30 tty53 vcs loop4 tty0 tty31 tty54 vcs1 loop5 tty1 tty32 tty55 vcsa loop6 tty10 tty33 tty56 vcsa1 loop7 tty11 tty34 tty57 vcsu mmcblk0 tty12 tty35 tty58 vcsu1 mmcblk0boot0 tty13 tty36 tty59 vhost-net mmcblk0boot1 tty14 tty37 tty6 watchdog mmcblk0p1 tty15 tty38 tty60 watchdog0 mmcblk0p2 tty16 tty39 tty61 zero а вот и счастье) большое спасибо! понимаю, что в этом вариться нужно постоянно) но откуда хоть как-то черпать инфу?

это как subnode?

в том-то и дело, что нужен голый spidev* (ну в моём случае это spidev1), а не память на интерфейсе но и ничего левого (spi_nor, spi_nand, ...) в конфигах не замечено а так-то оно да, включено: Symbol: SPI_SPIDEV [=y] │ │ Type : tristate │ │ Defined at drivers/spi/Kconfig:1135 │ │ Prompt: User mode SPI device driver support │ │ Depends on: SPI [=y] && SPI_MASTER [=y] │ │ Location: │ │ -> Device Drivers │ │ -> SPI support (SPI [=y]) │ │ (1) -> User mode SPI device driver support (SPI_SPIDEV [=y]) │ root@OpenWrt:/# ls /dev bus mmcblk1boot1 tty18 tty40 tty63 console mmcblk1p1 tty19 tty41 tty7 fd mmcblk1p2 tty2 tty42 tty8 full mmcblk1p3 tty20 tty43 tty9 gpiochip0 null tty21 tty44 ttyS0 gpiochip1 ppp tty22 tty45 ttyS1 hwrng psaux tty23 tty46 ttyS2 i2c-1 ptmx tty24 tty47 ttyS3 input pts tty25 tty48 ttyS4 kmsg random tty26 tty49 ttyS5 log shm tty27 tty5 ttyS6 loop-control stderr tty28 tty50 ttyS7 loop0 stdin tty29 tty51 urandom loop1 stdout tty3 tty52 userio loop2 tty tty30 tty53 vcs loop3 tty0 tty31 tty54 vcs1 loop4 tty1 tty32 tty55 vcsa loop5 tty10 tty33 tty56 vcsa1 loop6 tty11 tty34 tty57 vcsu loop7 tty12 tty35 tty58 vcsu1 mmcblk0 tty13 tty36 tty59 vhost-net mmcblk0p1 tty14 tty37 tty6 watchdog mmcblk0p2 tty15 tty38 tty60 watchdog0 mmcblk1 tty16 tty39 tty61 zero mmcblk1boot0 tty17 tty4 tty62 вот что в /dev