Расширенная техническая статья по интерфейсу MIPI CSI‑2 с описанием архитектуры физического уровня структуры пакетов рекомендациями по расчёту

Интерфейс MIPI CSI-2 Стандарт MIPI CSI-2 (MIPI Camera Serial Interface 2nd Generation) — это высокопроизводительный, экономичный и простой в использовании интерфейс. MIPI CSI-2 обеспечивает максимальную пропускную способность 10 Гбит/с с четырьмя линиями передачи данных изображения, каждая из которых способна передавать данные со скоростью до 2,5 Гбит/с. MIPI CSI-2 быстрее USB 3.0 и обладает надежным протоколом для обработки видео с разрешением от 1080p до 8K и выше. Кроме того, благодаря низкому уровню накладных расходов MIPI CSI-2 обеспечивает более высокую пропускную способность для передачи изображения. Интерфейс MIPI CSI-2 потребляет меньше ресурсов центрального процессора благодаря многоядерности процессоров. Он является интерфейсом камеры по умолчанию для Raspberry Pi и Jetson Nano. Модули камеры Raspberry Pi V1 и V2 также основаны на нём.



Ниже — расширенная техническая статья по интерфейсу MIPI CSI‑2 с описанием архитектуры, физического уровня, структуры пакетов, рекомендациями по расчёту требуемой пропускной способности и несколькими подробными примерами расчёта.
 

1. Введение MIPI CSI‑2 (Camera Serial Interface 2nd Generation) — распространённый интерфейс для передачи потоков изображений от камер к процессорам/ISP в встраиваемых и мобильных системах. CSI‑2 обеспечивает пакетную передачу данных по одной или нескольким дифференциальным линиям (data lanes) плюс отдельная линия тактового сигнала (в D‑PHY) или альтернативную физику (C‑PHY). Типичная конфигурация — до 4 data lanes, каждая до 2,5 Гбит/с (зависит от версии D‑PHY/C‑PHY), что даёт агрегированно до ~10 Гбит/с.

2. Архитектура и уровни

• Физический уровень: D‑PHY (обычно) или C‑PHY. D‑PHY: отдельная clock lane + N data lanes (дифференциальные пары), режимы Low‑Power (LP) и High‑Speed (HS). C‑PHY использует трёхпроводную кодировку; обеспечивает другие эффективные скорости.
• Протоколный уровень (CSI‑2): пакетная организация данных — short packets (служебные) и long packets (payload — изображение). Заголовки пакетов содержат Data Type (формат), Virtual Channel ID, длину и др.
• Логический уровень: виртуальные каналы (VC) позволяют мультиплексировать несколько потоков по одному физическому интерфейсу; форматы данных — RAW, RGB, YUV, JPEG и пр.

1. Ключевые понятия и параметры при расчёте пропускной способности

• Разрешение (W × H, активные пиксели).
• Частота кадров (fps).
• Глубина цвета (bits per pixel, bpp) — зависит от формата: RAW10 = 10 bpp, RAW12 = 12 bpp, RGB888 = 24 bpp, YUV422 = 16 bpp и т.п.
• Пакетная/форматная накладная (CSI‑2 headers, CRC/Checksum). Обычно накладные малы (несколько байт на пакет), но учитывать надо.
• Временная/строчная и кадровая «пустая» зона (blanking) — горизонтальные/вертикальные интервалы, которые увеличивают общий объём передаваемых данных по сравнению с чисто активными пикселями. Для сенсоров blanking может быть 5–30% (в зависимости от таймингов), для видеостримов VLC/encode/packaging — ещё небольшая доля.
• Физическая скорость на линии (например, 2.5 Gbps). Учтите, что фактически доступная пропускная способность может быть немного ниже из‑за служебных переходов LP↔HS, возможной кодировки или уровня ошибок.

1. Формула расчёта исходной пропускной способности Базовая формула (бит/с, без мелкой накладки): bits_per_second = W * H * fps * bpp

Учтём накладывающие множители:

• Коэффициент blanking: K_blank = 1 + fraction_blank (например, 0.1 для 10%).
• Коэффициент протокольной накладки: K_proto (например, 1.02 для ~2% накладки на заголовки и CRC).

Итог: required_bps = W * H * fps * bpp * K_blank * K_proto

