Links (ISS):
1) ti tda3 - trm (chapter 7 - imaging subsytem)
2) dm38x and tms320dm8127 davinci digital media processor imaging subsystem https://www.ti.com/lit/ug/spruhl6a/spruhl6a.pdf
csi, dsi:
1) https://en.wikipedia.org/wiki/Camera_Serial_Interface
2) https://www.mipi.org/specifications/csi-2
1) https://en.wikipedia.org/wiki/Camera_Serial_Interface
2) https://www.mipi.org/specifications/csi-2
Для использования примеров из библиотеки vps нужно подключить статические либы из проекта vision sdk, собранные командой gmake -s -j pdk. Как добавить путь к либам, сами либы, изменить путь к библиотеке sdk vision описано здесь. Необходимые для cala, calb примеров на основе vps либы:
1) ti.csl.aem4
2) vps_common.aem4
3) vpslib.aem4
4) vps_osal_baremetal.aem4
Если в своем проекте добавляем инициализацию драйверной системы FVID2 (Fvid2_init(NULL);), добавляем сборку стандартных fvid2-драйверов (например, FVID2_VPS_CAPT_VID_DRV), входящих в подсистему vps (Vps_init(NULL);), библиотеку с драйверами vpsdrv (VpsDrv_ctrlInit();), регистрируем драйвер из входящих в комплект bsp fvid2-драйвер для матрицы imx290 (Bsp_imx290Init();), необходимо включить следующие собранные либы, помимо вышеупомянутых (это всё понадобится для запуска примера из vision sdk C:\ti\PROCESSOR_SDK_VISION_03_06_00_00\ti_components\drivers\pdk_01_10_02_07\packages\ti\drv\vps\examples\iss\captureIss (CaptureIss_main.h, CaptureIss_main.с;
C:\ti\PROCESSOR_SDK_VISION_03_06_00_00\ti_components\drivers\pdk_01_10_02_07\packages\ti\drv\vps\examples\iss\isscapt_baremetal_app):
1) fvid2.aem4
2) vps_devices.aem4
3) vpsdrv_baremetal.aem4
4) vps_platforms.aem4
1. Включение clock domains CD_ISS и CD_CAM в подсистеме PRCM.
Нам необходимо включить подсистему считывания видеоданных с порта csi-2 матрицы CMOS (ip-блок Imaging subsystem). Для этого нам надо "разбудить" (подать питание и клоки) на clock domain CD-ISS (сама подсистема imaging subsystem) и clock domain CD-CAM (работа с портом CSI-2). Управление CD-ISS производится через группу регистров ISS_CM_CORE_AON, CD-CAM через группу регистров CAM_CM_CORE.
1.1. Процедура включения частотного домена ISS (группа регистров PRCM - ISS_CM_CORE_AON).
1.1.1. До включения (пройден GEL, начало функции main ядра ipu0 arm cortex-m4) регистры группы имеют следующие значения:
1) CM_ISS_CLKSTCTRL = 0x00000003:
- бит 8 CLKACTIVITY_ISS_GCLK = 0x0 (0x0: Corresponding clock is definitely gated)
- биты 1:0 CLKTRCTRL = 0x3 (0x3: HW_AUTO: Automatic transition is enabled. Sleep
and wakeup transition are based upon hardware conditions)
2) CM_ISS_ISS_CLKCTRL = 0x00070000:
- бит 18 STBYST = 0x1 (0x1: Module is in standby)
- биты 17:16 IDLEST = 0x3 (0x3: Module is disabled and cannot be accessed)
- биты 1:0 MODULEMODE = 0x0 (0x0: Module is disabled by SW. Any OCP access to
module results in an error, except if resulting from a module wakeup (asynchronous wakeup))
3) CM_ISS_STATICDEP = 0x00000020:
- бит 27 L4PER3_STATDEP = 0x0 (0x0: Dependency is disabled)
- бит 5 L3MAIN1_STATDEP = 0x1 (0x1: Dependency is enabled)
- бит 4 EMIF_STATDEP = 0x0 (0x0: Dependency is disabled)
1.1.2. Для того, чтобы подать разбудить модуль надо биты CLKTRCTRL регистра CM_ISS_CLKSTCTRL установить в состояние 0x2 (SW_WKUP: Start a software forced wake-up transition on the domain) и биты MODULEMODE регистра CM_ISS_ISS_CLKCTRL перевести в состояние 0x1 (0x1: Module is managed automatically by HW according to clock domain transition. A clock domain sleep transition put module into idle. A wakeup domain transition put it back into function. If CLKTRCTRL=3, any OCP access to module is always granted. Module clocks may be gated according to the clock domain state).
Будем использовать константы из хедера проекта vision sdk, подключим следующий файл C:\ti_830\PROCESSOR_SDK_VISION_03_06_00_00\ti_components\drivers\pdk_01_10_02_07\packages\ti\csl\soc\tda3xx\hw_iss_cm_core_aon.h для констант со сдвигами и файл C:\ti_830\PROCESSOR_SDK_VISION_03_06_00_00\ti_components\drivers\pdk_01_10_02_07\packages\ti\csl\soc\tda3xx\armv7m\soc.h. Нужному нам адресу 0x4a005760 (CM_ISS_CLKSTCTRL) из trm в файле soc.h соответствует константа SOC_VPE_CM_CORE_AON_BASE.
Neo, wake up:
HW_WR_REG32( cm_iss_clkstctrl_addr, FMKT( CM_ISS_CLKSTCTRL_CLKTRCTRL, SW_WKUP));
const uint32_t cm_iss_iss_clkctrl_addr = SOC_VPE_CM_CORE_AON_BASE + CM_ISS_ISS_CLKCTRL;
HW_WR_REG32( cm_iss_iss_clkctrl_addr, FMKT( CM_ISS_ISS_CLKCTRL_MODULEMODE, AUTO));
После изменения состояния обоих регистров становятся доступны регистры подгрупп ISS_TOP и ISS_TCTRL. Теперь возможна более детальная настройка ip-блока Imaging Subsystem.
1.2. Включение частотного домена CAM (группа регистров PRCM - CAM_CM_CORE).
1.2.1. До включения (пройден GEL, начало функции main ядра ipu0 arm cortex-m4) регистры группы имеют следующие значения:
1) CM_CAM_CLKSTCTRL = 0x00000003:
- бит 12 CLKACTIVITY_LVDSRX_96M_GFCLK = 0x0 (0x0: Corresponding clock is definitely gated)
- бит 11 CLKACTIVITY_LVDSRX_L4_GICLK = 0x0 (0x0: Corresponding clock is definitely gated)
- бит 8 CLKACTIVITY_VIP1_GCLK = 0x0 (0x0: Corresponding clock is definitely gated)
- биты 1:0 CLKTRCTRL = 0x3 (0x3: HW_AUTO: Automatic transition is enabled. Sleep
and wakeup transition are based upon hardware conditions)
2) CM_CAM_VIP1_CLKCTRL = 0x00070000:
- бит 24 CLKSEL = 0x0 (0x0: Selects L3_ICLK)
- бит 18 STBYST = 0x1 (0x1: Module is in standby)
- биты 17:16 IDLEST = 0x3 (0x3: Module is disabled and cannot be accessed)
- биты 1:0 MODULEMODE = 0x0 (0x0: Module is disabled by SW)
3) CM_CAM_CSI1_CLKCTRL = 0x00060001:
- бит 18 STBYST = 0x1 (0x1: Module is in standby)
- биты 17:16 IDLEST = 0x2 (0x2: Module is in Idle mode (only OCP part). It is
functional if using separate functional clock)
functional if using separate functional clock)
- биты 1:0 MODULEMODE = 0x1 (0x1: Module is managed automatically by HW according
to clock domain transition. A clock domain sleep transition put module into idle. A wakeup domain
transition put it back into function. If CLKTRCTRL=3, any OCP access to module is always granted. Module clocks may be gated according to the clock domain state.)
4) CM_CAM_STATICDEP = 0x00000030:
- ISS_STATDEP = 0x0
- L4PER3_STATDEP = 0x0
- GMAC_STATDEP = 0x0
- EVE1_STATDEP = 0x0
- L4CFG_STATDEP = 0x0
- L3MAIN1_STATDEP = 0x1
- EMIF_STATDEP = 0x1
1.2.2. Для того, чтобы подать разбудить модуль надо биты CLKTRCTRL регистра CM_CAM_CLKSTCTRL установить в состояние 0x2 (SW_WKUP: Start a software forced wake-up transition on the domain).
Будем использовать константы из хедера проекта vision sdk, подключим следующий файл C:\ti_830\PROCESSOR_SDK_VISION_03_06_00_00\ti_components\drivers\pdk_01_10_02_07\packages\ti\csl\soc\tda3xx\hw_cam_cm_core.h для констант со сдвигами и файл C:\ti_830\PROCESSOR_SDK_VISION_03_06_00_00\ti_components\drivers\pdk_01_10_02_07\packages\ti\csl\soc\tda3xx\armv7m\soc.h. Нужному нам адресу 0x4a009000 (CM_CAM_CLKSTCTRL) из trm в файле soc.h соответствует константа SOC_CAM_CM_CORE_BASE.
Wake up:
const uint32_t cm_cam_clkstctrl_addr = SOC_CAM_CM_CORE_BASE + CM_CAM_CLKSTCTRL;
HW_WR_REG32( cm_cam_clkstctrl_addr, FMKT( CM_CAM_CLKSTCTRL_CLKTRCTRL, SW_WKUP));
После просыпания бит CLKTRCTRL ставится в 0x2. Это ведет к следующим изменениям в регистрах, связанных с портами LVDS, CSI:
- бит CLKACTIVITY_LVDSRX_96M_GFCLK регистра CM_CAM_CLKSTCTRL ставится в 0x1 (0x1: Corresponding clock is running or gating/ungating transition is on-going)
- биты IDLEST регистра CM_CAM_CSI1_CLKCTRL ставятся в 0x0 (0x0: Module is fully functional, including OCP)
ISS overview.
Модуль отладки событий внутри блока ISS - CTSET
ISS Interfaces: CPI, LVDSRX, CSI-2.
CAL-A, CAL-B
7.2.4 ISS CSI2 PHY
7.2.4.1 ISS CSI2 PHY Overview
There is one MIPI D-PHY compliant PHY receiver (CSI2_PHY1 or generally referenced to as CSI2 PHY) immediately before the CAL_A and LVDS-RX module, which acts as a physical connection and
configuration of clock/data lanes with external sensors. A CSI2 PHY supports up to four configurations,
depending on the required number of D-PHY data lane external sensors. The receiver is compatible with the MIPI D-PHY Specification v1.00.00. The selection of a CSI2 PHY in D-PHY mode must be done before reset and not on the fly.
The CSI2 PHY is controlled and must be configured first from the device Control Module for pad
configuration. The differential data/clock lanes coming into the CSI2 PHY1 are configured from registers explained in Section 7.2.4.2.3, CSI2 PHY Link Initialization Sequence.
There is one CSI2 PHY instance integrated in the device. As shown in Figure 7-14, the CSI2_PHY1
contains four data lanes. Figure 7-14 shows the CSI2 PHY, with its signals further covered in
Section 7.2.6.3.6.1, CSI2 Physical Layer.
NOTE: LANE 4 of CSI2_PHY1 can be used only as a data lane, never as a clock lane. All other
configurations are possible.
CSI2_PHY1 represent the overall PHY solution for connecting external sensors to feed the CAL module. The MIPI D-PHY function can support up to four data lane modules and one clock lane module. Reverse direction escape mode is not supported. The lane module polarity and positions are configurable; that is, any lane module can be chosen as the clock lane module (except otherwise notified), and the DX/DY data pad for each lane module can be configured as DP or DN pins defined. The configuration and the selection of D-PHY mode, data/clock are done through the device Control Module (see Chapter 14, Control Module). The only exception is the four-data-lane use case, in which one corner lane is allowed to be only a data lane. the CSI2 CSI2_PHY1 can be configured through serial configuration protocol (SCP) interface.
7.2.4.2 ISS CSI2 PHY Functional Description
7.2.4.2.1 ISS CSI2 PHY Configuration
The CSI2 PHY converts the bitstream, divided into 1 up to 4 serial data lanes, and one clock lane, into a
bitstream compatible with the CSI2 low level protocol within the CAL module. The CSI2 low level protocol engine only provides the SCP clock when CSI2 PHY registers are accessed and CAL_CTRL[21] PWRSCPCLK = 0. However, the CSI2 PHY needs at least 3 SCP clock cycles to
come out of the reset state. Therefore, SW must perform a dummy read of a CSI2 PHY register (32 SCP
clock pulses) to complete the CSI2 PHY reset sequence. Alternatively, the SCP clock can be programmed to be free-runnig by setting CAL_CTRL[21] PWRSCPCLK = 1 (not prefered).
The CAL_CSI2_COMPLEXIO_IRQSTATUS_l register logs complex I/O events of the following types:
• Line power-state change (all lanes in ultralow-power mode [ULPM], at least one lane exits ULPM, etc.)
• Error on one lane
Some complex I/O parameters can be configured through the following registers:
• The REG0 register reports completion of reset on the different parts of the module and configures the
timing parameters.
• The CAL_CSI2_COMPLEXIO_CFG_l register contains the PWR_AUTO and PWR_CMD bit fields,
which affect the power management of the complex I/Os.
The Complex I/O FSM has three power states: ON, OFF, and Ultralow Power (ULP). Two operation
modes are available:.
• Automatic mode, when the CAL_CSI2_COMPLEXIO_CFG_l[24] PWR_AUTO bit is set to 1. The
transitions between ON and ULP states is done automatically based on the received ULPM signals
from the complex I/O for the active lanes defined in CAL_CSI2_COMPLEXIO_CFG_l[]
DATAx_POSITION bit-field, where x = [1...4].
• Manual mode, when the CAL_CSI2_COMPLEXIO_CFG_l[24] PWR_AUTO bit is set to 0 (default).
The complex I/O power state is controlled by the CAL_CSI2_COMPLEXIO_CFG_l[28:27] PWR_CMD bit field. The allowed transitions are: OFF <-> ON and ON <-> ULP.
Figure 7-15 shows the complex I/O power finite state-machine (FSM).
Another register, CAL_CSI2_TIMING_l, is used to control the power state of the complex I/O modules with regard to the differential line state. This register controls the mode of the three complex I/Os (RxMode and NoRxMode) and the delay between the differential lanes in STOP state and the complex I/O on NoRxMode. The CAL_CSI2_TIMING_l[15] FORCE_RX_MODE_IO1 bit sets the complex I/O in RxMode or NoRxMode (stopped mode). The FORCE_RX_MODE_IO1 bit is automatically reset to 0 by hardware when the counter ends and the FSM returns to NoRxMode. Three bits (CAL_CSI2_TIMING_l[14] STOP_STATE_X16_IO1, CAL_CSI2_TIMING_l[13] STOP_STATE_X4_IO1, and the CAL_CSI2_TIMING_l[12:0] STOP_STATE_COUNTER_IO1 bit field) configure the delay between line stop mode and complex I/O stop mode. The delay represents the number of functional clock cycles and can be calculated as follows:
Total delay in functional clock cycles =
CAL_CSI2_TIMING_l.STOP_STATE_COUNTER_IO1 x
(1 + CAL_CSI2_TIMING_l.STOP_STATE_X16_IO1 x 15) x
(1 + CAL_CSI2_TIMING_l.STOP_STATE_X4_IO1 x 3).
Table 7-322 lists the possible values of the delay, in terms of the functional clock cycles, depending on the values of the STOP_STATE_X16_IO1 and STOP_STATE_X4_IO1 bits.
CAL asserts FORCERXMODE signal when the bit-field CAL_CSI2_TIMING_l[15]
FORCE_RX_MODE_IO1 is set by the SW. It can be reset by SW or automatically by HW when the time out occurs. At the same time the signal is asserted, the logic starts monitoring the StopState[0:4] signals corresponding only to the enabled lanes. When all of StopState signals for only the enabled lanes are asserted by the complex IO, the timer starts. When one of the signals, for the enabled lanes only, is not in StopState, the timer is reloaded and the logic re-starts monitoring the stop state signals. When the timer period is finished, the ForceRxMode signal is de-asserted.
7.2.4.2.3 ISS CSI2 PHY MIPI D-PHY Link Initialization Sequence
The MIPI D-PHY initialization sequence is not implemented within CSI2 PHY. The CAL CSI2 low level protocol coordinates the PHY initialization. The controller must ensure that the CSI2 PHY is held in RESET/WAIT for RX mode until the D-PHY transmitter is powered up and the link comes to the defined state. The controller can use the STOPSTATE and FORCERXMODE signals of CSI2 PHY for this purpose. STOPSTATE indicates the line states, while FORCERXMODE forces the receiver state-machine into "wait for stop state". One possible initialization sequence is:
To fully initialize the CSI2 PHY, perform the following steps:
1. Configure all CSI2 low level protocol registers to be ready to receive signals/data from the CSI2 PHY:
i. Set CAL_CSI2_COMPLEXIO_CFG_l[18:16] DATA4_POSITION.
ii. Set CAL_CSI2_COMPLEXIO_CFG_l[14:12] DATA3_POSITION.
iii. Set CAL_CSI2_COMPLEXIO_CFG_l[10:8] DATA2_POSITION.
iv. Set CAL_CSI2_COMPLEXIO_CFG_l[6:4] DATA1_POSITION.
v. Set CAL_CSI2_COMPLEXIO_CFG_l[2:0] CLOCK_POSITION.
vi. Set the CTRL_CORE_CAMERRX_CONTROL[2:1] CSIPORTA_CAMMODE for CSI2_PHY1.
CAUTION
This must be done before the CSI2 PHY is active.
vii. A dedicated internal clock gate control is present for each PHY. Enable/disable the internal
CTRLCLK from the CTRL_CORE_CAMERRX_CONTROL register by setting the following bits:
• [0] CSIPORTA_CTRLCLKEN for CSI2_PHY1
2. CSI2 PHY and link initialization sequence:
a. Deassert the CSI2 PHY reset.
i. Set CAL_CSI2_COMPLEXIO_CFG_l[30] RESET_CTRL to 0x1.
CAUTION
For the CAL_CSI2_COMPLEXIO_CFG_l[29] RESET_DONE bit to be set to
0x1 (reset completed), the external sensor must to be active and sending
the MIPI HS BYTECLK.
The following registers can be set only after deasserting the CSI2 PHY reset and before asserting
the FORCERXMODE signal:
• REG0
• REG1
• REG2
• REG3
• REG6
• REG7
• REG8
• REG9
• REG10
b. Assert the FORCERXMODE signal:
i. Set CAL_CSI2_TIMING_l[15] FORCE_RX_MODE_IO1 to 0x1.
c. Connect pulldown on link (DP/DN) by asserting the respective PIPD* signals (PIPD* = 0):
For CSI2_PHY1 pulldown on signals through the corresponding bit-fields in padconf register
CTRL_CORE_SMA_SW_10.
d. Power up the CSI2 PHY:
a. Set CAL_CSI2_COMPLEXIO_CFG_l[28:27] PWR_CMD to 0x1.
e. Check whether the state status reaches the ON state:
• CAL_CSI2_COMPLEXIO_CFG_l[26:25] PWR_STATUS = 0x1
f. Wait for STOPSTATE = 1 (for all enabled lane modules):
a. The timer is set through the CAL_CSI2_TIMING_l[14:0] bit field. The reset value can be kept.
b. Wait until CAL_CSI2_TIMING_l[15] FORCE_RX_MODE_IO1 = 0x0. It is automatically put at 0
when all enabled lanes are in STOPSTATE and the timer is finished.
g. Release PIPD* (PIPD* = 1).
For CSI2_PHY1 pullup on signals through the corresponding bit-fields in padconf register
CTRL_CORE_SMA_SW_10.
3. The CSI2 PHY is initialized and ready/active in CSI-2 (D-PHY) mode.
7.2.4.2.5 ISS CSI2 PHY Error Signals
In D-PHY mode, the CSI2 PHY supports the following error detection and signaling to the associated
receiver:
• ERRSOTHS: Flags 1-bit errors in the HS start of transmission synchronization pattern. In this error
scenario, the CSI2 PHY continues to receive the data and pass it to the receiver, but confidence in the
data may be low, because of the 1-bit error seen in sync. This signal, if asserted, is high for one cycle
of RXBYTECLKHS.
• ERRSOTSYNCHS: Flags multiple bit errors in the HS start of transmission synchronization pattern. In this case, the CSI2 PHY cannot achieve proper synchronization and does not pass the received data
to the receiver. This signal, if asserted, is high for one cycle of RXBYTECLKHS.
• ERRCONTROL: Flags the control sequence error; that is, when the LP sequence observed on line is
not recognized as a valid control sequence. This signal, if asserted, is high until the next change in the
state of the LP line.
• ERRESC: Flags the escape entry error; that is, when the escape entry sequence is unrecognized. This
signal, if asserted, is high until the next change in the state of the LP line.
• ERRSYNCESC: Flags the low-power data transmission synchronization error. This error is flagged if
the number of bits received during a low-power data transmission is not a multiple of 8 bits. This
signal, if asserted, is high until the next change in the state of the LP line. In case the number of
received bits is 1 less than a multiple of 8, RXVALIDESC is also asserted together with
ERRSYNCESC, and an erroneous data byte is output on RXDATAESC. In other cases of this error,
RXVALIDESC is not asserted and an erroneous data byte is not sent out.
7.2.6.3 ISS CAL Functional Description
7.2.6.3.1 CAL Block Diagram
Figure 7-25 and Figure 7-26 show a top-level overview block diagrams of the CAL_A and CAL_B
modules, respectively.
merges data from multiple lanes, detects and correct errors, extracts the virtual channel ID, detects and
extracts the synchronization codes and re-formats the data into a stream understood by the CAL
processing pipeline. Each PPI interface has a small FIFO to accommodate latencies to access the CAL
pipeline.
The RD DMA block reads pixel data from memory and re-formats the data into a stream understood by
the CAL processing pipeline.
The data from all sources is multiplexed with 64-bit granularity and sent to the CAL pipeline for further processing. The data pipeline forwards 64-bit wide data words as well as a 5-bit wide data qualifier + 4-bit validity qualifier + 5-bit CPORT number referred as TAG in this chapter.
The TAG is set by the data source and controls how the different stages in the processing pipeline
behave. Figure 7-27 summarizes possible values for the data qualifier and the corresponding behavior of the different processing stages:
An active low asynchronous hardware reset is provided by the ISS. It is internally resynchronized to the
functional clock domain. A software reset is triggered by setting the CAL_HL_SYSCONFIG[0] SOFTRESET bit to 0x1. The CAL hardware ensures that the software reset is performed on clean OCP transactions boundaries and that no OCP protocol violation can occur due to the software reset. Mainly, it finishes ongoing OCP transactions and prevents generation of new ones.
The CAL_HL_SYSCONFIG[0] SOFTRESET bit is automatically cleared by hardware when the software reset has completed. The software reset will never complete, if outstanding OCP responses are not returned. This situation is only expected when the slave with which CAL is communicating fails. A
hardware reset is reset in that case.
A software reset is faster than a hardware reset controlled by the device ISS module. In fact, to avoid
OCP protocol violations, the ISS module first puts the CAL into Idle mode. The ISS can only perform a
clean hardware reset once CAL has acknowledged the IDLE request. That only happens once the CAL
has flushed all pending traffic. A software reset simply waits for the next clean OCP transaction boundary without finishing the frame. OCPC is fully functional after a software reset.
7.2.6.3.3 CAL Clock Configuration
CAL receives one functional clock from ISS that is also used for the OCP ports. The configuration port
(OCPC) operates at half the functional clock speed (clock enable signal used).
In addition, CAL receives one asynchronous clock for each PPI interface. This clock is generated from the bit clock received from the image sensor and converted into a byte clock by the CSI2 PHY.
CAL also provides the PWRSCP clock used to configure the CSI2 PHY. It corresponds to the CAL
functional clock divided by 4 and is gated depending on functional needs.
(OCPC) operates at half the functional clock speed (clock enable signal used).
In addition, CAL receives one asynchronous clock for each PPI interface. This clock is generated from the bit clock received from the image sensor and converted into a byte clock by the CSI2 PHY.
CAL also provides the PWRSCP clock used to configure the CSI2 PHY. It corresponds to the CAL
functional clock divided by 4 and is gated depending on functional needs.
7.2.6.3.5 CAL Interrupt Events
Section 7.2.6.2.1, CAL Main Integration Attributes). The CAL_x_IRQ is merged at ISS top level IRQ
merger.
NOTE: The CAL does not provide an event to detect Attribute Payload data at low level protocol
level. Attribute data can only be sent to memory and therefore software can use the
IRQ_WDMA_START / END events detected by the WR_DMA block.
Table 7-477 lists the event generation and corresponding registers of the CSI2 Low Level Protocol
engines.
On CAL top level, the different events trigger IRQs, if they have been enabled using the
CAL_HL_IRQENABLE_SET_j register. The status can be read from the CAL_HL_IRQSTATUS_j register.
The event-to-register mapping is shown in Figure 7-28.
• IRQ_PPI1_VC and IRQ_PPI0_VC refer to events controlled by CAL_CSI2_VC_IRQENABLE_l register and described in Table 7-477, CSI2 Low Level Protocol Interrupts.
• IRQ_PPI1 and IRQ_PPI1 refer to events controlled by CAL_CSI2_COMPLEXIO_IRQENABLE_l and described in Table 7-477, CSI2 Low Level Protocol Interrupts and Table 7-478, CSI2 Complex I/O
Interrupts.
All events are merged into a single CAL_IRQ signal available at CAL boundary.
NOTE: CAL_HL_IRQSTATUS_j does not refer to events, but is used to collect events tracked in CAL_CSI2_VC_IRQSTATUS_l and CAL_CSI2_COMPLEXIO_IRQSTATUS_l registers, and enabled by CAL_CSI2_VC_IRQENABLE_l and CAL_CSI2_COMPLEXIO_IRQENABLE_l registers. SW must use them to detect, if a Complex I/O or PPI event is pending and then get event details from the relevant second level IRQ status register. SW must only clear those events by setting the relevant bits in the CAL_CSI2_VC_IRQSTATUS_l and CAL_CSI2_COMPLEXIO_IRQSTATUS_l registers. CAL_HL_IRQSTATUS_j is automatically cleared by the HW when no more enabled Complex I/O or PPI events are pending
7.2.6.3.6 CAL CSI2 Low Level Protocol
CAL_A has two PPI interfaces that connect directly to two D-PHY instances of up to 4 lanes each. It also implements an OCP to SCP bridge to access the complex IO internal registers.
7.2.6.3.6.1 CSI2 Physical Layer
The CSI2 serial interface is a unidirectional differential serial interface with data/clock for the physical
layer. The maximum CSI2 data transfer capacity is 1500 Mbps per data lane. The speed of the link is
reconfigurable by SW only when the CSI2 PHY is in "stop state" or in ULPM (ulra-low power mode).
Data-clock signaling consists of two to five differential signal pairs: from one to four data lanes and one
clock lane. The minimum configuration is one data pair and one clock pair.
• The data signal carries the bit-serial data. The CSI2 transmitter in the image sensor sends the data inquadrature with the dual-data rate (DDR) clock in HS mode; otherwise, the clock is extracted from the received data in LS (low speed) mode. Data is transmitted byte-wise, LSB first. The CSI2 complex I/O receives the data and sends the byte stream to the CSI2 LL protocol core.
• The clock signal carries the DDR clock signal.
• The SW has to configure the order of the data lanes to indicate the byte order while merging the
received bytes for each CSI2 PHY into a byte stream.
Figure 7-29 is the CSI2 Low Level Protocol engine block diagram (it assumes there are four CSI2 image sensor data lines). The CSI2 receiver receives the byte data coming from a CSI2 D-PHY receiver
(CSI2_PHY1 with up to four data pairs), converts it to byte stream, detects and corrects errors, extracts
the virtual channel ID, detects and extracts the synchronization codes, reformats the data, and forwards it to the the CAL Data Stream Merger.
Each physical lane can be a data or clock lane with a restriction to the fourth lane, which can only be data (see Section 7.2.4.1, CSI2 PHY Overview). The clock/data lane must be configured before transmission to indicate the byte order, while merging the received bytes into a byte stream shows the reachable speed per data lane function of data lane numbers.
Lanes are configured through the CAL_CSI2_COMPLEXIO_CFG_l registers. The CAL_CSI2_COMPLEXIO_CFG_l[2:0] CLOCK_POSITION bit field and the CAL_CSI2_COMPLEXIO_CFG_l[3] CLOCK_POL bit configure which lane transmits the clock and define its polarity. The DATAx_POSITION and DATAx_POL bit-fields configure the data lanes and their polarity, where x is the number of the data lane (x = 1 to 4). When the DATAx_POSITION field is set to 0, data lane x is not used.
7.2.6.3.6.2 CSI2 Multi-lane Layer and Lane Merger
The layer consists of lane merger logic in order to merge the incoming serial stream into a byte stream.
The bits are send with LSB first. The number of active lanes is configurable through register. The order of the lanes at the CSI-2 receiver core is also configurable. The number of lanes can be changed only in
ULPM or when all data lanes are in "stop state" (OFF mode).
The lane merger can merge up to four lanes into a single byte stream, and is not used for a single lane.
Figure 7-30 to Figure 7-33 show the byte position into each serial link for one to four data lane
configurations. The byte stream always starts from lane 1. It finishes on one of the lanes, depending on
the number of bytes to receive and the number of lanes.
7.2.6.3.6.3 CSI2 Protocol Layer
The low-level protocol (LLP) is a byte-oriented protocol from the lane merger layer. It supports short and long packet formats.
The CSI2 protocol layer defines how image-sensor data is transported onto the physical layer.
The feature set of the protocol layer implemented by the CSI2 receiver is:
• Transport of arbitrary data (payload-independent)
• 8-bit word size
• Support for up to four interleaved virtual channels on the same link
• Special packets for frame-start, frame-end, line-start, and line-end information
• Error-correction code (ECC) for 1-bit error correction or 2-bit error detection in the header
• 16-bit checksum code for payload error detection
Figure 7-34 shows the CSI2 protocol layer with short and long packets.
7.2.6.3.6.3.1 CSI2 Short Packet
A short packet is identified by data types 0x00 to 0x0F. A short packet can be used for frame or line
synchronization or for generic data. A short packet contains only a Packet Header; a Packet Footer is not be present. Figure 7-35 shows the structure of a short packet.
NOTE: CAL accepts but does not use the frame number or line numbers transmitted by the sensor
as required by the MIPI CSI-2 standard.
The ECC byte allows single-bit errors to be corrected and 2-bit errors to be detected in the short packet.
Short packets apply to all contexts using the same virtual channel ID . The data type associated with the
context is not used to distinguish which context is used when receiving short packets.
7.2.6.3.6.3.2 CSI2 Long Packet
A long packet is identified by data types 0x10 to 0x37. A long packet consists of three elements:
• A 32-bit packet header (PH)
• An application-specific data payload with a variable number of 8-bit data words
• A 16-bit packet footer (PF)
The packet header is further composed of three elements:
• An 8-bit data identifier
• A 16-bit word count field
• An 8-bit ECC
The packet footer has one element, a 16-bit checksum.
Figure 7-36 and Table 7-483 show the structure of a long packet.
There are no restrictions on the size of the packet data, but each data format can impose additional
restrictions on the length of the payload data (for example, a multiple of 4 bytes).
7.2.6.3.6.3.3 CSI2 ECC and Checksum Generation
The CSI2 receiver includes an ECC in the packet header and a checksum in the packet footer for longpacket transmission. These two fields can be used to detect and/or correct errors in the received packet.
7.2.6.3.6.3.3.1 CSI2 ECC
To detect and correct transmission errors of the header of short and long packets, an 8-bit ECC is
included in the header of packets (short and long packet). It allows single-bit errors to be corrected and 2-bit errors to be detected in the packet header.
The ECC concerns all the fields for a short packet (data ID and short-packet data field) and the packet
header for a long packet (data ID and word count). The ECC can only correct one error. Additional errors cannot be repaired, but they are flagged. After the end of the Packet Header, the receiver reads the next Word Count * 8-bit data words of the Data Payload. While reading the Data Payload the receiver does not look for any embedded sync codes. Therefore, there are no limitations on the value of a data word. The CSI2 receiver ECC is compared against the CSI2 transmitter ECC embedded in the bitstream. If the ECC does not match, an interrupt is triggered.
For long and short packets, the correction is always done, if there is only one error per packet header.
An ECC error with or without correction can be reported at two levels, depending on the type of packet.
Table 7-484 describes the field in which events are logged. Logging cannot be disabled, but SW can set
the corresponding bit in the CAL_CSI2_VC_IRQENABLE_l register to prevent event generation at a
higher level.
The ECC check can be disabled (short and long packet) by setting the CAL_CSI2_PPI_CTRL_l[2]
ECC_EN bit to 0. Setting the bit to 1 enables the ECC check.
Refer to the MIPI CSI-2 1.0 standard for more details on ECC generation.
7.2.6.3.6.3.3.2 CSI2 Checksum
Once the CSI2 receiver has read the Data Payload, it reads the checksum in the Packet Footer. In the
generic case, the length of the Data Payload is a multiple of 8-bit data words. In addition, each data format may impose additional restrictions on the length of the payload data, e.g. multiple of four bytes. Each byte is transmitted LSB first.
To detect errors in transmission of the payload of long packets, a 16-bit CRC checksum is computed on
the payload of the long packets in the transmitter. This CRC is stored in the packet footer. The CSI2
receiver checksum is compared against the CSI-2 transmitter checksum. If the checksum does not match, an interrupt is triggered.
CRC errors are logged in the CAL_CSI2_VC_IRQSTATUS_l[] CS_IRQ_x (where x = [0 to 3]) register bitfields. Logging cannot be disabled, but SW can configure the corresponding bit in the
CAL_CSI2_VC_IRQENABLE_l register to prevent event generation at a higher level.
Since the payload has been already transferred into memory, it is not possible to discard the data but only to generate an interrupt.
7.2.6.3.6.3.5 CSI2 Data Identifier
The data identifier byte contains the virtual channel identifier (VC) value and the data-type (DT) value, as shown in Figure 7-37. The VC value is contained in the 2 MSBs of the data identifier byte. The DT value is in the 6 LSBs of the data identifier byte.
7.2.6.3.6.3.6 CSI2 Virtual Channel ID
The CSI2 protocol layer transports virtual channels. Virtual channels are built of frames. A frame can
comprise embedded data and image-sensor data. Two contexts are used to send the two types of data
(embedded and image-sensor) separately. Each frame is identified by unique mandatory synchronization codes: frame start and frame end. Line start and line end synchronization codes are optional for the transmitter. A set of registers is associated with each context defined by the virtual channel ID and the data type. Figure 7-38 shows a virtual channel.
7.2.6.3.6.3.7 CSI2 Synchronization Codes
Each frame is clearly identified by a synchronization code for the start of frame and the end of frame. The start of line and end of line can be sent by the image sensor but it is optional.
In order to send the synchronization codes, the camera uses the short packets. Data reception from the
image-sensor module uses four synchronization codes embedded in the serial bitstream:
• FSC: Identifies the start of a new frame
• LSC: Identifies the start of a new line; received for every line
• LEC: Identifies the end of a line; received for every line
• FEC: Identifies the end of the last line and the end of the current frame
Table 7-485 summarizes the synchronization code values.
7.2.6.3.6.3.8 CSI2 Generic Short Packet Codes
When the synchronization code value is from 0x8 to 0xF, the short packet is called a generic short packet. Short packets are not processed by the camera interface hardware. A generic short packet is stored in a register without the ECC and an interrupt can be generated. Therefore, generic short packets must be handled by software.
An interrupt (logged in CAL_CSI2_COMPLEXIO_IRQSTATUS_l[28] SHORT_PACKET register bit)
indicates to the application the short packet event. Logging cannot be disabled, but SW can set the
corresponding bit in the CAL_CSI2_COMPLEXIO_IRQENABLE_l register to prevent event generation at a higher level. It is SW responsibility to read the register CAL_CSI2_SHORT_PACKET_l before the next short packet with a code between 0x8 and 0xF. There is a single register for capturing the generic short packets since there is no data type in it to be associated with context.
7.2.6.3.6.3.9 CSI2 Frame Structure and Data
Each frame consists of short packets to indicate SOF and EOF. Optional short packets for start of line and end of line can be sent by the image sensor. Some information before and after the picture data can be sent by the image sensor as SOF and EOF information. It is decoded by the receiver and is sent to the system memory through the OCPO port. For each frame, the pixel data (arbitrary data or user-defined byte data) are valid only after an SOF short packet. If the data are invalid, they are discarded by the protocol engine. A frame contains embedded data and image-sensor data. Figure 7-39 shows where the embedded data and image-sensor data are in the frame. The frame is scanned in raster order starting from the top-left corner, as shown in Figure 7-39 and Figure 7-40. The following definitions for a frame apply:
• Zero or more SOF status lines (SOF lines) can be embedded at the beginning of a CSI2 frame.
• The image data comprises pixels of the same or different data formats. The image embedded data is
carried using separate data types and virtual channels (see Section 7.2.6.3.6.3.10, CSI2 Virtual
Channel and Context).
• Zero or more EOF status lines (EOF lines) can be embedded at the end of a CSI2 frame.
• The SOF lines, pixel data, and EOF lines do not overlap.
The CSI2 receiver does not use the information in the status lines. However, it extracts it and stores it in
memory for use by software. Because the data types are different, the data is carried using separate data types called virtual channels. Those must be mapped to the adequate context. The CSI2 receiver uses a different context for embedded data and image-sensor data. See Section 7.2.6.3.6.3.10, CSI2 Virtual Channel and Context. Embedded data is supported as a context by the CSI2 receiver; therefore, there is no specific hardware support for embedded data.
Figure 7-40 shows the frame structure of a YUV4:2:2 interlaced video frame without embedded data.
The period between the LEC and the new LSC is called line blanking period. The time between the FEC and the new FSC is called frame blanking period. The receiver works with "near zero" line blanking period.
NOTE: The embedded information (SOF & EOF lines) is never compressed (no DPCM). The embedded information covers full lines. The embedded information is not encoded in the same data format as the pixel data. The CSI-2 receiver extracts the embedded information but does not modify the data format. The pixel data can be compressed.
7.2.6.3.6.3.10 CSI2 Virtual Channel and Context
The CSI2 protocol layer transports virtual channels. The virtual channels separate different data flows
interleaved in the same data stream. Each virtual channel is identified by a unique channel identification
number in the packet header. This channel identification number is encoded in the 2-bit code.
The CSI2 receiver monitors the channel identifier number and demultiplexes the interleaved data streams.
The CSI2 receiver supports up to four concurrent virtual channels. The virtual channel values used for
each channel are as follows:
• Virtual channel 0 -> 0x0
• Virtual channel 1 -> 0x1
• Virtual channel 2 -> 0x2
• Virtual channel 3 -> 0x3
7.2.6.3.6.4 CSI2 TAG Generation FSM
Figure 7-41 shows how the synchronization codes for the CAL internal pipeline are extracted from the
CSI-2 stream. CSI-2 PPI IF corresponds to the byte stream after lane merge and PHY LS -> HS transition detection. CSI-2 LL state corresponds to the internal state of the TAG generation engine. CAL pipeline corresponds to the tags sent to the CAL processing pipeline.
Data is packed into words of 64-bits before it can be sent to the shared CAL processing pipeline. Each
PPI has its own TAG generation & packing state machine. Both CSI2 PHYs are therefore independent
and can operate simultaneously. Each PPI FSM has 8 copies of the CAL_CSI2_CTXy_l (y = [0 to 7],
CAL_CSI2_CTX0_l through CAL_CSI2_CTX7_l) state registers (that is, contexts).
To use a context, SW must define:
• The used virtual channel (through CAL_CSI2_CTXy_l[7:0] VC register bit-field)
• The expected MIPI CSI-2 Data Type (through CAL_CSI2_CTXy_l[5:0] DT bit-field)
• The CPort ID to use (through CAL_CSI2_CTXy_l[12:8] CPORT bit-field) for the data, and if it should be tagged as Attribute (that is, Embedded) data or as Pixel data (through CAL_CSI2_CTXy_l[13] ATT bit).
Attribute data is tagged using ATT_DAT_S, ATT_DAT and ATT_E tags. Pixel data is tagged using
PIX_DAT_FS, PIX_DAT, PIX_DAT_LE, PIX_DAT_LS, PIX_DAT_FE. Data reception is disabled by setting CAL_CSI2_CTXy_l[5:0] DT bit to 0.
The tag generation FSM accumulates words of up to 64-bits of data from the physical interface. Two SW selectable modes are supported:
• Line mode (set by CAL_CSI2_CTXy_l[14] PACK_MODE = 0). In this mode CAL generates frame
(PIX_DAT_FS; PIX_DAT_FE) and line (PIX_DAT_LS, PIX_DAT_LE) synchronization codes using
synchronization information provided by the CSI-2 transmitter. It pads words with 0's when the line end
or frame end is reached and generates the adequate data validity qualifier (VQ). Line and frame starts
always correspond to full 64-bit words (VQ=0x0). This is typically the mode to be used to receive pixel
data.
• Frame mode (set by CAL_CSI2_CTXy_l[14] PACK_MODE = 1). In this mode CAL only generates
PIX_DAT_FS and PIX_DAT_FE synchronization codes. PIX_DAT_LE and PIX_DAT_LS are replaced
by PIX_DAT and adequate data validity qualifiers are generated to create a contiguous stream. This
mode is typically used to receive a JPEG frame from a CSI-2 camera.
This appended dummy data can be cropped by the write DMA, or the hardware accelerator attached to
the Video port. The shared CAL processing pipeline therefore always receives full 64-bit words. The line length is detected from the CSI-2 long packet header and mismatches are detected through CRC errors. The tag generation FSM ensures that only valid TAG sequences can be provided to the shared CAL processing pipeline. FS, LS and LE codes are directly extracted from the CSI-2 stream. The FE code is not directly available and can be generated by two mechanisms:
• If SW knows the number of lines transmitted by the camera, it must write it into the
CAL_CSI2_CTXy_l[29:16] LINES register bit-field. The tag generation FSM will send a FE TAG for the last received line of each frame instead of the LE TAG. This leads to regular video timings and avoids potential artifacts. CAL generates the FE_CODE tag when the FE short packet is received earlier than expected (for example, incorrect configuration or lines discarded due to transmission errors). The PIX_DATA_FE tag is generated at the end of the last line specified in CAL_CSI2_CTXy_l[29:16] LINES bit-field. Additional lines received for the same frame are discarded.
• If the number of lines is not known, SW must set the CAL_CSI2_CTXy_l[29:16] LINES register bit-field to 0. The tag generation FSM sends the PIX_DAT_LE TAG for the last line in the case and FE_CODE tag line when a FE short packet is received.
No LS/LE tags are generated when CAL_CSI2_CTXy_l[13] ATT = 1.
Figure 7-42 through Figure 7-45 illustrate the operation of the packing stage.
Data is discarded and an FIFO_OVR event is triggered when the CAL shared pipeline cannot accept the
data from PPI interfaces fast enough. The tag generation FSM ensures however that only valid tag
sequences can be generated:
• Only a few words are dropped in the middle of a line: corresponding data words are dropped and
synchronization TAGs (LE or FE) are transmitted normally. The line where the overflow has occurred is therefore corrupted (that is, pixels shifted left), but synchronization is recovered from the next line start.
• The overflow condition persists over a line or frame boundary: one or multiple lines/frames are
dropped. HW waits until one word becomes available in the PPI FIFO and inserts a data word with
TAG FE. It then waits for the next FS to resume normal operation.
No specific SW intervention is required to recover synchronization and the HW ensures that no protocol violations or accesses outside of allocated buffers could occur.
NOTE: Optional MIPI CSI-2 LS and LE short packets are ignored by CAL. They are allowed in the
datastream from the camera, but are not used and not forwarded to the CAL shared
processing pipeline. CAL does not have a specific mechanism to ignore CRC checking. SW must simply disable the CS_IRQ event. CAL does not discard data with invalid CRC.
7.2.6.3.7 CAL Data Stream Merger
Two possible sources (2 x PPI, OCPI and RD DMA) can produce data that is sent through the shared CAL processing pipeline. The shared processing pipeline is time multiplexed at 64-bit word level. Data from the PPI interfaces cannot be stalled. It is therefore stored in a small FIFO (per each PPI) to compensate shared pipeline access latencies. Data from OCPI can be stalled to some extend as the external UniPro engine has its own FIFO. Data from the RD DMA is not timing critical.
A fixed priority arbitration scheme is used when data is ready from multiple sources. PPI_0 source is with highest priority, after that PPI_1. PPI FIFOs are only intended to compensate internal pipeline access latencies. It is SW responsibility to ensure that the total pixel rates are compatible with CAL capabilities.
7.2.6.3.8 CAL Pixel Extraction
Software must configure which CPORT a given pixel processing context must process, by setting the
CAL_PIX_PROC_i[23:19] CPORT register bit-field to the CPORT ID. The operation to perform is defined by the CAL_PIX_PROC_i[4:1] EXTRACT bit-field.
The data of a CPORT is forwarded without modification when pixel processing is disabled for that CPORT.
The pixel extraction stage receives up to 64 bits per cycle and can output either 64 bits (bypass) or 4
samples (6 ~ 16 bits per sample; 1 sample = 1 pixel for RAW data) per cycle.
Extracted pixels are left padded with 0's to fill 16-bit containers (for example, for RAW10: out[15:10]=0's and out[9:0]=data)
It only processes data tagged as DAT_PIX_FS, DAT_PIX_LS, DAT_PIX, DAT_PIX_FE, and DAT_PIX_LE (see Figure 7-27, CAL Data Pipeline TAGs, for definitions). All other data types are simply forwarded (that is, output = input).
DAT_PIX_FS and DAT_PIX_LS tags reset the pixel extraction state-machine. That ensures proper
recovery in case the pixel decoder goes out of sync for some reason (for example, TxBuffer overflow in
the transmitter, wrong configuration, bad synchronization between hardware and software).
Four samples do not necessarily align with a complete 64-bit word and several bits remain unused. They are stored locally until enough data is available to extract four additional samples or the end of a line has been reached (that is, TAG = PIX_DAT_LE or PIX_DAT_FE). The last 64-bit word can be padded with 0's, if there is not enough data to generate 4 pixels after all data tagged as PIX_DAT_LE or PIX_DAT_FE has been processed.
The incoming dataflow (from OCPI or Read DMA) can be stalled to prevent data corruption:
• When downstream modules cannot accept the data (that is, back-pressure from DPCM decoder)
• The extraction engine can only extract up to 4 pixels / cycle or forward complete 64-bit words without
processing
Contexts can be interleaved with 64-bit word granularity (that is, two consecutive words can have different TAGs). The number of contexts is as defined in the CAL_HL_HWINFO[12:8] PCTX register bit-field
Figure 7-46 shows the internal architecture of the pixel extraction module. It is composed of a 64-bit input buffer plus one 64-bit buffer per context (the number of contexts as defined in the CAL_HL_HWINFO[12:8] PCTX register bit-field). It has two computation units that extract four pixels per cycle and return the unused bits into the local storage.
NOTE: The pixel extraction engine does not process the VQ (data validity qualifier) generated by the
CSI-2 data packing stage. It forwards the VQ when bypass mode is selected and replaces it
by VQ=0 (all data valid) when data expansion is performed.
7.2.6.3.9 CAL DPCM Decoding and Encoding
The CAL DPCM decoder block only processes data tagged as DAT_PIX_FS, DAT_PIX_LS, DAT_PIX, DAT_PIX_LE and DAT_PIX_FE (as defined in Figure 7-27, CAL Data Pipeline TAGs). All other data types or data belonging to CPORTs where DPCM encode/decode is disabled, is simply forwarded. Software chooses which CPORT a given pixel processing context must process by setting the CAL_PIX_PROC_i[23:19] CPORT register bit-field to the CPORT ID. The DPCM decompression operation is selected though the CAL_PIX_PROC_i[9:5] DPCMD bit-field, and the DPCM compression operation is selected though the CAL_PIX_PROC_i[15:11] DPCME bit-field.
PIX_DAT_FS and PIX_DAT_LS tags initialize the DPCM encoder.
PIX_DAT_FS and PIX_DAT_LS tags initialize the DPCM decoder, except when the previous TAG
received on that context was DPCM_INIT. DPCM_INIT copies the received word into the context status register of the DPCM decoder and discards the initialization word (that is, it is not forwarded to the next pipeline stage). The next word of four pixels received on that context is DPCM decoded and the usual initialization step is skipped. That feature is intended to enable DPCM decoding of an image in multiple vertical stripes without re-decoding each line from the beginning.
The DPCM encoder and decoder are independent. They preserve state for each of the pixel processing
contexts (defined in CAL_HL_HWINFO[12:8] PCTX register bit-field), so that the encoder and the decoder context can be swapped with 4-pixel granularity.
The DPCM encoder and decoder can stall the incoming pixel from the pixel extraction block, if it arrives faster than what they can handle (that is, PREDICTOR2 selection or dataflow stalled by the pixel packing stage/write DMA).
7.2.6.3.11 CAL Pixel Packing
CAL_PIX_PROC_i[23:19] CPORT bit field to the CPORT ID. The operation to perform is defined by the CAL_PIX_PROC_i[18:16] PACK bit field.
The pixel packing stage only processes data tagged as PIX_DAT_FS, PIX_DAT_LS, PIX_DAT,
PIX_DAT_FE and PIX_DAT_LE. All other data types or data belonging to a C-Port where pixel packing is disabled is simply forwarded. The packing stage is reset by PIX_DAT_FS and PIX_DAT_LS to recover synchronization in case it has been lost.
PIX_DAT_FE and PIX_DAT_LE. All other data types or data belonging to a C-Port where pixel packing is disabled is simply forwarded. The packing stage is reset by PIX_DAT_FS and PIX_DAT_LS to recover synchronization in case it has been lost.
The pixel packing stage is flushed by a PIX_DAT_FE, PIX_DAT_LE and PIX_DAT_LE TAG: the last
generated 64-bit word may be padded with 0’s
generated 64-bit word may be padded with 0’s
Pixel packing is a symmetrical processing step to the pixel extraction (see Section 7.2.6.3.8, CAL Pixel
Extraction). However, the list of supported formats is different. The pixel packing stage also has buffering to preserve temporary (that is, incomplete) data when contexts are switched. Figure 7-51 below shows the internal architecture of the packing stage.
Extraction). However, the list of supported formats is different. The pixel packing stage also has buffering to preserve temporary (that is, incomplete) data when contexts are switched. Figure 7-51 below shows the internal architecture of the packing stage.
Supported packing modes are:
• RAW8 (8 bits per pixel)
• RAW10 (MIPI) (10 bits per pixel)
• RAW12 (linear) (12 bits per pixel)
• RAW12 (MIPI) (12 bits per pixel)
• RAW16 (16 bits per pixel)
• ARGB (32 bits per pixel)
The pixel packing engine does not process the VQ (data validity qualifier) generated by the CSI-2 data
packing stage. It forwards the VQ when bypass mode is selected and replaces it by VQ=0 (all data valid) when data expansion is performed.
Figure 7-52 shows how the packing engine packs 32 consecutive pixels (equal to 8 active input cycles as 4 pixels are provided per cycle) into five 64-bit words ready to be sent to memory (REM).
Figure 7-53 shows how the packing engine packs consecutive pixels (Px corresponds to a 16-bit pixel in the internal pipeline) into 64-bit words.
7.2.6.3.12 CAL Write DMA
NOTE: CAL_A is intended as an sensor inteface and write to memory port.
7.2.6.3.12.1 CAL Write DMA Overview
The memory write DMA has WCTX (defined in CAL_HL_HWINFO[18:13] WCTX register bit-field)
independent write contexts (that is, logical DMA channels). Each context receives a byte stream over a
64-bit wide bus as well as the TAG. The write DMA filters incoming data using the CPORT number and data type contained in the TAG. Data is only processed, if it matches the CPORT number defined in the CAL_WR_DMA_CTRL_k[13:9] CPORT register bit-field and the data type defined in the CAL_WR_DMA_CTRL_k[8:6] DTAG bit-field. It also uses the received TAG to lookup the adequate context information and control the address generation logic.
Only one write context can process a given data word from the internal pipeline at the time. Said
differently, the write DMA cannot be used to write two copies of the same data into separate locations.
Software must prevent that two active write contexts have the same settings for
CAL_WR_DMA_CTRL_k[13:9] CPORT and CAL_WR_DMA_CTRL_k[8:6] DTAG bit-fields.
Data that is not processed by the write DMA is discarded. Since the write DMA is the last stage in the CAL processing pipeline, it cannot forward data to a next stage.
Figure 7-54 shows a simplified block diagram of the write DMA engine.
7.2.6.3.12.2 CAL Write DMA Data Cropping
It is possible to discard part of the received data for pixel and attribute data (that is, header and control
data cannot be discarded). This is performed inside the write DMA cropping block. The feature is enabled by configuring:
• The position of the 1st byte to preserve in each line in the CAL_WR_DMA_XSIZE_k[15:3] XSKIP
register bit-field
• The number of bytes to preserve for each line in the CAL_WR_DMA_XSIZE_k[31:19] XSIZE bit-field
The cropping block discards unwanted data and modifies data TAG to preserve integrity. For example,
when pixel data is processed:
• PIX_DAT_FS => 1st word of a frame
• PIX_DAT_LS => 1st word of a line, except for the 1st line
• PIX_DAT_LE => last word of a line, except for the last line
• PIX_DAT_FE => last word of a frame
• PIX_DAT => any other pixel data
Cropping is mainly intended to enable partial DPCM decompression and to reduce storage requirements /power consumption when digital zoom is used. No dummy data will be written, if the programmed size is less than what is received. Refer to section Partial DPCM decompression for more details.
Cropping may also be used for attribute data. It cannot be used for header data. It is SW responsibility to not use cropping for header data. HW does not perform any additional checks.
The DMA accumulates data independently for contexts until an OCP write transaction can be generated.
That is the case when enough data is available to generate a full burst or when the end of an image line
has been reached.
NOTE: Data cropping is performed after the DPCM encoder. Therefore, horizontal skipping cannot
be used when data is DPCM encoded. Otherwise, it will be not possible to decode the data,
unless reference samples have been stored to resume decode.
7.2.6.3.12.3 CAL Write DMA Buffer Management
The DMA write buffer has two functions:
• Accumulate enough data to issue efficient OCP transactions
• Buffer data when it cannot be written to the OCPO port
Different write contexts do not have fixed locations in the write buffer to optimize the required buffer size. In fact, at a given point of time only some of the contexts are active while others are idle. There is no reserved space for unused contexts. Also, different contexts have different bandwidth requirements.
Therefore, different amounts of data will pile up for different contexts when OCPO is stalled.
The buffer is divided into slots of 2^(WDMA_SLOTSIZE+7) bytes that are dynamically allocated to a context. CAL maintains some internal status information to manage the buffer:
1) For each slot:
– State (2 bits):
• Empty
• Open (ready to receive more data)
• Closed (does not accept new data; ready for OCP burst generation)
– Level (4 bits): amount of data currently stored in the data slot
• Cleared when data has been sent to OCPO
• Incremented by 8 bytes each time a new word of 64-bits is added
– Destination Address (29 bits): destination address for an OCP burst
• This value is computed when the 1st word of 64-bits is stored in the slot
• All data of the slot is stored contagiously in memory. The HW allocates new slots to skip
memory locations at line ends.
2) For each context:
– Slot current in use (if applicable)
– Destination address
The write DMA uses the data qualifier provided along with data words to pack data in the local working
memory. It has a barrel shifter to pack data when lines ends do not correspond to 64-bit word boundaries and CAL_CSI2_CTXy_l[14] PACK_MODE = 0x1 (Frame mode).
OCP bursts cannot span over multiple slots for design simplification. Refer to section OCP Transaction
Generation for more details.
7.2.6.3.12.4 CAL Write DMA OCP Address Generation
7.2.6.3.12.4.1 Write DMA Buffer Base Address
The buffer base address (refered to as BASE, internal variable that cannot be read by SW) is
automatically updated when an ATT_HDR_S, ATT_DAT_S, CTRL_HDR_S, PIX_HDR_S or PIX_DAT_FS is received by the write DMA using the following algorithm based around CAL_WR_DMA_CTRL_k[2:0] MODE register bit-field:
• MODE = 0x0 (Disable): DMA is disabled
• MODE = 0x1 (Ping/pong destination address on every frame):
– BASE = CAL_WR_DMA_ADDR_k
– CAL_WR_DMA_ADDR_k = CAL_WR_DMA_ADDR_OLD
– CAL_WR_DMA_ADDR_OLD = BASE
• MODE = 0x3 (Initialize start address for continous mode. The first frame will be written at this address and consecutive frames will be appended):
– BASE = CAL_WR_DMA_ADDR_k
– CAL_WR_DMA_ADDR_k = CAL_WR_DMA_ADDR_OLD
– CAL_WR_DMA_ADDR_OLD = LINE_START (See Section 7.2.6.3.12.4.2, Write DMA Line Start
Address, for further details)
– CAL_WR_DMA_CTRL_k[2:0] MODE = 0x2
• MODE = 0x2 (Continously write data to memory):
– BASE = LINE_START + CAL_WR_DMA_OFST_k
• MODE = 0x4 (Use CAL_WR_DMA_ADDR_k as base address)
– BASE = CAL_WR_DMA_ADDR_k
After reset, CAL_WR_DMA_ADDR_OLD = 0x00000000. Software must update the
CAL_WR_DMA_ADDR_k register after the first FE event with a valid destination address. Otherwise, data will be sent to address 0 which is typically not a valid destination.
Регистр CAL_WR_DMA_ADDR_k относится к регистрам, которые имеют дубликат ("shadowing register"), это упоминается в пункте 7.2.6.3.15 "CAL Registers Shadowing" TRM. Table 7-490 summarizes which CAL registers are shadowed.
Для применения схемы "пинг-понг" в wr_dma надо разрешить, размаскировать события для актуального виртуального канала (у меня, 0) FE. При помощи макроса FMKT это выглядит следующим образом:
FMKT( CAL_CSI2_VC_IRQENABLE_FE_IRQ_0, ENABLE)
Затем в цикле обрабатывать смотреть за нужным битом в регистре статуса:
const uint32_t csi2_frame_status_0_cala_addr =
g_calaBaseAddr + CAL_CSI2_VC_IRQSTATUS(g_csi2Ctx);
if (FMKT(CAL_CSI2_VC_IRQSTATUS_FE_IRQ_0, TRUE) == (CAL_CSI2_VC_IRQSTATUS_FE_IRQ_0_MASK & HW_RD_REG32(csi2_frame_status_0_cala_addr) )
{
//! меняем адрес wr_dma
//! сбрасываем статус FE, записывая в него 0x1
}
//! ждём, пока не сбросится статус
7.2.6.3.12.4.2 Write DMA Line Start Address
The line start address is set to the base address when the base address is updated (that is, LINE_NUMBER = 0 at frame start). Otherwise, the line start address is updated upon reception of the
PIX_DAT_LS tag depending on the CAL_WR_DMA_OFST_k[23:22] CIRC_MODE register bit-field and CAL_WR_DMA_CTRL_k[4:3] WR_PATTERN bit-field. Table 7-487 summarizes how the line starts address (LINE_START) and line numbers are updated on every PIX_DAT_LS tag.
NOTE: CAL_WR_DMA_CTRL_k[2:0] MODE must be set to 0x0 (disabled) or 0x4 (use
CAL_WR_DMA_ADDR_k as base address), when CAL_WR_DMA_OFST_k[23:22]
CIRC_MODE !=0.
7.2.6.3.12.4.3 Write DMA Data Address
Data received together with the ATT_HDR_S, ATT_DAT_S, CTRL_HDR_S, PIX_HDR_S, PIX_DAT_FS or PIX_DAT_LS tag is stored at the line start address (refer to section Line Start Address). For all other tags (ATT_HDR_E, ATT_DAT, ATT_DAT_E, PIX_HDR_E, CTRL_HDR_E, PIX_DAT, PIX_DAT_FE or PIX_DAT_LE), data is appended (that is, ADDR+ = 8, for each word of 64-bits). Figure 7-55 illustrates how data is stored in memory when CAL_WR_DMA_OFST_k[23:22] CIRC_MODE = 0 (disabled) and CAL_WR_DMA_CTRL_k[4:3] WR_PATTERN = 0 (linear).
The write DMA channel with the lowest ID has the highest priority when multiple channels are ready to
send data simultaneously. Software can use CAL_WR_DMA_XSIZE_k[31:19] XSIZE = 0 in case the stream size is not known or exceeds the maximum range of the XSIZE bitfield. CAL skips the cropping feature in that case and sends all data to memory. However, software must still ensure that enough memory space has been allocated.
7.2.6.3.12.5 CAL Write DMA OCP Transaction Generation
The write DMA generates OCP write bursts of 1~8 x 16 bytes. A burst never crosses a 128 byte
boundary. The maximum burst size is defined by the CAL_CTRL[6:5] BURSTSIZE register bit-field. The first and the last burst of a contiguous data block may use smaller burst sizes than defined in the
BURSTSIZE bit-field. Bursts in the middle of the data block must use exactly the size defined in the
BURSTSIZE bit-field.
7.2.6.3.12.6 CAL Write DMA Real Time Traffic
Traffic for which the pixel rate is imposed by the camera is qualified as hard real time traffic. Example of such hard real time traffic is data received from the camera (through PPI), optionally processed in the CAL and then sent to SDRAM using the OCPO port. Hard real time traffic cannot be stalled for long periods of time. Indeed, the camera sends data at constant speed and it can only be stalled until FIFOs on the path are filled up. When FIFOs become full, data is discarded and the frame is therefore corrupted. To minimize the risk of real time data corruption, the device supports a mechanism that is activated by the MFlag generated by real time initiators. MFlag generation must be disabled (through CAL_CTRL[20:13] MFLAGL = 0xFF and CAL_CTRL[31:24] MFLAGH = 0xFF), when CAL does not generate any real time traffic.
Static assertion of MFlag is only supported for debug purposes and must not be enabled for normal
utilization (CAL_CTRL[20:13] MFLAGL = 0x00 -> MFlag=0x11; CAL_CTRL[20:13] MFLAGL = 0xFF and CAL_CTRL[30:24] MFLAGH = 0x00 -> MFlag=0x01).
Dynamic MFlag generation is to be used when the write DMA operates on real time data. In that case, the MFlag value depends on the number of slots (n) ready to generate transactions in the write DMA:
• MFlag = 00: SAFE (n < CAL_CTRL[20:13] MFLAGL)
• MFlag = 01: VULNERABLE (CAL_CTRL[20:13] MFLAGL <= n < CAL_CTRL[31:24] MFLAGH)
• MFlag = 11: ENDANGERED (CAL_CTRL[30:24] MFLAGH <= n)
Software must ensure that:
• CAL_CTRL[20:13] MFLAGL <= CAL_CTRL[30:24] MFLAGH (only 0x00 or 0x11 generated, when MFLAGL = MFLAGH)
• CAL_CTRL[20:13] MFLAGL = 0x00, 0xFF or less or
equal to 2^(CAL_HL_HWINFO[3:0] WFIFO - 3)
• CAL_CTRL[30:24] MFLAGH = 0x00, 0xFF or less or
equal to 2^(CAL_HL_HWINFO[3:0] WFIFO - 3)
7.2.6.3.13 CAL Read DMA
NOTE: CAL_B is intented as a read port and to feed the image pipe.
7.2.6.3.13.1 CAL Read DMA Overview
The read DMA is used to read pixel data from SDRAM and send it thought the CAL_B processing
pipeline. Table 7-488 summarizes the mode combinations supported (возможные схемы настройки буфера FIFO в SDRAM'е: циклический и линейный плюс разные режимы укладки байтов картинки):
Пиксельные данные в sdram должны определенном образом отформатированы (в памяти оказывается битовое представление фильтра Байера - формата, в котором данные считываются с cmos-матрицы).
The read DMA fetches one to two streams simultaneously, depending on the chosen mode. Circular
addressing and line skip patterns for both streams use the same algorithm than the write DMA (see
Section 7.2.6.3.12)
Reading of initialization data is optional and should be enabled before the read DMA is started by setting the CAL_RD_DMA_CTRL[1] INIT bit. The read DMA is enabled by setting the CAL_RD_DMA_CTRL[0] GO bit. (рус.: Запуск чтения из sdram запускается через битовое поле GO регистра CAL_RD_DMA_CTRL.) It sends the amount of data defined by configuration through the processing pipeline, triggers an IRQ_RDMA_END event and then returns into idle state until it is enabled again by SW.
7.2.6.3.13.2 CAL Read DMA Data Provided to Processing Pipeline
The read DMA generates adequate TAGs for proper control of the processing pipeline. It always uses the CPORT ID #0. Table 7-489 shows how data is sent through the CAL processing pipeline after it has been read from memory.
7.2.6.3.13.3 CAL Read DMA Skipping Modes
Cal supports 2 line skipping read patterns. Those are mainly intended to provide vertically sub-sampled
images. SW shall adjust the SDRAM start address to select the correct sub-sampled phase (i.e. +0 and +2 lines in RD2SKIP2 mode; +0, +2 and +4 lines in RD2SKIP4 mode). CAL_RD_DMA_YSIZE indicates the number of lines to read from SDRAM. It does therefore not include skipped lines.
Настройка CALA, CSI2LL, CALB.
CAL-A.
2. Включим клоки на подсистеме CAL-A модуля ISS (описано в 7.1.2.4 ISS Clocks).
2.1.1. После включения клок доменов на шаге 1 конфигурационный регистр ISS_CLKSTAT, используемый только для чтения, имеет следующие значения:
1) ISS_CLKSTAT = 0x3FFF0000:
- LVDSRX_OUT3_PCLK = 0x1
- LVDSRX_OUT2_PCLK = 0x1
- LVDSRX_OUT1_PCLK = 0x1
- LVDSRX_OUT0_PCLK = 0x1
- GLBCE_OUT_PCLK = 0x1
- NSF3V_OUT_PCLK = 0x1
- BYS_B_OUT_PCLK = 0x1
- BYS_A_OUT_PCLK = 0x1
- PARALLEL_A_PCLK = 0x1
- CAL_B_OUT_PCLK = 0x1
- CAL_B_BYS_OUT_PCLK = 0x1
- CAL_A_OUT_PCLK = 0x1
- CAL_A_BYS_OUT_PCLK = 0x1
- CCP2_PCLK = 0x1
- CTSET = 0x0
- LVDSRX = 0x0
- ICM_A = 0x0
- ICM_B = 0x0
- CAL_B = 0x0
- CAL_A = 0x0
- BYS_B = 0x0
- BYS_A = 0x0
- CCP2 = 0x0
- ISP = 0x0
- SIMCOP = 0x0
2) Регистр ISS_PM_STATUS, который показывает наличие питания у модулей ISS_PM_STATUS = 0x00000000:
- CTSET = 0x0
- ICM_A = 0x0
- ICM_B = 0x0
- CAL_B = 0x0
- CAL_A = 0x0
- CBUFF_PM = 0x0
- BTE_PM = 0x0
- SIMCOP_PM = 0x0
- ISP_PM = 0x0
- CCP2_PM = 0x0
В этот момент недоступны регистры группы CAL_A, ISS_CTSET, LVDSRX, CAMERARX_CORE_0 и ISP6P5_SYS1.
2.1.2. Включим модуль CAL_A, установив единицу (0x1: Request enable of the sub-module. No effect if the sub-module clock is already on) в бит 9 (CAL_A) регистра ISS_CLKCTRL.
Будем использовать константы из хедера проекта vision sdk, подключим следующий файл C:\ti_830\PROCESSOR_SDK_VISION_03_06_00_00\ti_components\drivers\pdk_01_10_02_07\packages\ti\csl\soc\tda3xx\hw_iss_cm_core_aon.h для констант со сдвигами и файл C:\ti_830\PROCESSOR_SDK_VISION_03_06_00_00\ti_components\drivers\pdk_01_10_02_07\packages\ti\csl\cslr_iss.h (он включает файл с определениями ti/csl/src/ip/iss/V0/hw_iss_regs.h).
сonst uint32_t iss_clkctrl_addr = SOC_ISS_REGS_BASE + ISS_CLKCTRL;
const uint32_t iss_clkstat_addr = SOC_ISS_REGS_BASE + ISS_CLKSTAT;
HW_WR_REG32( iss_clkctrl_addr, FMKT( ISS_CLKCTRL_CAL_A, ON));
while( FMKT( ISS_CLKSTAT_CAL_A, OFF) == (ISS_CLKSTAT_CAL_A_MASK & HW_RD_REG32(iss_clkstat_addr)));
После этого стали доступны регистры групп CAL_A, CAMERARX_CORE_0 для настройки CSI2-PHY.
2.1.3. Регистр ISS_CLKSTAT = 0x00200200:
- LVDSRX_OUT3_PCLK = 0x0
- LVDSRX_OUT2_PCLK = 0x0
- LVDSRX_OUT1_PCLK = 0x0
- LVDSRX_OUT0_PCLK = 0x0
- GLBCE_OUT_PCLK = 0x0
- NSF3V_OUT_PCLK = 0x0
- BYS_B_OUT_PCLK = 0x0
- BYS_A_OUT_PCLK = 0x0
- PARALLEL_A_PCLK = 0x1
- CAL_B_OUT_PCLK = 0x0
- CAL_B_BYS_OUT_PCLK = 0x0
- CAL_A_OUT_PCLK = 0x0
- CAL_A_BYS_OUT_PCLK = 0x0
- CCP2_PCLK = 0x0
- CTSET = 0x0
- LVDSRX = 0x0
- ICM_A = 0x0
- ICM_B = 0x0
- CAL_B = 0x0
- CAL_A = 0x1
- BYS_B = 0x0
- BYS_A = 0x0
- CCP2 = 0x0
- ISP = 0x0
- SIMCOP = 0x0
2.1.4. ISS_PM_STATUS = 0x00080000
- CTSET = 0x0
- ICM_A = 0x0
- ICM_B = 0x0
- CAL_B = 0x0
- CAL_A = 0x3 (0x2: Functional)
- CBUFF_PM = 0x0
- BTE_PM = 0x0
- SIMCOP_PM = 0x0
- ISP_PM = 0x0
- CCP2_PM = 0x0
2.2. К csi2 dphy подключен сенсор sony imx296, через i2cp-интерфейс мы его настроила, теперь настроим CAL-A (подсистему WR-DMA) для чтения пиксельных данных из интерфейса.
CAL-A example.
Для инициализации получения данных с матрицы imx297 попробуем запустить пример, входящий в vision sdk (C:\ti_830\PROCESSOR_SDK_VISION_03_06_00_00\ti_components\drivers\pdk_01_10_02_07\packages\ti\drv\vps\examples\iss\isscapt_baremetal_app).
Для хождения в отладке по используемым либам библиотеки, её надо пересобрать со статическими отладочными библиотеками. Как это сделать, описано тут.
Используемые в проекте библиотеки:
CAL-B.
3. Включим модуль CAL-B и попытаемся считать (RD-DMA) из порта OCPO простые пиксельные данные (7.2.6.3.13.2 CAL Read DMA Data Provided to Processing Pipeline). Для начала нам надо включить CAL-B, потом сформировать запрос к порту OCPO (7.2.6.3.13.5 CAL OCP Request Generation).
3.1. Включаем модуль CAL-B так же как и CAL-A, только взяв соседние дефайны:
- вместо ISS_CLKCTRL_CAL_A берем ISS_CLKCTRL_CAL_B
- вместо ISS_CLKSTAT_CAL_A_MASK берем ISS_CLKSTAT_CAL_B_MASK
сonst uint32_t iss_clkctrl_addr = SOC_ISS_REGS_BASE + ISS_CLKCTRL;
const uint32_t iss_clkstat_addr = SOC_ISS_REGS_BASE + ISS_CLKSTAT;
HW_WR_REG32( iss_clkctrl_addr, FMKT( ISS_CLKCTRL_CAL_B, ON));
while( FMKT( ISS_CLKSTAT_CAL_B, OFF) == (ISS_CLKSTAT_CAL_B_MASK & HW_RD_REG32(iss_clkstat_addr)));
В результате получим включенным модуль CAL_B, выключенными CAL-A и CAMERARX_CORE_0, так как CAL_B только memory2memory-передач (targeted as
read DMA engine).
3.2. Попробуем запустить RD-DMA-передачу из OCPO-порта
Фильтр Байера, массив цветных фильтров:
6) Interfacing a CMOS Sensor to the TMS320DM642 Using Raw Capture Mode https://www.ti.com/lit/an/spraa52a/spraa52a.pdf
CAL-B example.
Попробуем запустим пример iss loopback из vision sdk для tda3x
(C:\ti_830\PROCESSOR_SDK_VISION_03_06_00_00\ti_components\drivers\pdk_01_10_02_07\packages\ti\drv\vps\examples\loopback_baremetal_app):
Интересны следующие файлы из vision sdk:
1) C:\ti_830\PROCESSOR_SDK_VISION_03_06_00_00\ti_components\drivers\pdk_01_10_02_07\packages\ti\drv\vps\src\vpslib\isscore\vpscore_calm2m.h
2) C:\ti_830\PROCESSOR_SDK_VISION_03_06_00_00\ti_components\drivers\pdk_01_10_02_07\packages\ti\drv\vps\src\vpslib\isscore\src\vpscore_calm2m.c
3) C:\ti_830\PROCESSOR_SDK_VISION_03_06_00_00\ti_components\drivers\pdk_01_10_02_07\packages\ti\drv\vps\src\vpslib\hal\vpshal_isscal.h
4) C:\ti_830\PROCESSOR_SDK_VISION_03_06_00_00\ti_components\drivers\pdk_01_10_02_07\packages\ti\drv\vps\src\vpslib\hal\src\vpshal_isscal.c
5) C:\ti_830\PROCESSOR_SDK_VISION_03_06_00_00\ti_components\drivers\pdk_01_10_02_07\packages\ti\drv\vps\src\vpslib\isscore\src\vpscore_ispapi.c
6) C:\ti_830\PROCESSOR_SDK_VISION_03_06_00_00\ti_components\drivers\pdk_01_10_02_07\packages\ti\drv\vps\include\fvid2\fvid2_dataTypes.h
raw10 cmos camera format
links:
ti forum (csi2 without cmos):
1) Linux/AM5718: AM5718 custom board interfacing with camera sensor
ISS ISP
CSI-2 PHY.
(?)4. Настроим CSI-2 PHY через регистр CTRL_CORE_CAMERRX_CONTROL (0x4a002e08), находящийся в ip-блоке Control Module.
4.1. До включения (пройден GEL, начало функции main ядра ipu0 arm cortex-m4) регистр CTRL_CORE_CAMERRX_CONTROL, которого нет во вкладке Registers (должен быть в группе CTRL_MODULE_CORE), доступен через вкладку Expressions следующим образом (*0x4a002e08).
1) CTRL_CORE_CAMERRX_CONTROL = 0x00C01806:
почему-то стоят биты из reserved зоны (00000000110000000001100000000110b)
- бит 8 CSIPORTA_MODE = 0x0 ()
- биты 7:3 CSIPORTA_LANEENABLE = 0x0 (0x0: Lane module disabled)
- биты 2:1 CSIPORTA_CAMMODE = 0x3 (0x3: GPI mode)
- бит 0 CSIPORTA_CTRLCLKEN = 0x0 (0x0: Disable for CTRLCLK)
qsenimx296 doc:
exposure_time [nsec] = exposure_register[31:0] * 18.5185nsec
время экспозиции (наносекунды) = 10000 (0x2710) * 18.5185 наносекунд = 185185 наносекунд = 0.185185 миллисекунд
retrigger_time [nsec] = exposure_register[31:0] * 18.5185nsec
retrigger_time [nsec] = exposure_register[31:0] * 18.5185nsec
время retrigger (наносекунды) = 883008 (0xD7940) * 18.5185 наносекунд = 16351983,648 наносекунд = 16,351983648 миллисекунд
Open Core Protocol (OCP):
3) brief
lvds overview:
3) Differential Signaling 4 of 4 (LVDS) https://www.youtube.com/watch?v=CkpkDSgI3e0
4) LVDS Overview https://www.youtube.com/watch?v=U6eGpJBWtbU
5) LVDS Use Cases https://www.youtube.com/watch?v=fjXHivsmT_A
lvds diy:
1) Переходник LVDS на TTL плоский шлейф FFC 50Pin https://www.youtube.com/watch?v=HFP0dRlRDQM
2) Как правильно выбрать кабель LVDS для матрицы. https://www.youtube.com/watch?v=vBIsWQ2wbr8
3) Переделка кабеля LVDS. Теория https://www.youtube.com/watch?v=v3A3jZi3aXY
4) HDMI-LVDS. От макета к релизу https://habr.com/ru/post/370073/
5) Монитор из хлама / универсальный скалер LVDS MT6820 https://www.youtube.com/watch?v=Ag6YXdyJ_OU
csi-2 + fpga:
1) SP701 + PCAM-5C + 15 Минут+ VITIS = Easy MIPI на FPGA https://habr.com/ru/post/476620/
2) MIPI CSI-2 Transmitter Subsystem v2.1 Product Guide
https://www.xilinx.com/support/documentation/ip_documentation/mipi_csi2_tx_subsystem/v2_1/pg260-mipi-csi2-tx.pdf
csi + raspberry pi:
1) Обзор 98 одноплатных компьютеров. Часть 1 https://habr.com/ru/post/405023/
2) Трансляция видео с Raspberry Pi по 3G тремя способами https://habr.com/ru/post/258377/
3) Запускаем камеру от телефона, или что делать, когда ничего не получается?
https://habr.com/ru/post/509142/
csi-2 in ti and nxp solutions (datasheets):
1) https://www.st.com/resource/en/datasheet/stmipid02.pdf
2) MIPI–CSI2 Peripheral on i.MX6 MPUs https://www.nxp.com/docs/en/application-note/AN5305.pdf
2) MIPI CSI-2 Transmitter Subsystem v2.1 Product Guide
https://www.xilinx.com/support/documentation/ip_documentation/mipi_csi2_tx_subsystem/v2_1/pg260-mipi-csi2-tx.pdf
csi + raspberry pi:
1) Обзор 98 одноплатных компьютеров. Часть 1 https://habr.com/ru/post/405023/
2) Трансляция видео с Raspberry Pi по 3G тремя способами https://habr.com/ru/post/258377/
3) Запускаем камеру от телефона, или что делать, когда ничего не получается?
https://habr.com/ru/post/509142/
csi-2 in ti and nxp solutions (datasheets):
1) https://www.st.com/resource/en/datasheet/stmipid02.pdf
2) MIPI–CSI2 Peripheral on i.MX6 MPUs https://www.nxp.com/docs/en/application-note/AN5305.pdf
csi2 phy, CAL in linux:
Chroma noise filter, mesh based lens distortion and perspective correction, temporal video noise filter:
1) Undistorting Foreground Objects in Wide Angle Images
2) Fisheye Video Correction
3) Distortion-Free Wide-Angle Portraits on Camera Phones https://people.csail.mit.edu/yichangshih/wide_angle_portrait/shih_sig19_lowres.pdf
4) Blind Geometric Distortion Correction on Images Through Deep Learning
5) Nonlinear Lens Distortion
6) Video Noise Reduction Method Using Adaptive Spatial-Temporal Filtering
7) Noise reduction https://en.wikipedia.org/wiki/Noise_reduction
8) Video denoising https://en.wikipedia.org/wiki/Video_denoising
sony cmos imx296 config interfaces:
1) VC MIPI Camera Module Hardware Operating Manual (VC MIPI IMX296) https://www.vision-components.com/fileadmin/external/documentation/hardware/VC_MIPI_Camera_Module/index.html
2) (linux driver, demo code 4 rpi) https://www.vision-components.com/fileadmin/external/documentation/hardware/VC_MIPI_Raspberry_PI/index.html
sony cmos imx:
1) the driver source code of the Raspberry Pi camera module https://www.raspberrypi.org/forums/viewtopic.php?t=154915#p1012766
2) sony imx219 linux driver https://github.com/raspberrypi/linux/blob/rpi-4.19.y/drivers/media/i2c/imx219.c
3) sony imx219 datasheet
4) Sony CMOS Sensor: SonyIMX179 https://www.raspberrypi.org/forums/viewtopic.php?t=72863
i2c reading:
1) Difference I2C Sensor Reading Raspberry Pi and Arduino
2) WHAT COULD GO WRONG? I2C EDITION https://hackaday.com/2016/07/19/what-could-go-wrong-i2c-edition/
3) i2c wiki
ti i2c serializer:
CAL-A:
Сжатие динамического диапазона:
2) Просто о звуке: Обсуждаем сжатие динамического диапазона [Перевод] https://www.audiomania.ru/content/art-4182.html
Комментариев нет:
Отправить комментарий