Доводилось ли кому-либо работать с Интелловским (в прошлом) PXA270 ? Такие обычно шли в PDAи и подобные штуки помимо прочих вариантов.
В особенности интересует setup его встроенного LCD controllerа.
У нас в нем бежит Linux, программер на данный момент не доступен, все что известно пока так это несколько данных которые он ему давал через его APIи. Давал резолюцию, формат RGB данных требуемую частоту pixel clock на выходе в виде кол-ва ps (picoseconds) в периоде.
Что не понятно - как и где через те-же APIи задавать ему кол-во и местоположение пикселей в строке, кол-во и местоположение пустых строк в кадре.
Ессно у CPU есть релевантные регистры где это все устанавливается напрямую либо косвенно, но нет пямого доступа туда, только через APIи.

Я сам не программер, но возможно кто подскажет как на сие смотрет, тогда я бы постучался к программеру обснив ему куда смотреть и что расшифровывать (код не его).

Спасибо.

Количество пикселей в строке, если я правильно понимаю о чём идёт речь, однозначно определяется разрешением, или, по Вашему, "резолюцией".

Собственно в LCD-контроллере PXA270 количество пикселей в строке (для Base Screen) задаётся в LCCR1[PPL]. В это поле в драйвере пишется с помощью макроса LCCR1_DisWdth, которому в качестве параметра передаётся значение xres. Т.о. задавая разрешение - задаёте и этот параметр.

Что касается положения пикселей в строке - это margin параметры драйвера (внутри это делается аналогично DisWdth: например, LCCR1_BegLnDel(left_margin) -> LCCR1[LCCR1_BLW] - задаёт число так называемых dummy-пикселей в начале строки).

Подробней о поддерживаемые параметры видео-драйвера PXA270 описаны, например, в дереве Linux в Documentation/fb/pxafb.txt. Исходники можно взять, например, здесь: http://www.emcraft.com/technology.php .

Спасибо.
Я за это время проштудировал datasheet процессора, нашел нужные регистры (LCCR1, 2, 3) и т.д.
Другое дело что не в курсе насчет драйверов, софта и т.д. ибо это делает программер а он был в отлучке последние несколько недель. Недавно вернулся, узнал у него что действительно наверняка ненужно будет напрямую задействовать регистры - скорее всего достаточно будет указать необходимые параметры через API/driver а он (драйвер) сам уже установить нужные settings в регистры.
Резолюция действотельно определается заданием кол-ва пикселей в строке + кол-во активных строк в кадре. А частота clockа должна по идее однозначно определятся резолюцией, + заданием кол-ва dummy/blank clocks в строке (в начале и/или в конце) + кол-во dummy/blank lines в начале и/или конце кадра + frame rate.
Т.е. я так понял (от программера) что задав вышеуказанные параметры драйверу (или через API), драйвер сам вычислит необходимую частоту клока и сделает необходимые settings в регистрах клоков.
Я ошибаюсь ?

Не уверен, что частота как-то связана с разрешением. Вернее даже уверен, что она совсем с ним не связана

Драйвер pxafb действительно задаёт частоту Pixel Clock с помощью делителя (позволяя обеспечивать Pixel Clock от LCLK/2 до LCLK/512, где в свою очередь LCLK варьируется от 13МГц до 104Мгц), но значение pixclock определяется отдельным, независимым, параметром драйвера: pixclock. Или через FrameBuffer API: fb_set_var(info, var), полем var->pixclock.

ОК, спасибо за инфу.
Что я уверен так это то что базовая частота дисплея (pixel clock) 100% завязана на запрограммированое кол-во клоков в строке (total), кол-во строк в кадре (total) и требуемый frame rate. Три этих параметра вместе дают частоту pixel clockа при параллельной передаче данных (т.е. при формате когда по одному клоку передается цельный пиксель). Ну а резолюция есть ведь часть определения total clocks in line, total lines in frame.

Честно говоря не понял что вы имеете ввиду: ежели драйвер сам вычисляет и задает частоту pixel clockа устанавливая делители (скажем исходя из кристала 13 MHz), то почему нужно еще раз отдельно указываеть ему частоту параметром ?
Либо имелось ввиду что я задаю частоту драйверу параметром pixelclock а он сам вычисляет факторы делителей и их устанавливает ?
Но тогда не совсем логично получается, ибо что ежели я ему задам частоту которую невозможно точно получить цельными делителями в рамках 2-512 ? Кроме того, что ежели я ему задам частоту которая не сходиться с общим кол-вом пикселей в кадре ?