Далее сравниваем с эффективной пропускной способностью линии: effective_lane_bps = lane_rate_bps * lane_efficiency где lane_efficiency учитывает все второстепенные накладки; при D‑PHY и CSI‑2 без 8b/10b обычно можно принять lane_efficiency ≈ 0.95–0.99 (в зависимости от реализации). Если используете 4 линии: total_link_bps = effective_lane_bps * num_lanes

5. Примеры расчёта (пошагово) Во всех примерах примем lane_rate = 2.5 Gbps (2.5×10^9 б/с) и lane_efficiency = 0.98 (то есть резерв на служебные интервалы ~2%). K_proto = 1.02. Для blanking в примерах возьмём разумные значения и отдельно покажем, как изменится результат.

Пример A — Full HD (RGB888), 1920×1080, 30 fps, RGB888 (24 bpp) 1) Активные биты/кадр = 1920 * 1080 * 24 = 49 766 400 бит 2) bits/s (чисто активное) = 49 766 400 * 30 = 1 492 992 000 ≈ 1.493 Gbps 3) Учёт blanking. Пусть blanking = 10% → K_blank = 1.1: bits/s с blanking = 1.493 * 1.1 = 1.642 Gbps 4) Учёт протокола K_proto = 1.02 → required_bps ≈ 1.642 * 1.02 = 1.675 Gbps 5) Доступная полоса 1 линии: 2.5 Gbps * 0.98 = 2.45 Gbps Вывод: одна линия (или конфигурация 1 lane) достаточна; остаётся запас.

Пример B — Full HD, 60 fps, RGB888 (24 bpp) Активное bits/s = 1.493 Gbps * 2 = 2.986 Gbps
С blanking 10% → 3.285 Gbps
С протоколом → ~3.35 Gbps
Две линии: 2 * 2.45 = 4.9 Gbps → двух линий достаточно (одна — нет).

Пример C — 4K UHD (3840×2160), 30 fps, RAW10 (10 bpp), blanking 15% 1) Активные bits/frame = 3840 * 2160 * 10 = 82 944 000 бит 2) bits/s = 82 944 000 * 30 = 2 488 320 000 ≈ 2.488 Gbps 3) С blanking 15% → 2.488 * 1.15 = 2.861 Gbps 4) С K_proto 1.02 → ~2.918 Gbps Две линии: 2 * 2.45 = 4.90 Gbps → двух линий достаточно. Одной — нет.

Пример D — 8K (7680×4320), 30 fps, RAW12 (12 bpp), blanking 20% 1) Активные bits/frame = 7680 * 4320 * 12 = 398 131 200 бит 2) bits/s = 398 131 200 * 30 = 11 943 936 000 ≈ 11.944 Gbps 3) С blanking 20% → 11.944 * 1.20 = 14.333 Gbps 4) С K_proto 1.02 → ~14.62 Gbps Максимум 4 lane (по допущению 4×2.5 Gbps * 0.98 ≈ 9.8 Gbps) — явно недостаточно. Нужны: компрессия (в‑ч. компрессия сенсора или DSC), уменьшение fps, снижение bpp или более быстрый PHY/большее число линий (если поддерживается).

6. Примеры для популярных форматов (bpp)

• RAW8 = 8 bpp
• RAW10 = 10 bpp (обычно упаковывается: 4 байта на 4 пикселя → эффективная упаковка, но при расчётах используйте 10 б/пик)
• RAW12 = 12 bpp
• YUV422 (YUYV) = 16 bpp (две компоненты на два пикселя)
• RGB565 = 16 bpp
• RGB888 = 24 bpp

Замечание про упаковку RAW10/12: в CSI‑2 данные упаковываются в байтовые последовательности (packed), что добавляет некоторую нецелую байтовую организацию, но при подсчёте бита/пик лучше ориентироваться именно на bpp.

7. Структура пакета CSI‑2 и накладные расходы (наглядно)

• Long packet = [Long Packet Header (4 байта)] + [Payload (image data)] + [Footer/Checksum (2 байта, в зависимости от версии/настройки)]
• Short packet = 4 байта (служебные сообщения: синхронизация, конфигурация и т. п.)

Накладные расходы на много длинных пакетов: если payload большой (строка/несколько строк), то относительная доля заголовков мала. Практически обычно достаточно принять K_proto = 1.01–1.03.

8. Физический слой: D‑PHY vs C‑PHY (кратко)

