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

Documentation/i2c/dev-interface


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

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

т.е. если загружен драйвер, использующий эту шину, и в списке адресов, на этом адресе UU- занята, то никак и никогда я снаружи туда ничего не подгружу? Кроме как через этот драйвер, что использует ее?

погуглю за вас в интернете. очень дорого.
"i2c ioctl example"

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

да, если адрес заблокирован драйвером и вы видите UU, то он занят..
все что можно сделать - собрать драйвер модулем и выгрузив модуль, получить доступ в нужный адрес, и после работы загрузить драйвер обратно..
либо модифицировать драйвер, чтобы он, например, через sysfs получал данные от вашей программы и пересылал в устройство
непонятна суть ваших действий?
если дополнить функционал, то проще дописать в существующем драйвере
если что-то менять "на ходу", то проще рулить через переменные в sysfs

как классический пример - драйвер lm85 дает порулить pwm чипа через обычное echo в sysfs.

Вам же дали документ с примером и объяснениями:
https://www.kernel.org/doc/Documentation/i2c/dev-interface



Верно.
Что легко проверить заглянув сюда:
/sys/bus/i2c/drivers

Здесь тоже интересно:
/sys/bus/i2c/devices/
Видно все устройства и их адреса.

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

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


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

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

Полагаю, что имелось ввиду, что драйвер, работающий с нашим устройством не должен быть активным (драйвер на той же i2c чине и с тем же адресом), а для ioctl нужен драйвер i2c, который в директории /sys/ видем как i2c-0 для первой шины, i2c-1 для второй.

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


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

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


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


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