Включаю драйвер TS в BSP, создал GPIO SPI, примерно как описано здесь, подключил к нему драйвер ADS7846, по первым признакам все нормально - драйвер успешно грузится, активность на SPI линиях "адекватная", прерывание по нажатию срабатывает.
НО!!!
По началу долго не мог понять, в чем дело - некоторые пины GPIO SPI "через раз" работали как надо, иногда просто на них небыло никакой активности, всю BSP перешерстил - не пересекаются они ни с чем.
Потом, вдруг, "волшебным образом" SPI линии заработали как надо, двигаюсь далее, собираю TSLIB (вернее она уже была собрана, по сути с ней адекватность на линиях проверял) и тут выясняется шайтан-момент - при запуске ts_print и ts_print_raw, все работает как положено (координаты правильно показывает), но при запуске ts_calibrate чтение координат не пашет ...
Выяснилось, что при запуске ts_calibrate, входная линия (со стороны ARM) PENIRQ становится выходом и на ней бегают какие то импульсы ...
Интуитивно полагаю, что при открытии фреймбуфера прошел какой то косяк и какой то неправильно смапившийся буфер сводит полтом с ума регистры ввода вывода, кстати, при этом на самом fb все отображается правильно.
Полез копаться в сорцах ...
Стал поочередно отковыривать функции на предмет глюка, выяснилось, что с самой инициализацией fb проблем нет, а вот вывод уже ломает картину ...
Может кто какой криминал заметит?
полистал выложенный исходник, в первом приближении все нормально. Из низкоуровневых обращений вижу __setpixel.
Я бы более внимательно проверил исходники фреймбуфера 9Г45, может там идет "левое" или неправильное переназначение пина, типа отрабатывали драйвер экрана на внешнем прерывание и забыли закоментировать..
например в драйвере экрана НУК950 присутствуют вот такие строки непонятной нужности:
Можно попробовать для начала убрать все из п/п main и оставить открыть/закрыть фреймбуфер - если глючки пропали, то искать строку их вызывающую..
Честно говоря слабо представляю как может драйвер fb влиять на работу устройства ввода :) Я бы для начала попробовал отключить fb в ядре и проверить что с event device что-то действительно валится - простым cat.
Сам драйвер FB вроде не причем, если запустить проигрывание AVI или в графической консоли весь экран забить, PENIRQ остается PENIRQ, а вот стоит запуститть ts_calibrate или ts_test, как начинаются чудеса ...
Причем, выбери я другой GPIO пин, наверное и не заметил бы даже, но это все причина серьезно призадуматься - как в системе с защищенной памятью такое может происходить ...
Сам контроллер тачскрина (и все что с ним связано) работает нормально, если запускать ts_print (ts_print_raw) координаты читаются правильно, PENIRQ ведет себя как положено, просто какой тогда смысл в этой TSLIB, если нельзя откалибровать.
Запросто - вот тут мапятся физические адреса памяти в адресное пространство пользовательского процесса
если VSCREENINFO имеет некоректные значения или структура обрабатывается неправильно то можно смапить "случайно" и память io практически любых регистров и заслать туда мусор. Ошибка может быть и в ф-ции mmap - многие драйверы fb переопределяют ее на свою реализациюю
PS думаю что в твоей реализации пплаты используется другая область физической памяти нежели в оригинальной плате, fbcon работает через read/write и поэтому это не сказалось. в общем в первую очередь посмотри что в драйвере fb задан правильный адрес физической памяти
Как уже говорил, я пробовал коментарить содержимое всех функций вывода, оставив только open_framebuffer и close_framebuffer, при этом ts_calibrate уже не ломала PENIRQ (хотя и не показывала ничего).
Тоже первым делом на это подумал, распечаталд все используемые значения, все правильно передается.
Собрал Qt, тот же эффект, что склоняет мысли в сотону бага драйвера FB (а может и силикона) ...
Как выяснилось, описываемого эффекта не наблюдается в 16 битном режиме цветности (обнаружил совершенно случайно, отчаявшись понять причины происходящего).
Скорей всего при 16 битах при записи просто недотягивает до регистров gpio. Есть подозрение на баг в описании ресурсов lcdfb, попробуй так:
добавь в файле board-sam9m10g45ek.c в структуре ek_lcdc_data инициализацию smem_len :