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

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

Jury093, спасибо!
А вы не помните последовательность как отключать CS в uboot-е?

поищите в мануале на камень или хидерах исходников юбута - адрес регистра, который отвечает на режим для CS и соседних GPIO.
после qsys и запуска юбута, там будет значение для работы в составе SPI (если не вру, 3 бита для multifunction mode), вот в этом битовом поле надо поменять на gpio mode
в моем случае была последовательность из одной команды - записать в память значение, значение предварительно считано стандартной командой чтения памяти в юбут и откорректировано (кажись команды "md/mw" с аргументами)

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

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

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

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

где ХХХ логический номер GPIO для физического пина
если команда пройдет успешно, то вы получили контроль над пином в режиме gpio - его можно перестроить на выход и прописать уровень
метод тормозной, но если все включено в ядре, то пересобирать не надо..
или прописать в исходниках этот пин, тогда он автоматом появится в том же /sys/class/gpio, если его не перехватит spi

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

дак а вопрос то в чём?
ядру на все наплевать, если его не будут грузить назойливые драйверы, драйвер может расстроиться и не загрузиться, если не будет нужных ресурсов..
в случае, который описываю я все условия соблюдены
в qsys разрешен аппаратный интерфейс SPI
в юбут у SPI отключается CS
да, забыл упомянуть (давно это было), в dts для ядра в секции spi прописано (для моего случая)

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

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