• D‑PHY: классический, clock lane + N data lanes; данные передаются в HS режиме дифференциальными парами. Поддерживается широкими версиями PHY; скорость на линию зависит от версии (в новых версиях до 2.5 Gbps и выше).
• C‑PHY: трёхпроводная физика, кодирует символы, обычно даёт другие эквивалентные скорости (например, 1 триада символов ≈ несколько бит). Используется для более высоких скоростей на меньшее число проводников.
  Выбор PHY влияет на допустимую длину трассы, EMI, режимы пробуждения (LP), и на поддерживаемые скорости.

8. Практические рекомендации при проектировании системы

• Всегда учитывать blanking и возможности сенсора выставлять сокращённые строчные/кадровые интервалы.
• Используйте virtual channels для мультиплексирования нескольких потоков (например, параллельная выдача RAW + метаданных).
• Если агрегированная пропускная способность близка к пределу, рассмотрите:
• Понижение bpp (например, RAW12 → RAW10 с потерями);
• Снижение fps или разрешения (cropping);
• Включение компрессии (если поддерживается);
• Переход на более быстрый PHY/увеличение числа линий;
• Задержки/буферизацию и использование DMA на стороне SoC, чтобы снизить CPU‑нагрузку.
• Тестируйте в реальных условиях: пограничная полоса часто приводит к потере кадров или скипам.

8. Пример расчёта с упаковкой RAW10 (деталь) RAW10 упаковывается так: каждые 4 пикселя занимают 5 байт (40 бит), т.е. 10 бит/пик. Это означает, что в пересчёте на байты средняя нагрузка = 1.25 байта/пик. Формула остаётся: bits = pixels * 10. Пример: 3840×2160@30fps RAW10: pixels/frame = 8 294 400 bits/frame = 8 294 400 * 10 = 82 944 000 бит bits/s = *30 = 2.48832 Gbps (анализ выше).

9. ASCII‑диаграммы и указания для построения картинок

Блок‑схема (ASCII): [Camera sensor] --> [CSI‑2 TX (PHY)] --(clock lane + data lanes)--> [CSI‑2 RX (SoC/ISP)] --> [ISP] --> [CPU/DSP/Memory]

Вариант с 4 линиями: Camera ──> TX ──> D‑PHY: CLK | D0+/- | D1+/- | D2+/- | D3+/- ──> RX ──> ISP

Инструкция для рисования диаграммы в draw.io / Visio:

• Блоки: Sensor, CSI‑2 Transmitter, D‑PHY (разделить на Clock lane и N data lanes), CSI‑2 Receiver/ISP, Memory/CPU.
• Соединить строчными стрелками. Подписать линии: скорость на линию (напр., 2.5 Gbps), режимы (HS/LP), протокол (CSI‑2 vX).
• Дополнительно можно отрисовать временную диаграмму HS передачи: clock lane HS→LP переходы, data lanes HS символьные интервалы.

1. Контрольные вопросы при проектировании/внедрении

• Какой PHY поддерживает ваш сенсор и ваш SoC (D‑PHY версия, C‑PHY)?
• Какова максимальная скорость на линию и сколько линий физически доступно?
• Каков формат данных (RAW/RGB/YUV) и bpp?
• Каковы реальные тайминги (включая blanking) сенсора?
• Есть ли требование по задержкам и буферизации?
• Поддерживается ли компрессия (например, VVC/DSC) в цепочке?

1. Заключение MIPI CSI‑2 — эффективный и широко применимый интерфейс для камер в встроенных системах. Правильный расчёт пропускной способности требует учёта разрешения, fps, глубины цвета, blanking и небольшой накладки протокола. При типичных параметрах Full HD30 RGB888 одна линия 2.5 Gbps справится, а для более тяжёлых конфигураций (4K60 RGB или 8K30 RAW12) требуются дополнительные линии, компрессия или снижение параметров съемки.

Пример для расчета сенсора изображения AR0234

