Подключил панельку SK-WF43BTIBED0TP-Plug, теперь пытаюсь понять, как к ядру для нее драйвер FB прикрутить ...
Лирическое отступление, LCD модуль этого контроллера в LQFP корпусе не имеет возможности формировать развертку обычных TFT (в их терминологии DOTCLK интерфейс), только VSYNC, DVI и процессорный интерфейс (с учетом которого и разведен внешний разъем платы для прямого подключения плага расширения).
Механизм взаимодействия с панелями процессорного интерфейса примерно следующий: настраиваем указатель на требуемый к передаче блок данных, указываем количество передаваемых данных, LСDIF модуль в режиме мастера на шине читает данные с внешней памяти, выдает их на LCD и генерирует прерывание по окончании блока.
Насколько я понимаю, мастером на шине делают LCDIF модуль для его исключительной приоритетности при доступе к внешней памяти, что особо не требуется с панелями на процессорном интерфейсе (нет необходимости формировать четкие тайминги развертки), в сорцах LCDIF есть упоминания о DMA ...
Это все теория, как на практике прикрутить к "двухслойному" драйверу (драйвер панели + драйвер FB) экрана панель, пока без понятия .
Там не двухслойный драйвер - для разных панелей инит разный, поэтому для универсальности ф-ции касающиеся работы lcd-матрицы вынесены в отдельный модуль, чтобы можно было не исправляя основной драйвер менять панели. В нашем случае нужно будет сделать немного больше работы - там системный интерфейс не предусмотрен в модулях.
Я пока исходники просматриваю фрискейловские - там полный бардак в применяемых стилях, очень трудно читаются. Такое ощущение что писалось все как в Простоквашино - начал дяд Федор, потом продолжил кот а дописывал Шарик. Пипец полный. В одном месте написано как принято в linux через writel, в другом через подстановки и дефайны как принято у фрискейловцев, притом стиль дурацкий потому что у одих регистров кроме адреса есть дополнительные регистры для установки, очистки, переключения а у других нет - только один адресный регистр, постоянно приходится рыться в даташите.
Не проще а просто по другому и не получится :) Кроме него и для панели надо делать и еще там куча ф-ций разбросана по всему ядру - например mux пинов - надо разобраться что к чему, там шины в их панелях 16 битные, у нас 8.
не уловил суть проблемы - индикатор не отдается по GPIO или iMX упрямится при переходе в GPIO или не прикрутить индикатор во фреймбуфер?
в каком месте буксуем?
режим когда он может сам хватать блок данных из внешней памяти
Вот в ходе экспериментов пока тупо не можем получить хотя бы какое то движение на LCD пинах и стробах в обоих режимах.
Обмен через GPIO, конечно можно настроить (как в драйвере с 9260), но это уже крайний вариант.
т.е. в самом АРМе не поднимается контроллер экрана?
могу предложить путь сложный и скучный:
допустим контроллер выключен логически и все пины подконтрольны. экран соединен по штатной схеме.
"на коленке" пишется примитивная прога, которая сама шевелит все пинами изображая GPIO-интерфейс.
скорость тут не важна, но - что достигается:
- проверка правильности соединения
- полная наглядность и подконтрольность..
безусловно, такое можно провернуть, если все пины подконтрольны :)
в случае упрямости контроллера надо искать как его разрешить, проверить разрешения тактовой на модуль и еще кучу мест
помнится, потребовалось в PXA270 шевелить пином - пришлось понять как получить разрешение на _разрешение_ им управлять :)))
в вашем случае, наверно полезно выводить диагностику состояния ключевых регистров до и после попытки запустить драйвер фреймбуфера (я на мнуке созерцал крайне забавные вещи) - возможно что драйвер делает вид что запускается, но с кем-то конфликтует..
зы выдвинулся в сторону дома..
23.05.2010 19:18 
23.05.2010 19:19
.