Я не знаком с програмными аспектами драйвера, но мне кажется вполне логично было-бы для драйвера задать ему параметры кадра (общее кол-во клоков в строке, общее кол-во строк в кадре, frame rate, кол-во пустых клоков в строке до/после активной части, кол-во пустих строк до/после активной части, ширины HSYNC/VSYNC пульсов) а также исходную частоту его кристалла, и тогда драйвер однозначно сможет вычислить необходимые делители...
Хотя стоп....кажется и тут не все однозначно - ведь можно указать параметры видео под которые невозможно получить точный pixel clock исходя из 13 MHz кристалла и 2-512 делителей....
Значит видимо данное соответствие лежит на совести проэктировщика...

да, именно это и имелось ввиду.



просто получите ближайшую к желаемой величину.



Честно говоря не вижу соответствия. Опуская всю экзотику связанную с margin/sync, Вы задаёте три независимых параметра: pixclock, xres, yres. Из них контроллер LCD сам рассчитывает частоты/времена line_clock = pixclock * xres и frame_clock = line_clock * yres. Всё. При чём тут общее количество пикселей (xres * yres) в кадре (каждые frame_clock) ?


да, получается так.

ОК, но резолюция по определению есть кол-во активных клоков в строке х на кол-во активных строк в кадре. Но кроме активных у нас есть обычно определенные кол-ва blank/dummy клоков в строке и определеное кол-во blank/dummy строк в кадре. Эти blank/dummy клоки и строки могут распологаться до, после либо и до и после активных зон (в строке и в кадре соответственно).
Это означает что частота клока определяест общим кол-вом клоков в кадре, включая требуемые dummy/blank таковые, а не только резолюцией.
Пример (конкретный пример реального проэкта):
Дисплей 320х240, его timing требует 520 клоков в строке (пиксель передается по каждому клоку) и 275 строк в кадре (progressive scan), 50 кадров в секунду. Значит частота определается не резолюцией а полным кол-вом клоков/строк в кадре:
520х275х50 = 7.15 MHz.
При этом: HSYNC_freq = 275 x 50 = 13.75 kHz; VSYNC_freq = 50 Hz.

Как описано в его datasheet, LCCR1/LCCR2 регистры как раз и описывают резолюцию (т.е. активную зону) + все необходимые blanks и их расположение в строке/кадре.

Или мы говорим об одном и том-же но с разных сторон ?

Но ведь количество кадров в секунду (частота обновления) - это явно не фиксированная величина. Вот, например, смотрю док на 4.3 SHARP WQVGA Touch TFT - здесь правда не частота обновления в качестве параметра выставлена, а частота клока: написано, что минимальная частота клока есть 7.83MHz, максимальная - 9.26 MHz. Так что хочешь покрасивей картинку - повышай клок используя pixclock параметр драйвера; если же терпимо, чтобы моргание было заметно (но зато например шины процессора поменьше загружены будут, да и экономней в смысле потребления) - с помощью того же параметра клок понижай . При всём при этом разрешение остаётся постоянным. Так что всё же никакого противоречия в независимости xres, yres, pixlock всё же нет.


да в общем-то да

Ну можно сказать частота кадров в секунду обычно фиксирована апплиакцией, дисплеи-же обычно позволяют несколько фиксированных frame rates на выбор проэктировщика, и конкретный выбор обычно зависит от аппликации.
Ессно, имея частоту клока можно получать различные frame rates, меняя резолюции и blank data.
Можно например понижать клок при той-же резолюции и frame rate, но тогда автоматом понижаем кол-во balnk data (пустых пикселей в строке и пустых строк в кадре) и т.д.

Я моем случае например стоит задача согласования 2х разных по совей натуре дисплеев: один OLED, другой TFT. О них разные форматы данных и разные требования к таймингу, вот и приходится искать "общий знаменатель" по таймингу согласовывая их в FPGAе через буфер памяти...

Вот возник еще вопрос:
можно ли из него (PXA270) вытащить видео на LCD в формате CCIR656 ? (т.е. 8 бит CbYCr с кодированными syncs EAV, SAV и т.д.) ? Сейчас проверяю по его datasheet - пока не вижу возможной конфигурации выхода таким образом...

Немного не в тему. Подскажите, а что у Вас за LCD cо входом 656. Делаю камеру с таким выходом и с прогрессивной разверткой, а куда подать посмотреть - не знаю.