ioctl, писать через него I2C данные Опции

[Метценгерштейн]

как правильно делать отправку данных через ф-ю ioctl на i2c?
i2c-0
сама шина.
И может ли данная ф-я что-то писать в шину, если на шине есть звуковая карта на этом месте? Просто программа, которая запускается и пишет туда через ioctl, возвращает ошибку, т.к. шина занята.
А если изначально все модули звуковух убрать, то шина i2c свободна и можно через программу по ioctl писать что-то.

[alx2]

как правильно делать отправку данных через ф-ю ioctl на i2c?

Documentation/i2c/dev-interface

i2c-0
сама шина.
И может ли данная ф-я что-то писать в шину, если на шине есть звуковая карта на этом месте? Просто программа, которая запускается и пишет туда через ioctl, возвращает ошибку, т.к. шина занята.

Мультимастер?
Не имеет значения, какие устройства физически есть на шине. Имеет значение, занята шина какой-то операцией в данный конкретный момент или нет.
Шину i2c в любой момент времени может использовать только один мастер. Естественно, что если шина уже занята каким-то мастером, то другой мастер в это время работать с шиной не может. Он должен ждать освобождения шины.

[des333]

Мультимастер?
Не имеет значения, какие устройства физически есть на шине.

Имеет значение то, какие драйвера сейчас загружены.
Есть ли среди них использующие эту I2C шину.

[alx2]

Имеет значение то, какие драйвера сейчас загружены.
Есть ли среди них использующие эту I2C шину.

Что-то я не понял Вашу мысль...
Если не загружено ни одного драйвера, использующего нашу шину, каким образом пользовательская программа сможет обратиться к устройству на этой шине???

Вот, например, у меня в устройстве в ядре присутствует один из драйверов из drivers/i2c/busses/. Пользовательские программы с его помощью (используя ioctl) обращаются к устройствам на шине. Если на момент обращения шина свободна, выполняется запрошенная операция. Если же на момент обращения шина занята (на шине присутствует другой мастер, который в данный момент выполняет операцию), наше устройство будет ждать освобождения шины, после чего начнет выполнять запрошенную операцию. Если другой мастер в этот момент захочет выполнить новую операцию, он будет ждать, когда завершится наша. Таким образом, несколько мастер-устройств вполне могут совместно использовать одну и ту же шину. И только в случае, если один из мастеров занял шину и не освобождает длительное время (например читает одной операцией большой объем данных или вообще завис), другой мастер получить доступ к шине не сможет. В этом случае ioctl вернет ошибку (timeout). Вот как-то так... Кстати, удерживать шину в занятом состоянии может и slave-устройство...

Вопрос в том, что если шина i2cdetect -y 0
UU на ней, то ioctl запись ругается- пишет, но читает опять старые значения

Не понял... ioctl при попытке записи возвращает -1? Что при этом в errno?

[Jury093]

Что-то я не понял Вашу мысль...
Если не загружено ни одного драйвера, использующего нашу шину, каким образом пользовательская программа сможет обратиться к устройству на этой шине???

а в чем проблема? при наличие прав доступа к шине можно из программы обратиться к любому свободному допустимому адресу на шине i2c - ioctl и вперед, делал так неоднократно..
если вы имеете в виду отсутствие драйвера самой шины (выключена поддержка в хостовом проце), то опять же при наличие прав можно на обычных gpio изобразить диаграмму i2c и работать со слейвом в режиме программного i2c.. или задействовать стандартный i2c-gpio в kernel

[alx2]

а в чем проблема? при наличие прав доступа к шине можно из программы обратиться к любому свободному допустимому адресу на шине i2c - ioctl и вперед, делал так неоднократно..

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

если вы имеете в виду отсутствие драйвера самой шины (выключена поддержка в хостовом проце), то опять же при наличие прав можно на обычных gpio изобразить диаграмму i2c и работать со слейвом в режиме программного i2c.. или задействовать стандартный i2c-gpio в kernel

Да, я говорил о драйвере шины. Метценгерштейн упоминал, что там на шине есть звуковая карта. Я что-то сомневаюсь, что обмен со звуковой картой происходит через программный i2c. Наверняка там аппаратный контроллер...
Метценгерштейн, думаю, пора уточнить, как у Вас подключена шина к контроллеру (есть ли аппаратный i2c), какие драйвера используются, что Вы запрашиваете через ioctl и какую ошибку ioctl возвращает. Без конкретики мы тут можем только гадать, и вряд ли чем-то сможем Вам помочь...

[Jury093]

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

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

Метценгерштейн, думаю, пора уточнить, как у Вас подключена шина к контроллеру (есть ли аппаратный i2c), какие драйвера используются, что Вы запрашиваете через ioctl и какую ошибку ioctl возвращает. Без конкретики мы тут можем только гадать, и вряд ли чем-то сможем Вам помочь...

вот что писал ТС в начальном сообщение:

И может ли данная ф-я что-то писать в шину, если на шине есть звуковая карта на этом месте? Просто программа, которая запускается и пишет туда через ioctl, возвращает ошибку, т.к. шина занята.
А если изначально все модули звуковух убрать, то шина i2c свободна и можно через программу по ioctl писать что-то.

у ТС не указана архитектура, но обычно во встройке применяют аудиокодеки, а термин "звуковуха" ближе к х86 архитектуре
я плотно в х86 не лазил, но обычно звуковые карточки для х86 управляются через интерфейс i2s, который не имеет отношения к i2c
и что там у автора происходит и куда и как он обращается, мне даже гадать лень..