[12:44:48] <stuw> zombah, я смотрел инфу по поводу bus pirate, но так и не понял, она может вместе с i2c смотреть еще какие-нибудь каналы?
[12:45:00] <stuw> zombah, может ты в курсе
[12:45:10] <stuw> zombah, привет %)
[12:55:43] <zombah> stuw: привет
[12:56:21] <zombah> stuw: я его подключал к eeprom сидящему на i2c и он мне показывал комманды которые летели к этому eeprom
[12:56:41] <zombah> и с него
[12:56:59] <zombah> всего тремя ногами инпут, оутпут и земля
[12:57:26] <stuw> да, что это он у меет я знаю. мне интересно, сможет ли обрабываться еще один канал (EC_REQUET)
[12:57:38] <zombah> для этого на пирате надо было выбрать режим i2c, нужно кол-во герц и вроде все
[12:57:53] <zombah> stuw: хм вот это не скажу не знаю
[12:58:06] <zombah> счас дам тебе линк по которому сам делал
[12:59:03] <zombah> почитай может так тебе понятней его функционал станет
[13:00:01] <stuw> zombah, я похожие мануалы видел. Похоже придется на форум dangerousprototypes таки лезть :)
[13:00:35] <stuw> точнее не просто лезть, а задавать вопрос %)
[13:00:55] <zombah> stuw: спроси на канале coreboot скажи что разбираешься с таким то ec может они подскажут как правильно действовать
[13:01:24] <stuw> ок, попробую сначала коребутовские ресурсы пошерстить
[13:05:39] <zombah> ты кстати даташит читал на это ene? может там написано?
[13:06:41] <zombah> у меня он есть могу дать
[13:07:16] <stuw> у меня тоже есть.
[13:07:24] <zombah> ок
[13:07:46] <zombah> kb926d revision 1.1 dec 2008
[13:07:57] <stuw> мне понятно, что нужно смотреть, но не ясно, реально ли это нормально сделать с помощью bus pirate или придется использовать logic sniffer.
[13:08:29] <zombah> ну так бус пиратом я могу попробовать посмотреть
[13:08:34] <stuw> еще я тут понял, что можно clk от i2c не смотреть, и тогда будет 2 канала для анализа.
[13:10:01] <zombah> это как осцилограф чтоли?
[13:10:07] <stuw> типа того
[13:10:24] <stuw> данные на комп софту отдаются, а софт уже показывает, что к чему
[13:10:36] <stuw> и тут только цифровой анализ, а не аналоговый
[13:10:57] <zombah> понятно
[13:11:08] <stuw> хотя м.б. уровень тоже можно получить.
[13:11:34] <zombah> я в этом уже вообще ничего не понимаю, мумба юмба сплошная
[13:13:00] <stuw> тут ничего сложного - с определенным интервалом проверяется состояние линии.
[13:13:19] <stuw> по большому счету больше ничего не делается
[13:13:35] <stuw> кстати, i2c без clk хрен расшифруешь :(
[13:13:40] <stuw> это печально
[13:14:16] <zombah> без клока?
[13:14:34] <stuw> у i2c две линии - clk и data
[13:14:54] <stuw> если смотреть только data, то не понятно, что передается.
[13:15:13] <zombah> а почему не смотреть обе?
[13:16:13] <zombah> а ты смотрел драйвер ene932 может он похож на наш девайс?
[13:16:33] <zombah> http://review.coreboot.org/gitweb?p=coreboot.git;a=history;f=src/ec/compal/ene932;hb=HEAD
[13:18:00] <stuw> чтобы второй канал задействовать для просмотра EC_REQUEST. Тегра общается с EC так: когда что-то нужно передать EC тегра дергает EC_REQUEST, EC начинает передачу, тегра до окончания передачи отпускает EC_REQUEST, передача продолжается. Мне интересны следующие пара
[13:18:00] <stuw> метры: частота clk, моменты поднятия/отпускания EC_REQUEST относительно передачи данных
[13:18:08] <stuw> не смотрел, сейчас гляну
[13:19:35] <zombah> просто врядли ene сильно меняет логику работы своих ec они могут быть как братья близнецы только разница в каком нить размере еепром под прошивку
[13:20:48] <stuw> кстати, мы похоже уже смотрели этот драйвер
[13:21:05] <stuw> по коду похоже, что ec доступен напрямую (запись/чтение регистров)
[13:21:19] <zombah> у нас не так?
[13:21:19] <stuw> у нас же доступ по i2c, причем тегра как slave
[13:21:32] <zombah> аа
[13:23:07] <stuw> да, для 932 используется outb(unsigned char value, unsigned short int port)
[13:24:19] <stuw> в принципе частоту i2c можно и пиратом посмотреть.
[13:26:08] <stuw> но я думаю заказать себе Open Bench Logic Sniffer. Может быть осилю и включение звукового кодека (посмотрю, как в 2.1 он без щелчка врубается)
[13:26:11] <zombah> http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/ec/google/chromeec/ec.c;h=c57e18bbca808bb79fe52d2f14398d60d1603531;hb=HEAD#l156
[13:26:37] <zombah> stuw: о это очень полезная тема
[13:27:17] <zombah> щелчки эти вообще не в кассу
[13:30:43] <stuw> да, i2c код уже интереснее
[13:31:10] <zombah> может там у них найтедтся другой марки но работающий похожим образом
[13:32:21] <stuw> у нас самая большая проблема в том, что тегра работает как slave
[13:32:35] <zombah> stuw: почему?
[13:33:17] <stuw> так задумано и мало кто использует такую схему
[13:33:35] <stuw> пока мне кажется, что chromeec - slave, проц - master
[13:33:44] <stuw> но я еще поковыряюсь
[13:36:07] <zombah> именно проц? или северный мост мастер? я не очень поманию общую схему
[13:36:08] <stuw> да, проц работает как master :) не отвертется нам
[13:36:23] <stuw> i2c контроллер на SoC
[13:37:02] <zombah> ну там как бы весь функционал внутри сок и мосты и проц
[13:38:01] <zombah> а по какому признаку ты понял что проц мастер покажи, я тоже поищу в разных кодах
[13:38:47] <stuw> работа с i2c шиной идет через i2c контроллер. В случае хромбуков самсунга (этот ec драйвер для них, на сколько я понял) i2c контроллер exynos работает как мастер
[13:39:19] <zombah> а во i2c контроллер понятно, так как ты понял что он мастер?
[13:39:28] <stuw> 1) http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/ec/google/chromeec/ec_i2c.c;h=a13dde6a7b7cf649ea6e3593eb6128147f527c66;hb=HEAD#l116
[13:39:39] <stuw> тут идет запись команды и потом чтение ответа
[13:39:47] <zombah> а у нас чтож ene мастер а i2c контроллер слейв?
[13:39:52] <stuw> да
[13:39:57] <zombah> ишь как
[13:40:34] <stuw> для slave так делать не очень правильно, т.к. мастер может запросить операцию чтения, а мы будем пытаться сделать запись -> получится каша
[13:40:51] <zombah> да да начинаю улавливать
[13:43:28] <stuw> хм, я локально смотрел chromium.googlesource.com/chromiumos/third_party/coreboot - там i2c_write уходит в код для exynos. А на сайте коребут я не могу найти кода для exynos ))
[13:45:15] <stuw> 2) в коде chromium.googlesource.com/chromiumos/third_party/coreboot i2c_write зовет i2c_transfer, а i2c_transfer сам выставляет start condition -> он мастер
[13:49:19] <zombah> беда
[13:49:58] <zombah> а может просто погуглить упоминания такой комбирации когда это бус контроллер работает слейвом и посмотреть уже код рабочей связки?
[13:59:31] <zombah> правда тут видно нужны некие кодовые слова, простым описанием я ничего не нахожу интересного
[14:03:45] <stuw> zombah, в mainline ядре такого нет, т.к. нет еще устоявшейся схемы для device tree в подобных случаях
[14:04:57] <stuw> у нас проблемы сейчас заключаются в том, что 1) ec иногда тупит 2) сон работает нестабильно 3) в мейнлайне нужно менять i2c core под наш драйвер
[14:05:35] <stuw> первые две вещи нужно отлаживать на железе (самое простое - сравнить поведение в 2.1 и сейчас)
[14:05:49] <stuw> третью - только обсуждать и имплементить
[14:05:55] <zombah> ну мейнлайн это конечно серьезно, ят пока радею за даунстрим ибо с мейнлайном в андроиде пока тухляк
[14:07:09] <stuw> так а что ты в даунстриме хочешь получить?
[14:07:11] <stuw> сон?
[14:07:49] <zombah> stuw: ну пока хочу чтоб ошибок синхронимации при движениях тачем не было 8) а дальше видно будет
[14:08:47] <stuw> я думаю тут надо проверять, что на уровне железа происходит
[14:09:12] <stuw> код драйвера простой и его вроде анализировали триста раз
[14:09:19] <zombah> stuw: всмысле? так ведь там пяток патчей откатить и ошибки пропадают
[14:09:22] <stuw> может быть мы не то что-то шлем
[14:09:28] <stuw> хм...
[14:09:33] <stuw> можно заняться
[14:09:36] <stuw> :)
[14:09:59] <stuw> но нужно будет откатывать, накатывать, проверки вставлять
[14:10:26] <zombah> вот посмотри список ревертов https://github.com/ac100-ru/android_kernel_asus_grouper/commits/cm-11.0-ac100 в staging: nvec
[14:10:46] <zombah> так откатываю и все зашибись тач начинает работать нормально
[14:11:24] <stuw> по-одному пробовал откатывать?
[14:11:40] <zombah> да пробовал конечно, так и нашел место перелома
[14:11:52] <stuw> который из патчей?
[14:12:48] <zombah> вот этот кажется https://github.com/ac100-ru/android_kernel_asus_grouper/commit/ae6ceaf9becfebc8ad468c7039a6b303c07f37b1
[14:13:15] <zombah> счас логи надо посмотреть это все давно проверялось когда только проблема появилась
[14:14:24] <zombah> ладно проще еще раз проверить просто, все равно мне как раз надо опять патчи марвина натянуть на нексус ядро
[14:14:38] <zombah> сегодня вечером сделаю полный отчет по этой теме
[14:14:46] <zombah> хотя может на вики что осталось
[14:15:00] <stuw> Если этот патч, то он большой. Его надо будет по кускам откатывать, тогда проще будет найти проблему.
[14:15:50] <zombah> stuw: там половина этих патчей идет в связке т.к. это марвин даунстрим драйвер приводил к виду похожему на мейнлайн
[14:16:38] <stuw> ясно, значит придется несладко, но если хотим разобраться, нужно будет возиться )
[14:17:24] <zombah> ну всяко
[14:19:59] <zombah> я вообще соберу опять всю инфу и засуну на вики а то что не могу найти концов старых
[14:20:12] <zombah> только логи на пастебине
[14:21:52] <stuw> ок
[14:56:05] * Disconnected (Connection reset by peer).
[14:56:28] * Now talking on #ac100-ru
[14:56:28] * Topic for #ac100-ru is: Канал пользователей смартбука Toshiba AC-100 | Вики: http://ac100.wikispaces.com || use UTF-8 dude || Логи: http://ac100.wikispaces.com/IRC
[14:56:28] * Topic for #ac100-ru set by [email protected] at Thu Apr 3 18:53:32 2014
[14:56:28] -NickServ- You are already logged in as Stuw.
[22:22:42] <brightkill> zombah: почему на тошибе через некоторое время после включения пропадает звук с колонок?
[22:22:50] <brightkill> помогает только ребут
[22:23:33] <stuw-n7> brightkill, logcat и dmesg запости, пожалуйста
[22:23:48] <brightkill> stuw-n7: дак я сейчас уже ребунтулся
[22:24:39] <stuw-n7> как появится проблема, собери логи
[22:24:41] <brightkill> точнее батарейка села
[22:24:45] <brightkill> и он вырубился сам