[R6L-025 1]

Добрый день!

Столкнулся с проблемой: есть устройство на ArriaV SoC, есть ядро 3.10 поднятое на ней, есть spi. Нужно совершить несколько транзакций не поднимая ChipSelect между ними.

В экземпле из документации ядра (Documentation/spi/spidev_test.c) транзакции осуществляются через передачу структуры сообщения "spi_ioc_transfer". В ней есть поле "cs_change". Как я понял через это поле можно управлять CS, однако... не вышло :smile3046: . Драйвер упорно поднимает CS между посылками при любых значениях поля. Еще есть подозрение что это еще можно сделать через вызов ioctl(fd, SPI_IOC_WR_MODE, &mode), где переменной mode передать флаг "SPI_READY". Вот только ядро начинает ругаться на некорректный аргумент "mode". Запускал экземпл spidev_test.c с разными флагами mode - та же история, ругается на любые флаги.

Кто нибудь знает как можно заставить ядро не поднимать CS?

[Jury093 2]

Кто нибудь знает как можно заставить ядро не поднимать CS?

я с год назад боролся с подобным на Cyc V SOC, пришел к выводу, что это не побороть. в моем случае помогло откусить CS от SPI интерфейса (командой в юбуте) и вывести этот пин в режим GPIO, а т.к. канал был один, то просто вывел в 0, через value..

вам возможно поможет, если сможете включить CS-GPIO, когда драйвер дергает CS не через аппаратный ресурс, а в режиме GPIO и там подкрутить под требуемое поведение

а если система не требовательна к ресурсам, то можно просто перейти на SPI-GPIO, но это нагрузка на проц и не очень стабильные времянки

[R6L-025 1]

Jury093, спасибо!

А вы не помните последовательность как отключать CS в uboot-е? :)

[Jury093 2]

А вы не помните последовательность как отключать CS в uboot-е? :)

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

после qsys и запуска юбута, там будет значение для работы в составе SPI (если не вру, 3 бита для multifunction mode), вот в этом битовом поле надо поменять на gpio mode

в моем случае была последовательность из одной команды - записать в память значение, значение предварительно считано стандартной командой чтения памяти в юбут и откорректировано (кажись команды "md/mw" с аргументами)

[R6L-025 1]

Спасибо, попробую. Еще пришла идея после старта ОС напрямую в контроллер SPI постучаться чтоб подергать CS, а передавать данные уже силами драйвера

[Jury093 2]

Спасибо, попробую. Еще пришла идея после старта ОС напрямую в контроллер SPI постучаться чтоб подергать CS, а передавать данные уже силами драйвера

кстати, да, о ядре то я и забыл, конечно можно и из ядра - просто в моем случае всё было на уровне тестов и ядро лень было пересобирать :)

 

[R6L-025 1]

Ну я в ядре не силен, хочу попробовать отобразить на виртуальную память адресное пространство контроллера, и насильно придавить CS. Подсмотрел в альтеровском hwlib для baremetall как они это далают, завтра буду пробовать :)

[Jury093 2]

Ну я в ядре не силен, хочу попробовать отобразить на виртуальную память адресное пространство контроллера, и насильно придавить CS. Подсмотрел в альтеровском hwlib для baremetall как они это далают, завтра буду пробовать :)

если я в ядре поддержана и включена опция gpio, то можно посчитать номер и поэхать

echo XXX > /sys/class/gpio/export

где ХХХ логический номер GPIO для физического пина

если команда пройдет успешно, то вы получили контроль над пином в режиме gpio - его можно перестроить на выход и прописать уровень

метод тормозной, но если все включено в ядре, то пересобирать не надо..

или прописать в исходниках этот пин, тогда он автоматом появится в том же /sys/class/gpio, если его не перехватит spi

[R6L-025 1]

Хм, но ведь пин настроен в qsys как принадлежащий spi, и мультиплексор периферии сконфигурирован соответствующе, или ядру всеравно?

[Jury093 2]

Хм, но ведь пин настроен в qsys как принадлежащий spi, и мультиплексор периферии сконфигурирован соответствующе, или ядру всеравно?

дак а вопрос то в чём?

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

в случае, который описываю я все условия соблюдены

в qsys разрешен аппаратный интерфейс SPI

в юбут у SPI отключается CS

да, забыл упомянуть (давно это было), в dts для ядра в секции spi прописано (для моего случая)

&spi0 {
   status = "okay";
   num-cs = <1>;
/*   cs-gpios = <&portc 2 GPIO_ACTIVE_LOW>;*/

потом через echo я конфигурю пин CS вручную под себя (выход, 0)

и чип-слейв бодро работает..

 

в теории, можно перекрутить пин не из юбута, а прямо из линукса (через mmap), но "Ну я в ядре не силен", тут надо писать несложную программу и если вам хватил скилла, то возможно это ваш путь, а не через юбут..