расчёты пропускной способности для вашего сенсора AR0234 (1920×1200 @ 120 fps, оптический формат 1/2.6") для типичных форматов вывода (RAW8/RAW10/RAW12) и оценю, сколько MIPI‑ланов потребуется при PHY 2.5 Gbps/lanе. Пояснения и рекомендации в конце.

Исходные данные:

• Разрешение: 1920 × 1200 = 2 304 000 пикселей/кадр
• Частота: 120 fps
• Скорость линии PHY: 2.5 Gbps (typical D‑PHY HS)
• Эффективность линии (резерв под HS/LP переходы, служебные интервалы): возьмём lane_efficiency = 0.98 → эффективная скорость на линию ≈ 2.5 × 0.98 = 2.45 Gbps
• Протокольная накладная CSI‑2: примем K_proto = 1.02 (≈2%)
• Blanking (тайминги строки/кадра) сильно зависят от настроек сенсора — приведу расчёты для трёх сценариев blanking: 0% (идеал), 10% (типично), 20% (консервативно)

Формула: required_bps = pixels_per_frame × fps × bpp × K_blank × K_proto, где K_blank = 1 + blanking_fraction.

Вычисления (в Gbps):

1) RAW10 (10 bit/pixel)

• Базовый (без blanking): bits/s = 2 304 000 × 120 × 10 = 2.7648 Gbps
• С учётом протокола (K_proto=1.02): 2.7648 × 1.02 = 2.8201 Gbps
• С blanking 10% (K_blank=1.1): 2.7648 × 1.1 × 1.02 = 3.1021 Gbps
• С blanking 20% (K_blank=1.2): 2.7648 × 1.2 × 1.02 = 3.3841 Gbps

Требуемое число линий (эффективная линия = 2.45 Gbps):

• 0%: 2.82 / 2.45 = 1.15 → min 2 lanes
• 10%: 3.10 / 2.45 = 1.27 → 2 lanes
• 20%: 3.38 / 2.45 = 1.38 → 2 lanes

Вывод: RAW10 @120fps → 2 линии (2×2.5 Gbps) дают комфортный запас.

2) RAW12 (12 bit/pixel)

• Базовый: 2 304 000 × 120 × 12 = 3.31776 Gbps
• С протоколом: 3.31776 × 1.02 = 3.38412 Gbps
• С blanking 10%: 3.31776 × 1.1 × 1.02 = 3.72253 Gbps
• С blanking 20%: 3.31776 × 1.2 × 1.02 = 4.06094 Gbps

Требуемые линии:

• 0%: 3.384 / 2.45 = 1.38 → 2 lanes
• 10%: 3.723 / 2.45 = 1.52 → 2 lanes
• 20%: 4.061 / 2.45 = 1.66 → 2 lanes

Вывод: RAW12 @120fps → тоже укладывается в 2 линии при PHY 2.5 Gbps, но запас меньше, чем для RAW10.

3) RAW8 (8 bit/pixel)

• Базовый: 2 304 000 × 120 × 8 = 2.21184 Gbps
• С протоколом: 2.21184 × 1.02 = 2.25608 Gbps
• С blanking 10%: 2.21184 × 1.1 × 1.02 = 2.48168 Gbps
• С blanking 20%: 2.21184 × 1.2 × 1.02 = 2.70729 Gbps

Требуемые линии:

• 0%: 2.256 / 2.45 = 0.92 → 1 lane теоретически хватает
• 10%: 2.482 / 2.45 = 1.01 → в пограничном состоянии → лучше 2 lanes
• 20%: 2.707 / 2.45 = 1.10 → 2 lanes

Вывод: RAW8 может в теории поместиться на 1 линии в идеальном случае, но при реальном blanking почти наверняка потребуется 2 линии, поэтому на практике лучше проектировать с 2 линиями для надёжности.

Краткое итоговое резюме и рекомендации

• Для AR0234 1920×1200 @ 120 fps наиболее надёжный и практичный выбор — MIPI CSI‑2 с 2 data lanes @ 2.5 Gbps (конфигурация 2 lanes даёт ~4.9 Gbps агрегированной пропускной способности при запасе).
• RAW10 и RAW12 при типичном blanking 10…20% укладываются в 2 lanes; RAW8 иногда может поместиться в 1 lane, но это небезопасно без подтверждённых таймингов.
• Если вам нужен запас (для дополнительных виртуальных каналов, метаданных, буферизации, пиковых перегрузок), можно рассмотреть 4 lanes (даёт ≈9.8 Gbps эффективной полосы) или уменьшить bpp/fps/разрешение, либо включить компрессию (если поддерживается).

Ниже — ясная диаграмма подключения, пример фрагмента device‑tree для конфигурации 2/4 data‑lanes и подробные расчёты: пик/строчная скорость, время HS‑передачи одной строки и пример MIPI long‑packet для строчной передачи при сенсоре AR0234 (1920×1200 @ 120 fps). В расчётах принимаем PHY D‑PHY @ 2.5 Gbps/lanе, lane_efficiency = 0.98, протокольная накладная K_proto = 1.02. Если хотите — сделаю аналог для другой lane‑count или другого PHY.

