Ядро Linux для 1892ВМ14Я. Руководство программиста¶

О документе¶

Документ содержит описание основных подсистем и драйверов ядра Linux, реализованных для поддержки аппаратуры СнК 1892ВМ14Я и модулей на базе СнК.

Ядро Linux поддерживает модули следующих ревизий:

Салют-ЭЛ24Д1 r1.3;
Салют-ЭЛ24Д1 r1.4;
Салют-ЭЛ24Д1 r1.5;
Салют-ЭЛ24Д1 r1.5 с установленным навигационным радиомодулем RF2Chan v2;
Салют-ЭЛ24Д2 r1.1;
Салют-ЭЛ24ОМ1 r1.1 с установленным Салют-ЭЛ24ПМ1 r1.1 или Салют-ЭЛ24ПМ1 r1.2;
Салют-ЭЛ24ОМ1 r1.2 с установленным Салют-ЭЛ24ПМ1 r1.2, Салют-ЭЛ24ПМ2 r1.0 или Салют-ЭЛ24ПМ2 r1.1.

Файлы DTS *.dtsi, *.dts расположены в дереве исходных кодов U-Boot arch/arm/dts/*.dts*. Пути до прочих файлов приведены относительно корня дерева исходных кодов Linux.

Подсистема управления тактовыми сигналами¶

Управление тактовыми сигналами и частотами в ядре Linux реализовано с использованием Common Clock Framework. Тактовые сигналы микросхемы описаны в виде дерева в файле mcom02.dtsi. Для управления тактовыми сигналами и частотами используются следующие драйверы, описанные в drivers/clk/elvees/clk-mcom.c:

mcom-clk-gate;
mcom-clk-divider;
mcom-clk-mux;
mcom-clk-pll;
mcom-cmctr.

Для корректного управления тактовыми сигналами каждый драйвер устройства, входящий в состав ядра Linux, должен реализовывать:

При инициализации драйвера:
1. Захват необходимого для устройства тактового сигнала, используя функцию clk_get().
2. Включение тактового сигнала, используя функцию clk_enable().
При удалении драйвера:
1. Выключение тактового сигнала, используя функцию clk_disable().

При инициализации подсистемы управления тактовыми сигналами происходит начальная настройка всех PLL и делителей частот микросхемы. Устанавливаемые при инициализации значения множителей PLL и делителей частот описаны в файле mcom02.dtsi.

Драйвер контроллера SPI dw_spi_mmio¶

Драйвер dw_spi_mmio управляет контроллерами SPI0 и SPI1 СнК 1892ВМ14Я.

Драйвер поддерживает следующие возможности:

Работа в режиме ведущего устройства.
Использование GPIO в качестве сигналов CS.
Настройка работы контроллера: фазы (CPHA) и полярности (CPOL) сигнала SCK, полярности сигнала CS (при использовании GPIO в качестве CS).
Поддержка слов длиной 8 и 16 бит.
Управление скоростью передачи в зависимости от ведомого устройства.

Ограничения драйвера:

Не поддерживается передача данных с помощью DMA.
Не поддерживается передача слов данных младшим битом вперед.

Драйвер контроллера PWM pwm-mcom¶

Драйвер pwm-mcom управляет контроллером PWM 1892ВМ14Я. Драйвер реализует стандартный интерфейс PWM

Файл с исходным кодом драйвера — drivers/pwm/pwm-mcom.c. Описание DTS bindings представлено в файле Documentation/devicetree/bindings/pwm/elvees,mcom-pwm.txt.

Ограничения драйвера:

Не реализовано управление каналами OUTB.
Не поддерживается режим счёта PWM-контроллера (PWM API не поддерживает данный режим).
Не реализовано управление предделителем.

Драйвер контроллера дисплея vpout-drm¶

Данный раздел применим к драйверу контроллера дисплея VPOUT СнК 1892ВМ14Я для подсистемы DRM — vpout-drm.

Документация, описывающая текущую версию подсистемы DRM, доступна по ссылке Linux GPU Driver Developer’s Guide.

Исходный код драйвера содержится в директории drivers/gpu/drm/vpout.

На рисунке 10 представлена диаграмма зависимостей компонентов драйвера Direct Rendering Manager (DRM).

10 Диаграмма зависимостей компонентов драйвера DRM

Драйвер обеспечивает следующие возможности:

Разрешение экрана до 1920x1080 пикселей;
Поддержка внешнего HDMI передатчика NXP TDA998x;
Поддержка внешних панелей с заданием параметров дисплея через DTS;
Чтение Extended Display Identification Data (EDID);
Эмуляция фреймбуфера через устройство /dev/fb0.

Ограничения драйвера:

Не поддерживаются чересстрочные видеорежимы (не поддерживаются контроллером дисплея VPOUT);
Не поддерживаются HDMI передатчики отличные от NXP TDA998x;
Не реализована поддержка абстракции плоскостей (plane abstraction);
Не поддерживается атомарная установка видеорежима.

Экспериментальные возможности драйвера, функционал не проверялся на аппаратуре:

Поддержка DSI-дисплеев:
1. Не поддерживается MIPI Display Command Set (MIPI DCS) и Extended Display Identification Data (EDID) DSI-дисплеев, т.к. MIPI DCS не поддерживается в аппаратуре;
2. Фиксированные параметры дисплея (разрешение, FPS) считываются из DTS. Дополнительно в командной строке ядра должно быть указано разрешение и тип DSI-дисплея;
3. В коде драйвера фиксировано количество DSI-линий — 4.

При использовании в качестве устройства вывода HDMI монитора драйвер устанавливает оптимальный для подключенного монитора видеорежим, определяемый по EDID. С помощью параметров ядра (kernel parameters) возможно установить фиксированный видеорежим. Например, следующая строка задает разрешение экрана в 1280×720 пикселей:

video=HDMI-A-1:1280x720

При использовании в качестве устройства вывода DSI-дисплея драйвер устанавливает видеорежим заданный с помощью параметров ядра (kernel parameters). При этом параметры дисплея считываются из DTS. Например, следующая строка задает разрешение экрана в 1280×720 пикселей:

video=DSI:1280x720

Подробное описание параметров ядра, задающих видеорежим, содержится в документе Documentation/fb/modedb.txt.

Драйвер фреймбуфера vpoutfb¶

Для вывода на экран графического окружения на СнК используется подсистема FBDev и драйвер vpoutfb. Директория с исходным кодом драйвера — drivers/video/fbdev/vpoutfb. Драйвер управляет контроллером VPOUT и HDMI-адаптером ITE IT66121.

Алгоритм работы драйвера:

Если в DTS в узле output присутствует свойство compatible=»ite,it66121», то выполнить настройку контроллера ITE IT66121, подключенного по I2C.
Считать из DTS видеорежим и настроить VPOUT для вывода в заданном видеорежиме.
Если в DTS отсутствует видеорежим или тайминги некорректны, или свойство output отсутствует, то настроить VPOUT для вывода в режиме 720p 60 FPS.

Вызов ioctl FBIOPUT_VSCREENINFO с заданием неподдерживаемого режима завершается с -EINVAL. (Следовательно, вызов fbset завершится c ненулевым кодом возврата).

Поддерживаются следующие ioctl:

FBIOGET_VSCREENINFO;
FBIOPUT_VSCREENINFO;
FBIOGET_FSCREENINFO;
FBIOGETCMAP;
FBIOPUTCMAP;
FBIOBLANK;
VPOUTFB_GET_MEMORY_ID.

При появлении прерывания OUT_FIFO_INT блока VPOUT драйвер останавливает и переинициализирует VPOUT. При этом в dmesg печатается сообщение «Caught OUT_FIFO_INT, reinitializing VPOUT».

В драйвере не реализовано:

Чтение EDID HDMI-монитора и ограничение возможных разрешений согласно данным из EDID.
Остановка/запуск VPOUT при отключении/подключении HDMI-монитора.

Примечание

Т.к. автоматическое определение подключения HDMI-монитора отсутствует, драйвер может быть выключен по умолчанию. Загрузка драйвера выполняется командой modprobe vpoutfb.

Примечание

Для управления видеорежимами может использоваться утилита fbset и файл fb.modes.

Драйвер считывает видеорежим из DTS в соответствии с описанием в Documentation/devicetree/bindings/video/display-timing.txt. В DTS-файле mcom02.dtsi описан формат цветовых компонентов изображения, устанавливаемые при инициализации драйвера. Подробное описание полей узла устройства VPOUT представлено в файле Documentation/devicetree/bindings/fb/vpoutfb.txt.

Примечание

Модуль vpoutfb используется консолью – перед выгрузкой модуля необходимо отключить консоль от драйвера:

echo 0 > /sys/class/vtconsole/vtcon1/bind
modprobe -r vpoutfb

Драйвер VPU avico¶

Общие сведения¶

Драйвер avico управляет VPU VELcore-01 и реализует аппаратное кодирование и декодирование видео по стандарту H.264. Драйвер реализован с использованием подсистемы V4L2 и предоставляет стандартный программный интерфейс для кодирования/декодирования и управления.

Кодирование видео¶

Поддерживается входное несжатое видео с форматом пикселей M420.
Максимальная ширина кадра — 1920 пикселей.
Максимальная высота кадра — 4096 пикселей.
Поддержка кодирования видео с разрешением кратным 2 по ширине и высоте.
Возможность установки FPS видеопотока.
Возможность установки параметра QP с помощью контролов:
- V4L2_CID_MPEG_VIDEO_H264_I_FRAME_QP;
- V4L2_CID_MPEG_VIDEO_H264_P_FRAME_QP;
- V4L2_CID_MPEG_VIDEO_H264_CHROMA_QP_INDEX_OFFSET.
Возможность установки IDR-кадра с помощью контрола V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME.
Возможность установки размера GOP с помощью контрола V4L2_CID_MPEG_VIDEO_GOP_SIZE. Новый размер GOP применяется со следующего IDR-кадра после завершения текущего GOP. Чтобы применить новый размер GOP на следующем кадре, нужно запросить IDR-кадр с помощью контрола V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME.
Поддержка более одного потока кодирования видео. Максимальное число поддерживаемых потоков кодирования зависит от ширины и высоты кадра, количества запрошенных V4L2-буферов и объема памяти, которая может быть выделена с помощью Contiguous Memory Allocator (CMA). Теоретическое максимальное число поддерживаемых потоков кодирования можно вычислить с помощью формулы:

$n = M / (W * (128 + (2 * B_c + 3/2 * (B_o + 1)) * H))$

где M — размер памяти, которая может быть выделена с помощью CMA, W — ширина кадра, H — высота кадра, $B_o$ — количество V4L2-буферов output-интерфейса, $B_c$ — количество V4L2-буферов capture-интерфейса. Дополнительно количество потоков n ограничивается фрагментацией CMA. Производительность кодирования каждого видео понижается с увеличением числа потоков, т.к. используется один аппаратный поток кодирования. Пример реального максимального числа потоков и достигаемой при этом производительности кодирования при QP 23, четырех V4L2-буферов output-интерфейса, четырех V4L2-буферов capture-интерфейса, размере CMA-памяти 128 МБ и частоте VPU 312 МГц:
- 1920x1072 — 4 потока, ~15 FPS;
- 1280x720 — 6 потоков, ~22 FPS;
- 640x480 — 19 потоков, ~18 FPS.
Пример ограничения числа потоков кодирования для обеспечения производительности кодирования ~30 FPS при QP 23, четырех V4L2-буферов output-интерфейса, четырех V4L2-буферов capture-интерфейса, размере CMA-памяти 128 МБ и частоте VPU 312 МГц:
- 1920x1072 — 2 потока, ~30 FPS;
- 1280x720 — 4 потока, ~30 FPS;
- 640x480 — 12 потоков, ~30 FPS.
Поддержка сжатия с постоянным битрейтом с помощью контролов:
- V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE — включение/выключение контроля битрейта;
- V4L2_CID_MPEG_VIDEO_BITRATE — битрейт, бит/с.
Контроль битрейта будет выключен, если число кадров в GOP меньше трёх.
Особенности очереди capture:
- Поддерживаются буферы типов DMABUF и MMAP.
- Буферы должны быть физически непрерывными.
- Буферы типа MMAP выделяются драйвером с помощью CMA и являются физически непрерывными и некешируемыми.
Особенности очереди output:
- Поддерживаются буферы типов DMABUF, MMAP и USERPTR.
- Буферы типов DMABUF и MMAP должны быть физически непрерывными.
- Буферы типа MMAP выделяются драйвером с помощью CMA и являются физически непрерывными и некешируемыми.
- Если буферы типа USERPTR не являются физически непрерывными, выполняется копирование данных из них в непрерывную память с помощью DMA. Это снижает производительность кодирования.

Декодирование видео¶

Поддерживается выходное несжатое видео с форматом пикселей M420.
Поддержка декодирования видео с разрешением до 1920x1072 кратным 16 по ширине и высоте.
Поддержка контрола V4L2_CID_MPEG_VIDEO_GOP_SIZE.
Поддержка события V4L2_EVENT_SRC_CH_RESOLUTION при смене разрешения видео (в т.ч. в начальный момент момент времени, когда разрешение видео неизвестно, см. Memory-to-Memory Stateful Video Decoder Interface).
Особенности очередей capture и output:
- Поддерживаются буферы типов DMABUF и MMAP.
- Буферы должны быть физически непрерывными.
- Буферы типа MMAP выделяются драйвером с помощью CMA и являются физически непрерывными и некешируемыми.

Ограничения драйвера¶

Поддерживается только один аппаратный поток кодирования и один аппаратный поток декодирования.
Несжатое видео имеет нестандартный формат пикселей (M420).
Шаг между яркостными и/или цветовыми строками должен быть кратен 16 байтам.
Для кодирования требуется 180 КиБ памяти XYRAM.
Использование с драйвером delcore30m невозможно, т.к. драйвер avico использует SDMA через API DMA-engine, драйвер delcore30m — непосредственное управление SDMA.
Поддерживается только контроль битрейта в режиме CBR. Контроль битрейта реализован на базе алгоритма, описанного в JVT-G012 и JVT-K049, только частично: при вычислении целевого параметра квантования для P-кадров не учитывается средняя абсолютная разница (MAD) кадра и его прогноза, т.к. VPU не предоставляет доступ к значению MAD, вычисляемому им на этапе оптимизации R-D. MAD может быть вычислен программно, но предполагается, что это повлечет значительное снижение производительности, поэтому вместо модели R-D, описанной в JVT-G012 и JVT-K049, используется модель R-D, описанная в Контроль битрейта при кодировании. Контроль битрейта возможен только при количестве кадров в GOP, равном 3 и более.
Нет возможности менять FPS в процессе кодирования.
Для декодирования требуется выделенная память в двух контроллерах DDR (по 8 МиБ в каждом DDR для поддержки разрешения 1920x1072).
При декодировании сжатый кадр должен быть целиком расположен в одном output-буфере.

При кодировании для обхода проблемы rf#1382 драйвер использует промежуточные буферы в XYRAM для восстановленных и сжатых данных. Всего используется 4 буфера по 45 КиБ (строка макроблоков для кадра шириной 1920 пикселей в формате M420) — 2 буфера для восстановленных данных и 2 для сжатых. В результате реализации обхода проблемы, максимальная ширина кадров ограничилась 1920 пикселями.

При кодировании после каждой строки макроблоков VPU останавливается и драйвер выполняет следующие действия:

Настраивает VPU на другой промежуточный буфер.
Запускает SDMA для копирования данных из промежуточного буфера в DDR.
Запускает VPU на обработку следующей строки макроблоков.

При кодировании для обхода проблемы rf#2003 в обработчике прерывания используется задержка, состоящая из следующих действий:

Ожидание завершения чтения очередных данных исходного и референсного кадров.
Ожидание завершения 80-кратного чтения регистра EVENTS.
Ожидание снятия всех флагов регистра EVENTS, указывающих на текущую работу VDMA.

При декодировании для обхода проблемы зависания rf#1382 драйвер в начале декодирования выделяет буферы DDRx и DDRy в разных DDR, затем каждый кадр выполняет следующие действия:

Копирование входных сжатых данных из буфера пользователя в буфер DDRx с помощью SDMA. DDRx — буфер, в котором находится референсный кадр.
Копирование в VRAM первых двух строк макроблоков из буфера референсного кадра. Данное копирование стало необходимым после перемещения восстановленного кадра в отдельный буфер из общего буфера для референсного/восстановленного кадра. Восстановленный кадр теперь записывается в буфер DDRy.
Запуск декодирования, при этом референсный кадр и сжатые данные считываются из DDRx, а восстановленный кадр записывается в DDRy.
Выгрузка последней строки макроблоков из VRAM в буфер восстановленного кадра.
Копирование полученного в результате декодирования восстановленного кадра из DDRy в буфер пользователя с помощью SDMA.
Буферы DDRx и DDRy меняются местами, так что восстановленный кадр в DDRy используется как референсный кадр в DDRx для следующего кадра.

Использование драйвера¶

При инициализации аппаратного блока драйвер регистрирует два устройства V4L2:

index = 0 — для кодирования,
index = 1 — для декодирования.

В дистрибутиве Buildroot для устройств создаются символические ссылки в директории /dev/v4l/by-path:

# ls -l /dev/v4l/by-path/*codec*
lrwxrwxrwx ... /dev/v4l/by-path/platform-37100000.codec-video-index0 -> ../../video0
lrwxrwxrwx ... /dev/v4l/by-path/platform-37100000.codec-video-index1 -> ../../video1

Контроль битрейта при кодировании¶

Контроль битрейта основан на алгоритме, описанном в JVT-G012 и JVT-K049.

Битрейт контролируется на уровне GOP и на уровне кадра. В задачи контроля битрейта входит вычисление параметра квантования, так чтобы средний битрейт видео соответствовал заданному значению.

В последующем описании используются следующие обозначения:

$f$ — частота кадров (предполагается, что не меняется в процессе кодирования);
$w$ — ширина кадра в пикселях;
$h$ — высота кадра в пикселях;
$i\in\mathbb{N}$ — номер GOP;
$j\in\mathbb{N}$ — номер кадра в пределах GOP;
$N_i$ — количество кадров в i-ом GOP;
$b_i(j)$ — размер j-го сжатого кадра в i-ом GOP;
$B_i(j)$ — число бит, оставщихся в GOP, на момент кодирования j-го кадра в i-ом GOP;
$QP_i(j)$ — параметр квантования j-го кадра в i-ом GOP;
$\overline{QP}^p_i$ — усредненный параметр квантования по всем P-кадрам в i-ом GOP;
$R_i(j)$ — целевой битрейт на момент кодирования j-го кадра в i-ом GOP;
$S_i(j)$ — целевой уровень виртуального буфера (число оставшихся бит) после кодирования j-го карда в i-ом GOP;
$V_i(j)$ — уровень заполнения виртуального буфера сжатых кадров (число бит в буфере сжатых кадров гипотетического референсного декодера) на момент кодирования j-го кадра в i-ом GOP;
$bpp = \frac{R_1(1)}{fwh}$ — целевое число бит на пиксель.

Описание алгоритма¶

Общее число бит для оставшихся кадров в GOP в случае сжатия с константным битрейтом вычисляется по формуле:

$B_i(j) = \begin{cases} \frac{R_i(j)}{f} \times N_i - V_i(j) & \quad j=1 \\ B_i(j-1) - b_i(j-1) & \quad j = 2, 3, \dotsc, N_i \end{cases}$

Уровень заполнения виртуального буфера вычисляется по формуле:

$V_i(1) = \begin{cases} 0 & \quad i=1\\ V_{i-1}(N{i-1}) & \quad \text{other} \end{cases} V_i(j) = V_i(j-1) + b_i(j-1) - \frac{R_i(j-1)}{f} \quad j=2, 3, \dotsc, N_i$

Для первого карда первого GOP значение параметра квантования выбирается на основе целевого числа бит на пиксель по формуле:

$QP_1(1) = \begin{cases} 40 & \quad bpp \leq l1\\ 30 & \quad l1 < bpp \leq l2\\ 20 & \quad l2 < bpp \leq l3\\ 10 & \quad bpp > l3\\ \end{cases}$

Рекомендуемые значения:

$l1=0.15, l2=0.45, l3=0.9$ — для кадров размером QCIF/CIF;
$l1=0.6, l2=1.4, l3=2.4$ — для кадров больше QCIF/CIF.

Для последующих GOP:

$QP_i(1) = max(QP_{i-1}(1) - 2, min(QP_{i-1}(1) + 2, \overline{QP}^p_{i-1} - min(2, \frac{N_{i-1}}{15})))$

$\overline{QP}^p_i = \sum_{j=2}^{N_i} QP_i(j) / (N_i - 1)$

Полученное значение параметра квантования корректируется по формуле:

$QP_i(1) = QP_i(1) - 1 \quad \text{if} \quad QP_i(1) > QP_{i-1}(N_{i-1}) - 2$

Перед вычислением параметра квантования P-кадров вычисляется целевой размер P-кадра.

Целевой размер P-кадра зависит от целевого уровня виртуального буфера. Целевой уровень виртуального буфера определяется для каждого P-кадра согласно размерам первого IDR-кадра и первого P-кадра.

После кодирования первого P-кадра в i-ом GOP начальное значение целевого уровня виртуального буфера устанавливается по формуле:

$S_i(2) = V_i(2)$

Целевой уровень виртуального буфера для последующих P-кадров вычисляется по формуле:

$S_i(j+1) = S_i(j) - \frac{S_i(2)}{N_i - 2}$

Размер, выделяемый для j-го P-кадра в i-ом GOP, вычисляется на основе целевого уровня виртуального буфера, частоты кадров, целевого битрейта и реального уровня заполненения виртуального буфера по формуле:

$\tilde{T}_i(j)=\frac{R_i(j)}{f} + \gamma (S_i(j) - V_i(j))$

где $\gamma$ — константа, равная 0.5.

При вычислении целевого размера кадра также следует учесть число оставшихся бит в GOP для кадра, которое вычисляется по формуле:

$\hat{T}_i(j) = \frac{B_i(j)}{N_i - max(j - 1, 1)}$

Целевой размер P-кадра — взвешенная комбинация $\tilde{T}$ и $\hat{T}$ , которая вычисляется по формуле:

$T_i(j) = \beta \hat{T}_i(j) + (1 - \beta) \tilde{T}_i(j)$

где $\beta$ — константа, равная 0.5.

Для совместимости с гипотетическим референсным декодером целевой размер P-кадра должен также ограничиваться согласно Совместимость с гипотетическим референсным декодером.

В JVT-K049 и JVT-G012 целевой параметр квантования вычисляется на основе квадратичной модели R-D, в которой используется средняя абсолютная разница [1] (MAD) текущего базового элемента (кадр, макроблок или слайс) и его прогноза, полученного на этапе оптимизации R-D. VPU не предоставляет значение MAD для кадра, поэтому вычисление целевого параметра квантования выполняется другим методом.

[1]	MAD для текущего базового элемента вычисляется на основе линейной модели прогнозирования, в которой используется действительный MAD предыдущего базового элемента.

Согласно Rate-Distortion Analysis for H.264/AVC Video Coding and its Application to Rate Control увеличение параметра квантования на единицу приводит к уменьшению битрейта на ~12.5%, таким образом целевой параметр квантования QP может быть вычислен из формулы:

$T = c_1 \times 0.875^{(QP-QP_c)}T_c + c_2$

где T — целевой размер кадра, $T_c$ — размер кадра, полученный при значении $QP_c$ параметра квантования, $c_1, c_2$ — коэффициенты, начальные значения которых соответственно равны 1 и 0. Коэффициенты обновляются после кодирования каждого кадра согласно методу наименьших квадратов.

Данный метод требует двух проходов кодирования каждого кадра, т.к. сначала требуется вычислить размер кадра для заданного QP и в случае необходимости скорректировать QP и повторно выполнить кодирование. Для выполнения одного прохода кодирования предлагается прогнозировать размер текущего кадра для заданного QP на основе размера предыдущего P-кадра по формуле [2]:

$\tilde{T}_c = a_1 T_c + a_2$

[2]	Формула аналогична модели прогнозирования MAD, описанной в JVT-G012 и JVT-K049.

где $a_1$ и $a_2$ — коэффициенты модели прогнозирования размера кадра, $T_c$ — размер предыдущего кадра. Начальные значения коэффициентов соответственно равны 1 и 0. Коэффициенты обновляются после кодирования каждого кадра согласно методу наименьших квадратов.

Для предотвращения резкого изменения качества видео вычисленный параметр квантования корректируется по формуле:

$QP_i(j) = min(QP_i(j-1) + 2, max(QP_i(j-1) - 2, QP_i(j)))$

Полученное значение параметра квантования ограничивается диапазоном [0; 51] и передается в VPU, который выполняет оптимизацию R-D согласно значению QP.

После завершения кодирования кадра значения коэффициентов $a_1, a_2, c_1, c_2$ обновляются.

Примечание - В текущей реализации алгоритма контроля битрейта коэффициенты $a_1, a_2, c_1, c_2$ всегда равны начальным значениям.

Совместимость с гипотетическим референсным декодером¶

Чтобы удовлетворять требованиям гипотетического референсного декодера целевой размер P-кадра также ограничивается нижней границей ( $Z_i(j)$ ) и верхней границей ( $U_i(j)$ ) по формуле:

$T_i(j) = min(U_i(j), max(Z_i(j), T_i(j)))$

Верхняя и нижняя границы инициализируются по формулам:

$Z_i(1) = B_{i-1}(N_{i-1}) + \frac{R_i(1)}{f} U_i(1) = B_{i-1}(N_{i-1}) + be(t_{r,1}(1)) \times \omega$

где $B_{i-1}(N_{i-1})$ — число бит для оставшихся кадров в GOP с номером (i-1), $B_0(N_0)=0$ , $\omega$ — константа, равная 0.9, $t_{r,1}(1)$ — длительность удаления 1-го кадра из виртуального буфера, $be(t)$ — размер данных (в битах), эквивалентный длительности t с коэффициентом преобразования, равным битрейту.

Последующие значения $Z_i(j)$ и $U_i(j)$ вычисляются по формулам:

$Z_i(j) = Z_i(j-1) + \frac{R_i(j)}{f} - b_i(j-1) U_i(j) = U_i(j-1) + (\frac{R_i(j)}{f} - b_i(j-1)) \times \omega$

Примечание - Формулы для $Z_i(j)$ и $U_i(j)$ , описанные выше, представлены в Adaptive rate control for H.264. Предполагается, что в JVT-K049 даны некорректные формулы $Z_i(j)$ и $U_i(j)$ (в формулах вместо размера предыдущего кадра используется размер текущего кадра, который не может быть известен на данном этапе). В документе JVT-G012 целевой размер P-кадра не ограничивается нижней и верхней границами, поэтому формулы $Z_i(j)$ и $U_i(j)$ там отсутствуют.

Драйвер контроллера Ethernet arasan-gemac¶

Драйвер arasan-gemac управляет контроллером Ethernet Arasan GEMAC. Драйвер реализует стандартный интерфейс network devices, описанный в Documentation/networking/netdevices.txt. Обработка RX-прерываний реализована с использованием интерфейса NAPI.

Директория с исходным кодом драйвера — drivers/net/ethernet/arasan.

Драйвер поддерживает выполнение следующих операций из пространства пользователя:

Установка скорости (10/100/1000 Мб/с);
Установка дуплекса (full/half);
Установка уровня сообщений драйвера;
Установка MAC-адреса;
Чтение регистров контроллера Ethernet Arasan GEMAC утилитой ethtool;
Перезапуск автосогласования;
Проверка физического подключения;
Установка MTU кадра в диапазоне 68 – 3500 байт;
Отключение фильтрации пакетов (Promiscuous mode);
Включение приема всех multicast-пакетов (IFF_ALLMULTI);
Поддерживается фильтрация unicast-пакетов по MAC-адресу и multicast-пакетов по hash-таблице.

Примечание

Включение promiscuous mode повышает нагрузку на CPU.

Драйвер не поддерживает:

Управление паузой;
Чтение и запись EEPROM;
Wake-on-Lan;
Управление объединением прерываний.

Подсистема управления энергопотреблением¶

Подсистема управления энергопотреблением Linux определяет модели управления энергопотреблением (подробнее см. Device Power Management Basics):

System Sleep;
Runtime Power Management.

Модель System Sleep¶

В модели System Sleep определены состояния сна (подробнее см. System Power Management Sleep States):

Suspend-To-Idle (s2idle, freeze);
Standby, Power-On Suspend (shallow, standby);
Suspend-to-RAM (deep);
Suspend-to-disk (disk).

Поддерживаемые состояния сна:

Suspend-To-Idle;
Power-On Suspend.

Для энергосбережения в состоянии Power-On Suspend используются свойства драйверов:

поддержка приостановки (suspend) контроллера СнК в драйвере;
поддержка приостановки (suspend) контроллера внешнего интерфейса (приёмопередатчик CAN, Ethernet PHY, и т.д.) в драйвере;
поддержка CPU Hotplug (подробнее см. главу CPU Hotplug).

Поддержка приостановки реализована в драйверах контроллеров СнК:

avico (невозможен переход в Power-On Suspend во время сжатия);
delcore-30m;
designware-i2c;
designware-i2s;
dw-apb-gpio;
dw-apb-uart;
dw-wdt;
dwc2;
sdhci-mcom02.

Поддержка приостановки реализована в драйверах контроллеров внешних интерфейсов модулей на базе СнК:

bcm4329-fmac;
mcp2515;
ft313h.

Поддержка приостановки не реализована в драйверах контроллеров СнК:

arasan-gemac;
dw-apb-ssi;
dw-apb-timer;
mcom-pwm;
mfbsp-i2s;
nfc-v2p99;
pl330;
vinc;
vpout-drm;
vpoutfb.

Поддержка пробуждения (wakeup) реализована в драйверах:

dw-apb-uart (подробнее см. Пример пробуждения по событию от UART);
dw-apb-gpio;
rtc-ds1307 (подробнее см. Пример пробуждения по событию от RTC).

Пример пробуждения по событию от UART¶

Установить UART0 в качестве источника пробуждения:
```
echo enabled > /sys/devices/platform/38028000.serial/tty/ttyS0/power/wakeup
```

Перевести ОС в состояние сна:

echo freeze > /sys/power/state # enter Suspend-To-Idle state

или:

echo standby > /sys/power/state # enter Power-On Suspend state

В терминале на ПЭВМ отправить любой символ в приёмник контроллера UART0.

Пример пробуждения по событию от RTC¶

Перевести ОС в состояние сна до указанного времени пробуждения:
```
rtcwake -s 3 -m freeze # enter Suspend-To-Idle state
```
или:
```
rtcwake -s 3 -m standby # enter Power-On Suspend state
```

Модель Runtime Power Management¶

Для поддержки динамического управления энергопотреблением реализованы:

механизм CPU hotplug;
драйвер управления частотой ядер CPU cpufreq-dt.

Механизм CPU hotplug¶

Механизм CPU hotplug позволяет включать и выключать процессорные ядра, не перезагружая систему, что может использоваться:

для отключения CPU1;
для перехода системы в состояния сна.

Для выключения и включения процессорных ядер используются функции cpu_down() и cpu_up(), описанные в файле kernel/cpu.c.

Использование через sysfs:

Для отключения питания ядра CPU1 необходимо выполнить:
```
echo 0 > /sys/devices/system/cpu/cpu1/online
```
Для включения питания ядра CPU1 необходимо выполнить:
```
echo 1 > /sys/devices/system/cpu/cpu1/online
```

Драйвер управления частотой ядер CPU cpufreq-dt¶

Штатный драйвер cpufreq-dt, позволяет управлять тактовой частотой ядер CPU0 и CPU1 через подсистему CPUfreq.

Директория с исходным кодом драйвера — drivers/cpufreq. Список частот ядер CPU описан в DTS-файле mcom02.dtsi. Описание DTS bindings представлено в файле Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt.

Возможности драйвера:

Регуляторы масштабирования тактовой частоты ядер CPU (CPUfreq governors):
- ondemand (по-умолчанию) — устанавливает тактовую частоту в зависимости от нагрузки на ядрах CPU;
- conservative — похож на ondemand, но более экономный (предпочтение отдаётся меньшим тактовым частотам);
- performance — устанавливает тактовую частоту в максимальное значение;
- userspace — позволяет устанавливать частоту из пространства пользователя.
Управление регуляторами и частотами через sysfs.

Ограничения драйвера:

Не поддерживается управление напряжением питания ядер CPU, т.к отсутствует поддержка в СнК.
Не поддерживается независимое управление частотой ядер CPU, т.к отсутствует поддержка в СнК.

Для установки тактовой частоты ядер из пространства пользователя необходимо:

Выбрать регулятор userspace:

echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Выбрать частоту из поддерживаемых. Список частот доступен в файле /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies.
Установить частоту. Значение частоты передаётся в кГц, например:
```
echo 312000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
```

Подсистема UART в режиме RS-485¶

Для управления полудуплексными приёмопередатчиками RS-485 используются ioctl TIOCMBIS/TIOCMBIC:

int rts_flag = TIOCM_RTS;
ioctl(fd, TIOCMBIS, &rts_flag); // set send mode
ioctl(fd, TIOCMBIC, &rts_flag); // set receive mode

Примечание: модули Салют-ЭЛ24ОМ1 имеют полудуплексный приёмопередатчик RS-485.

Модуль dmatestcontig для тестирования SDMA¶

Модуль dmatestcontig не входит в состав исходных кодов Linux. Описание относится к модулю dmatestcontig из коммита 4896f90a4cd335d91f5b9f2c1457f24baa7f98ce в репозитории модуля. Модуль dmatestcontig основан на модуле dmatest из коммита 9da2b1641a098eb9b00aacbfd7715efb6a503f7b в репозитории ядра Linux.

Модуль dmatestcontig позволяет провести тестирование SDMA с передачей данных, измерением производительности и проверкой правильности переданных данных. Управление SDMA осуществляется через DMA Engine API. Поддерживаемые типы передач: DMA_MEMCPY, DMA_XOR, DMA_PQ. Модуль поддерживает ряд параметров, которые позволяют задать размер буферов, количество повторений передач, максимальное число используемых каналов SDMA, количество потоков ядра, использующих канал SDMA, и др. Особенностью модуля dmatestcontig является то, что он позволяет выбрать типы передач, указывать специфические регионы памяти и включать частоты, которые, например, могут быть необходимы для обеспечения доступа к устройству памяти.

Модуль поддерживает все параметры, которые имеет модуль dmatest, а также добавляет параметры:

tests — типы выполняемых передач данных (по умолчанию выбраны все поддерживаемые типы передач);
memregs — базовые адреса зарезервированных регионов памяти в DTS, в которые каналы SDMA должны адресовать запросы чтения/записи (по умолчанию регион выбирается автоматически);
src — регионы памяти из memregs, в которые каналы SDMA будут адресовать запросы чтения (по умолчанию первый регион, указанный в memregs);
dst — регионы памяти из memregs, в которые каналы SDMA будут адресовать запросы записи (по умолчанию первый регион, указанный в memregs);
clocks — наименования узлов устройств в DTS, описывающих частоты, которых нужно включить, например, для обеспечения доступа SDMA к устройству памяти.

Параметр tests содержит битовую маску типов передач. Значение 1 бита включает тип передачи и наоборот. Соответствие типов передач и номеров бит в параметре:

бит 0 — DMA_MEMCPY;
бит 1 — DMA_XOR;
бит 2 — DMA_PQ.

Резервирование регионов памяти в DTS выполняется согласно Reserved memory regions. Пример резервирования регионов памяти для модулей Салют-ЭЛ24ПМ:

reserved-memory {
  #address-cells = <1>;
  #size-cells = <1>;
  ranges;

  dmatestc_ddr0_reserved: dmatestc_ddr0@0x7f800000 {
    no-map;
    reg = <0x7f800000 0x800000>;
  };
  dmatestc_ddr1_reserved: dmatestc_ddr1@0xdf800000 {
    no-map;
    reg = <0xdf800000 0x800000>;
  };
  dmatestc_xyram_reserved: dmatestc_xyram@0x3a400000 {
    no-map;
    reg = <0x3a400000 0x40000>;
  };
};

Элементы массивов src и dst ссылаются на регионы памяти по индексу региона в массиве memregs. Номер канала SDMA, с которым ассоциируется регион, определяется индексом элемента в src/dst.

Пример загрузки модуля с параметрами tests, src и dst:

modprobe dmatestcontig wait=1 run=1 noverify=1 tests=0x01 \
  max_channels=5 memregs=0x7f800000,0xdf800000,0x3a400000 \
  src=2,2,0,1,1 dst=0,0,2,2,1
modprobe -r dmatestcontig

В примере выше пять каналов SDMA адресуют запросы чтения/записи в регионы памяти следующим образом:

Канал 0: чтение из региона с базовым адресом 0x3a400000, запись в регион с адресом 0x7f800000.
Канал 1: чтение из региона с базовым адресом 0x3a400000, запись в регион с адресом 0x7f800000.
Канал 2: чтение из региона с базовым адресом 0x7f800000, запись в регион с адресом 0x3a400000.
Канал 3: чтение из региона с базовым адресом 0xdf800000, запись в регион с адресом 0x3a400000.
Канал 4: чтение из региона с базовым адресом 0xdf800000, запись в регион с адресом 0xdf800000.

Пример загрузки модуля с параметром clocks:

modprobe dmatestcontig run=1 noverify=1 memregs=0x7f800000,0x3a400000 \
  src=0 dst=1 clocks="dsp_aclk"
modprobe -r dmatestcontig

В примере выше включается частота, описанная в узле устройства «dsp_aclk» в DTS, необходимая для обеспечения доступа к XYRAM.

Ядро Linux для 1892ВМ14Я. Руководство программиста¶

О документе¶

Подсистема управления тактовыми сигналами¶

Драйвер контроллера SPI dw_spi_mmio¶

Драйвер контроллера PWM pwm-mcom¶

Драйвер контроллера дисплея vpout-drm¶

Драйвер фреймбуфера vpoutfb¶

Драйвер VPU avico¶

Общие сведения¶

Кодирование видео¶

Декодирование видео¶

Ограничения драйвера¶

Использование драйвера¶

Контроль битрейта при кодировании¶

Описание алгоритма¶

Совместимость с гипотетическим референсным декодером¶

Драйвер контроллера Ethernet arasan-gemac¶

Подсистема управления энергопотреблением¶

Модель System Sleep¶

Пример пробуждения по событию от UART¶

Пример пробуждения по событию от RTC¶

Модель Runtime Power Management¶

Механизм CPU hotplug¶

Драйвер управления частотой ядер CPU cpufreq-dt¶

Подсистема UART в режиме RS-485¶

Модуль dmatestcontig для тестирования SDMA¶

Оглавление

Предыдущий раздел

Следующий раздел