[12:51:38] <zombah> добрый день всем
[13:07:08] <zombah> stuw: как то интересно добавил папку paz00_keyHandle как subproject, через веб интерфейс хрен посмотришь ее 8)
[13:07:40] <stuw> ага, я собирался переделать. Локально выкачано было, мне потом влом было переделывать
[13:07:49] <stuw> у меня в профиле проект этот лежит
[13:08:01] <stuw> надо его затащить в cm-paz00
[13:08:24] <stuw> точнее вместо subproject'а папку с проектом добавить
[13:08:31] <stuw> чтобы не париться с подпроектами
[13:09:00] <zombah> можно отдельным проектом оставить его repo его подцепит и так
[13:14:50] <stuw> там гемора не будет, с тем, что один проект внутри другого ?
[13:36:07] <zombah> stuw: ну мы можем его и по другому пути положить, в /hardware например пофиг ведь
[13:37:16] <stuw> zombah: https://github.com/zombah/android_device_toshiba_paz00-common/tree/jellybean-paz00-key-handler
[13:37:42] <stuw> zombah: отсмотри патчи, может описание где поменять надо
[13:38:41] <stuw> патч в android_device_toshiba_ac100 можно и старый оставить
[13:39:12] <stuw> zombah: новую версию патчей не пробовал, но отличий в коде быть не должно - я только переразбил на разные коммиты
[13:39:53] <stuw> zombah: если работает, затягивай в свой основной бренч. А бренчи jellybean-func-keys надо будет грохнуть, чтобы не мешались
[13:47:24] <zombah> да грохать то зачем они ни чем не мешают
[13:54:58] <zombah> приноровился к таймауты на кнопке питания, нитак и долго вполне норм
[14:17:26] <stuw> да, там чуть раньше отпускаешь, меню само появится
[14:17:41] <stuw> когда много бренчей запутаться легко :)
[14:18:00] <stuw> сейчас главное, чтобы патчи собирались и работали без проблем
[14:21:42] <zombah> да их же не руками цепляешь а репо по списку качает, мне кажется пофиг пускай весят
[14:22:10] <zombah> когда раньше отпускаешь легко попасть на короткое нажатие
[14:24:28] <zombah> проще привыкнуть к долгому
[14:27:19] <stuw> дело привычки :)
[14:34:06] <zombah> главное что работает и лучше чем раньше
[14:35:04] <stuw> лучше ?
[14:35:25] <zombah> stuw: конечно, долгое нажатие есть, раньше не было
[14:35:46] <stuw> разве? мы же вроде делали его через powerbtnd и раньше
[14:36:18] <stuw> может это сильно раньше было и последние несколько версий этого не было :)
[14:37:01] <zombah> stuw: нет через powerbtn оно работало только по короткому, на длинное в 3.1 кнопка питания вообще не реагировала
[14:37:11] <stuw> аааа
[14:40:58] <stuw> zombah: по проблеме долгого форматирования - в рекавери и самом андроиде есть dd? Может им стоит посмотреть скорость чтения/записи ?
[14:41:26] <zombah> stuw: да надо посмотреть у меня пока руки не дошли до этого, все пытаюсь с дерганьем графики разобраться
[14:41:46] <zombah> уже кучу всего перепробовал но никак
[14:41:48] <stuw> ну да, графика не очень плавная
[14:42:08] <stuw> это из-за количества памяти используемого или еще что ?
[14:42:17] <zombah> а вот если включить Disable HW overlays в developer options то сразу становится все ок
[14:42:33] <zombah> stuw: пробовал увеличивать буфер до 192мб, не помогает
[14:42:40] <stuw> а в dmesg есть что ?
[14:42:43] <zombah> 256 у нас не вариант
[14:42:57] <stuw> ну да, нам бы 128 или даже 64 ))
[14:43:12] <zombah> stuw: на 128 есть ругать nvmap alloc, но над 160 ее уже нет но проблема продолжается
[14:43:47] <zombah> 64 точно никогда работать не будет это уже много раз проверялось столько для 3д не достаточно
[14:44:04] <zombah> а вот 128 с 3.1/2.6.x работало отлично
[14:44:08] <zombah> а тут такая фигня
[14:44:36] <stuw> надо поискать, что в андроиде меняет эта опция
[14:44:44] <zombah> чую digetx чет подкрутил под себя т.к. у них 256 но пока не признается 8)
[14:44:45] <stuw> в исходниках
[14:45:21] <zombah> stuw: ну кеш текстур не влазит в память выделенную под него, чего искать то
[14:45:54] <zombah> но почему проблема с overlay я не понимаю
[14:46:24] <stuw> что за кеш текстур? и что за оверлей и где он в ядре живет?
[14:47:45] <zombah> stuw: вот этот кеш https://github.com/ac100-ru/picasso-kernel/blob/3.18-paz00/arch/arm/boot/dts/tegra20-paz00.dts#L36
[14:48:44] <zombah> а оверлей как я понимаю вот это в ядре https://github.com/ac100-ru/picasso-kernel/tree/3.18-paz00/drivers/staging/tegra/video/dc
[14:49:52] <zombah> вот тут видно что туда в этот nvmap засовывается /sys/kernel/debug/nvmap/generic-0/*
[14:50:22] <zombah> на хом скрине интерфейся у меня там обычно занято 55-65 метров всего
[14:50:39] <zombah> поэтому я не шибко верю в то что размер тут роляет
[14:50:57] <zombah> или покрайней мене не для именно этих притормаживаний
[14:51:21] <stuw> ты у digetx спрашивал, что он думает по этому поводу ?
[14:51:34] <zombah> stuw: да он несколько идей высказал
[14:52:13] <zombah> stuw: частота клоков памяти и размер nvmap carveout этого
[14:52:40] <zombah> stuw: я добавил emc таблицы памяти из 3.1 но не пойму пока как проверить что они пашут
[14:52:59] <stuw> что за таблицы ?
[14:53:40] <zombah> размер carveout увеличивал до 192 никакого эффекта
[14:53:43] <zombah> stuw: https://github.com/ac100-ru/picasso-kernel/commit/f42a14aa3641b54a3e226f20fe68bf8bd02aabf9
[14:54:30] <zombah> stuw: у разной памяти нашей есть некий ккд ram-code 0 или 1 и по этой информации применяется конфиг для памяти
[14:54:42] <zombah> для 165мгц и 333мгц
[14:54:53] <zombah> 166.5 вернее и 333
[14:55:11] <zombah> как в 3.1 ядре, но там EMC этот срал в дмесг инфой, а тут тишина
[14:55:39] <zombah> чую что может u-boot не передает ram-code этот можеи и конфиги памяти не применяются
[14:55:51] <zombah> но какая текущая частота у памяти пока не нашел как посмотреть
[14:57:04] <zombah> плюс у меня еще есть сокральная мысль
[14:57:14] <zombah> что в 3.18 нужен аналог вот такого патча https://github.com/zombah/android_kernel_toshiba_ac100/commit/046a597b9cc3e2bd7b707887530827cbd607b275
[14:57:28] <zombah> но он у меня пока в голове не укладывается
[14:57:35] <stuw> ну в драйвер (./arch/arm/mach-tegra/tegra2_emc.c) можно и логов напихать )
[14:58:19] <stuw> почему не укладывается ?
[14:58:41] <zombah> не пойму где это там живет
[14:59:10] <zombah> видимо это надо через dt делать
[15:01:42] <zombah> но я не понимаю нужно вообще или нет, надо попробовать в sysfs найти эти значения чтоли посмотреть их текущие состояния
[15:08:45] <stuw> drivers/clk/tegra/clk-tegra20.c - возможно тут, но как-то все не тривиально :)
[15:09:09] <stuw> ну ничего, с клоками тоже надо разбираться, чтобы сон дебажить ))
[15:10:18] <zombah> я помню когда еще в 2015 первый раз попробовал 3.18 этот у меня слип почти заработал, много всего интересного в лог писал
[15:10:31] <zombah> а счас чет не сообразу как я такого эффекта добился 8))
[15:11:23] <zombah> одно сообщение в дмесг мол слип, но диод питания не моргает
[15:11:44] <zombah> такое чувство что он даже не пытается уснуть
[15:11:47] <zombah> но почему не ясно
[15:12:15] <zombah> попробовал вручную echo mem > /sys/power/state
[15:12:28] <zombah> экран вырубился но лог пустой
[15:12:51] <zombah> может что в ядре забыл включить
[15:13:26] <stuw> drivers/clk/tegra/clk.c - о, вот тут похожие дефайны есть, можно покопать
[15:13:58] <stuw> по сну - надо пробовать на разных стадиях. Ща на вики гляну, должна быть инфа, с моих последних раскопок
[15:16:16] <zombah> во PM_TRACE я кажись не включил
[15:16:21] <zombah> счас добавлю
[15:16:44] <stuw> zombah: cat /sys/kernel/debug/clock/clock_tree пробовал ?
[15:18:09] <zombah> счас попробую
[15:18:24] <zombah> stuw: PM_TRACE похоже теперь X86 только
[15:18:47] <stuw> он вроде всегда был x86 %)
[15:18:56] <stuw> PM_DEBUG
[15:19:16] <stuw> я вроде PM_DEBUG использовал
[15:19:47] <zombah> PM_DEBUG включен
[15:20:16] <zombah> cd: /sys/kernel/debug/clock/clock_tree: No such file or directory
[15:20:27] <zombah> system/bin/sh: cd: /sys/kernel/debug/clock: No such file or directory
[15:20:47] <stuw> дебаг смонтирован? если да, попробуй find
[15:20:53] <zombah> ./clk/clock
[15:20:53] <zombah> ./mmc1/clock
[15:20:53] <zombah> ./mmc0/clock
[15:21:01] <stuw> find /sys/kernel/debug -name "*clock*"
[15:21:29] <zombah> во да в clk похоже все
[15:22:35] <zombah> root@android:/sys/kernel/debug/clk/2d # cat clk_rate
[15:22:38] <zombah> 300000000
[15:22:48] <zombah> root@android:/sys/kernel/debug/clk/2d_emc # cat clk_rate
[15:22:51] <zombah> 0
[15:24:03] <zombah> root@android:/sys/kernel/debug/clk/mpe # cat clk_rate
[15:24:06] <zombah> 333000000
[15:24:09] <zombah> mpe есть
[15:24:22] <zombah> так что там еще то было
[15:24:37] <zombah> epp,vi,3d
[15:25:47] <zombah> 2d/3d_emc пустые, а остальные норм все
[15:27:59] <zombah> похоже они инициализированы все нормально
[15:30:00] <zombah> хотя с usb udc клоками то должно быть чтот не так таки,
[15:30:20] <zombah> т.к. оно заводится только если вставить кабель в комп до включения питания
[15:30:26] <zombah> а если после то фиг
[15:31:15] <zombah> помню была такая ботва когда только u-boot заводили..и чего то там не хватало
[15:32:05] <zombah> надо кстати попробовать udc в u-boot самом, в 2016 он ведь есть уже
[15:40:20] <zombah> вот по этому патчу если судить https://github.com/digetx/picasso-kernel/commit/964333b5b4844bea59f05ce4095ba8742bc55f41
[15:40:37] <zombah> то должны быть значения у всех *_emc
[15:41:41] <zombah> чет видно с emc не так
[15:53:16] <stuw> клоки сравнивал для usb ?
[15:53:29] <stuw> в смысле в двух случаях с usb
[15:58:26] <stuw> и dmesg желательно сравнить
[16:06:08] <zombah> еще нет, сравню
[16:11:19] <stuw_> zombah: какое полное сообщение для nvmap alloc ? pr_err("avp_lib: can't nvmap alloc for lib '%s'\n", lib->name); - имя либы печатается ?
[16:12:28] <zombah> stuw_: nvmap_carveout_alloc: still can't allocate 2490368 bytes, attempt 2!
[16:14:23] <zombah> в конце
[16:18:46] <stuw_> NVMAP_CARVEOUT_COMPACTOR в конфиге есть? Какой конфиг используется (а то я запамятовал) ?
[16:19:27] <stuw_> используется
[16:20:00] <zombah> tegra_paz00_android_defconfig
[16:20:05] <zombah> да мне кажется он включен
[16:22:31] <zombah> вообще я конфиг слизал с picasso
[16:22:44] <zombah> можно по аналогии с 3.1.10 попробовать
[16:23:10] <zombah> там слегка отличались опции насколько я помню
[17:17:34] <zombah> счас пожалуй затестю конфиг как в 3.1 посмотрю что будет
[18:56:15] <zombah> со старым конфигом еще хуже
[18:56:23] <zombah> вообще курсором не подвигаешь
[18:57:52] <zombah> но правда Disable HW overlays также все фиксит
[19:09:50] <zombah> так в /sys/kernel/debug/nvmap/generic-0/ пишет что 450мб клиентские
[19:10:00] <zombah> странно
[19:10:15] <zombah> diff --git a/arch/arm/configs/tegra_paz00_android_defconfig b/arch/arm/configs/tegra_paz00_android_defconfig
[19:10:18] <zombah> index 716a00f..7f44250 100644
[19:10:21] <zombah> --- a/arch/arm/configs/tegra_paz00_android_defconfig
[19:10:23] <zombah> +++ b/arch/arm/configs/tegra_paz00_android_defconfig
[19:10:26] <zombah> @@ -535,8 +535,9 @@ CONFIG_TEGRA_DOWNSTREAM=y
[19:10:28] <zombah> # CONFIG_TEGRA_CAMERA is not set
[19:10:31] <zombah> CONFIG_TEGRA_GRHOST=y
[19:10:33] <zombah> CONFIG_TEGRA_DC=y
[19:10:36] <zombah> -CONFIG_NVMAP_ALLOW_SYSMEM=y
[19:10:38] <zombah> -CONFIG_NVMAP_CARVEOUT_KILLER=y
[19:10:41] <zombah> +# CONFIG_NVMAP_PAGE_POOLS_INIT_FILLUP is not set
[19:10:43] <zombah> +CONFIG_TEGRA_DSI=y
[19:10:46] <zombah> +CONFIG_TEGRA_NVHDCP=y
[19:10:49] <zombah> # CONFIG_IOMMU_SUPPORT is not set
[19:10:51] <zombah> CONFIG_MEMORY=y
[19:10:54] <zombah> видим CONFIG_NVMAP_ALLOW_SYSMEM так влияет
[19:11:09] <zombah> надо посмотреть что он делает, как то странно
[19:11:25] <zombah> я думал наоборот он так будет прикован к carveout
[19:11:39] <zombah> а получается наоборот что ли
[22:21:21] <zombah> так надо пожалуй попробовать только killer этот отключить
[22:53:50] <stuw__> я думаю без киллера жопа будет )
[23:01:46] <zombah> ну в 3.1 он у нас отключен был и было норм
[23:06:54] <stuw__> ну посмотрим :) может я и не прав
[23:11:29] <zombah> у нас кстати был похожий баг раньше, в одной из следующих версий андроида
[23:12:20] <zombah> и решал я его тогда враппером поверх блоба hwcomposer'а
[23:12:31] <zombah> надо его попробовать будет