1) Диаграмма подключения (ASCII) Camera (AR0234) I2C/SPI (control) | v [Sensor AR0234] -- MIPI CSI‑2 TX --> [D‑PHY (CLK lane + data lanes)] CLK lane (CLK+ / CLK-) D0 lane (D0+ / D0-) D1 lane (D1+ / D1-) D2 lane (D2+ / D2-) (опционно) D3 lane (D3+ / D3-) (опционно) | v [SoC / ISP MIPI CSI‑2 RX] --> ISP --> Memory/CPU

Примечание: для 2‑lanes используются D0 и D1; CLK — обязательна. Не подключайте неиспользуемые пары.

2) Пример фрагмента device‑tree (универсальный/иллюстративный) (Внимание: синтаксис и имена свойств зависят от конкретной SoC/binding. Проверяйте binding вашего SoC — rockchip/imx/tegra/mediatek имеют нюансы. Ниже — шаблон, который нужно адаптировать.)

/* Sensor node / ar0234@3c { compatible = "onsemi,ar0234"; reg = <0x3c>; / пример I2C адреса (замените на реальный) / label = "ar0234"; ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; endpoint { remote-endpoint = <&csi0_in>; data-lanes = <1 2>; / пример: используем D0 и D1 (проверьте нумерацию: 0- or 1-based) / clock-lane = <0>; / индекс clock lane, если требуется / / media bus format и другие свойства sensor specific */ }; }; }; };

/* Host/CSI receiver node (пример) / csi0: csi@… { compatible = "vendor,mipi-csi2"; / … / ports { #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; endpoint: endpoint@0 { reg = <1>; remote-endpoint = <&ar0234_port0>; data-lanes = <1 2>; / согласовать с сенсором */ clock-lane = <0>; }; }; }; };

Советы:

• Нумерация data‑lanes в DT часто 0‑based (<0 1>) либо 1‑based (<1 2>) — смотрите binding SoC.
• Для 2 lanes указывайте два индекса (D0, D1). Для 4 lanes — <0 1 2 3> или <1 2 3 4> в зависимости от binding.
• Иногда используется свойство "remote-endpoint" и phandle к эндпоинту SoC CSI.

3) Базовые численные параметры (напоминание)

• Активные пиксели/кадр = 1920 × 1200 = 2 304 000 пикселей
• Частота кадров = 120 fps
• Пикселей/с = 2 304 000 × 120 = 276 480 000 пикс/с

4) Средняя (average) скорость передачи (payload) — без учета пиков/бликов payload_bps = pixels/s × bpp

RAW8 (8 bpp)

• payload_bps = 276 480 000 × 8 = 2.21184 Gbps RAW10 (10 bpp)
• payload_bps = 276 480 000 × 10 = 2.7648 Gbps RAW12 (12 bpp)
• payload_bps = 276 480 000 × 12 = 3.31776 Gbps

Добавляем протокольную накладную (K_proto = 1.02): avg_total_bps = payload_bps × 1.02

Итого (average, с K_proto):

• RAW8: 2.21184 × 1.02 = 2.25608 Gbps
• RAW10: 2.7648 × 1.02 = 2.820096 Gbps
• RAW12: 3.31776 × 1.02 = 3.3841152 Gbps

Эти значения — средняя требуемая полоса (суммарно) для непрерывной передачи всех активных пикселей при 120 fps.

5) Пиковая/строчная скорость (burst/line peak) Пиковая (инстантная) скорость важна, если сенсор передаёт данные только в HS во время активной части строки/кадра, а в blanking переходит в LP. В таком случае тот же объём данных передаётся за меньшую «активную» долю времени, что повышает требуемую HS‑скорость пропорционально фактору заполнения (duty cycle).

Определим общий фактор пустого времени (total_blank_fraction) = (HTSVTS - WH) / (W*H). Если нет точных HTS/VTS, можно аппроксимировать общую «пустоту» (включая горизонтальный и вертикальный blanking) как 0…20% — выберем примеры 0%, 10%, 20%.

Пиковая скорость: peak_bps = avg_total_bps × (1 + total_blank_fraction)

Примеры (RAW10, avg_total = 2.820096 Gbps):

