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

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

i2c-0

сама шина.

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

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

[alx2 0]

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

Documentation/i2c/dev-interface

 

i2c-0

сама шина.

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

Мультимастер?

Не имеет значения, какие устройства физически есть на шине. Имеет значение, занята шина какой-то операцией в данный конкретный момент или нет.

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

 

[Des333 0]

Мультимастер?

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

 

Имеет значение то, какие драйвера сейчас загружены.

Есть ли среди них использующие эту I2C шину.

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

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

[Jury093 2]

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

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

"i2c ioctl example"

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

да гуглил уже. Даже пример накатал. Вопрос в том, что если шина i2cdetect -y 0

UU на ней, то ioctl запись ругается- пишет, но читает опять старые значения

[Jury093 2]

да гуглил уже. Даже пример накатал. Вопрос в том, что если шина i2cdetect -y 0

UU на ней, то ioctl запись ругается- пишет, но читает опять старые значения

да, если адрес заблокирован драйвером и вы видите UU, то он занят..

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

либо модифицировать драйвер, чтобы он, например, через sysfs получал данные от вашей программы и пересылал в устройство

непонятна суть ваших действий?

если дополнить функционал, то проще дописать в существующем драйвере

если что-то менять "на ходу", то проще рулить через переменные в sysfs

 

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

[Tarbal 4]

да гуглил уже. Даже пример накатал. Вопрос в том, что если шина i2cdetect -y 0

UU на ней, то ioctl запись ругается- пишет, но читает опять старые значения

 

Вам же дали документ с примером и объяснениями:

https://www.kernel.org/doc/Documentation/i2c/dev-interface

 

да, если адрес заблокирован драйвером и вы видите UU, то он занят..

 

Верно.

Что легко проверить заглянув сюда:

/sys/bus/i2c/drivers

 

Здесь тоже интересно:

/sys/bus/i2c/devices/

Видно все устройства и их адреса.

[alx2 0]

Имеет значение то, какие драйвера сейчас загружены.

Есть ли среди них использующие эту I2C шину.

Что-то я не понял Вашу мысль...

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

 

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

 

Вопрос в том, что если шина i2cdetect -y 0

UU на ней, то ioctl запись ругается- пишет, но читает опять старые значения

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

[Jury093 2]

Что-то я не понял Вашу мысль...

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

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

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

[Tarbal 4]

Что-то я не понял Вашу мысль...

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

 

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

 

 

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

 

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

[alx2 0]

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

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

 

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

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

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

 

[Jury093 2]

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

драйвера i2c чего?

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

если загружен драйвер устройства, то шина будет доступна, но при попытке обращения к занятому адресу вернется код ошибки

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

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

всё, вроде больше вариантов нет..

 

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

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

 

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

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

у ТС не указана архитектура, но обычно во встройке применяют аудиокодеки, а термин "звуковуха" ближе к х86 архитектуре

я плотно в х86 не лазил, но обычно звуковые карточки для х86 управляются через интерфейс i2s, который не имеет отношения к i2c

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