• total_blank = 0% → peak = 2.8201 Gbps
• total_blank = 10% → peak = 2.8201 × 1.10 = 3.1021 Gbps
• total_blank = 20% → peak = 2.8201 × 1.20 = 3.3841 Gbps

Аналогично для RAW12 (avg_total = 3.3841152 Gbps):

• 0% → 3.3841 Gbps
• 10% → 3.7225 Gbps
• 20% → 4.0609 Gbps

6) Сравнение с доступной физической полосой (2 lanes @ 2.5 Gbps) Эффективная полоса на одну линию = 2.5 Gbps × 0.98 = 2.45 Gbps

• 1 lane ≈ 2.45 Gbps
• 2 lanes ≈ 4.90 Gbps
• 4 lanes ≈ 9.80 Gbps

Вывод:

• Для AR0234 @1920×1200@120fps RAW10/RAW12 практично использовать 2 lanes (2×2.5 Gbps) — дают запас и покрывают пик‑скорости до ~4.9 Gbps.
• RAW8 может уместиться и на 1 lane в идеальном случае, но при реальных blanking/протокол‑оверхэде безопаснее 2 lanes.

7) Строчная передача и пример размера MIPI long packet (по строке) MIPI CSI‑2 long packet: header (4 байта) + payload (N bytes) + CRC (2 байта) [CRC присутствует если включён]. Длина payload указывается в 16‑битном поле (макс 65535 bytes) — значит строки до ~64 KB можно отправлять в одном long packet.

Bytes per pixel (пример):

• RAW8 = 1.0 B/pix
• RAW10 = 10 bits/pix → упакованы как 1.25 B/pix → bytes/line = 1920 × 1.25 = 2400 bytes
• RAW12 = 12 bits/pix → 1.5 B/pix → bytes/line = 1920 × 1.5 = 2880 bytes

Размер long packet для одной строки (payload = bytes_per_line):

• RAW8: payload = 1920 B → total packet = 1920 + 4 + 2 = 1926 B = 15408 bits
• RAW10: payload = 2400 B → total = 2406 B = 19248 bits
• RAW12: payload = 2880 B → total = 2886 B = 23088 bits

Количество long packets на кадр = число активных строк = 1200 (каждая строка — отдельный long packet, обычно).

8) HS‑время передачи одной строки при 2 lanes HS aggregate rate = 2 lanes × 2.5 Gbps × 0.98 = 4.90 Gbps

HS_time_per_line = bits_per_line_total / HS_aggregate_rate

Примеры:

• RAW10: bits_per_line_total = 19248 bits → HS_time = 19248 / 4.9e9 = 3.93 μs
• RAW12: 23088 bits → HS_time = 23088 / 4.9e9 = 4.71 μs
• RAW8: 15408 bits → HS_time = 15408 / 4.9e9 = 3.15 μs

Сравнение с line_time:

• Frame_time = 1 / 120 = 8.333 ms
• Если предположить total_lines = active_lines (т.е. нет вертикального blanking) → line_time = 8.333 ms / 1200 = 6.944 μs
• Если допустим общий blanking (гор.+верт.) 10% → total_lines = 1200 × 1.1 = 1320 → line_time = 8.333 ms / 1320 = 6.313 μs

Итого: HS_time_per_line (3.15…4.71 μs) < line_time (≈6.3…6.94 μs) → 2 lanes обеспечивают достаточное время передачи строки с запасом при приведённых допущениях.

9) Пример расчёта полноты проверки Проверим RAW12 с 20% total blank:

• avg_total_bps = 3.3841152 Gbps
• peak_bps = avg_total_bps × 1.20 = 4.06093824 Gbps
• HS aggregate (2 lanes) = 4.90 Gbps → запас ≈ 0.84 Gbps → ok

10) Заключение и рекомендации

• Практическая рекомендация: проектируйте с 2 data lanes + clock lane для AR0234 @1920×1200@120fps (RAW10/RAW12). Это обеспечивает запас для протокольной накладки и умеренного blanking.
• Для точных расчётов и верификации нужно HTS (horizontal total pixels) и VTS (vertical total lines) из даташита AR0234 — они позволяют точно вычислить duty_cycle и пиковую HS‑скорость.
• Убедитесь в правильной нумерации data lanes в device‑tree для вашей SoC и в соответствии физического подключения (контакт +/− каждой пары).
• Если требуется резерв для будущего апгрейда (4K/60 и т. п.), можно предусмотреть 4 lanes.