SPRUIE9D May 2017 – May 2024 DRA74P , DRA75P , DRA76P , DRA77P
Table 9-63 summarizes which CAL registers are shadowed.
Register | Shadowed | Trigger | Additional Information |
---|---|---|---|
CAL_HL_REVISION | No | N/A | |
CAL_HL_HWINFO | No | N/A | |
CAL_HL_SYSCONFIG | No | N/A | |
CAL_HL_IRQ_EOI | No | N/A | |
CAL_HL_IRQSTATUS_RAW_j | No | N/A | |
CAL_HL_IRQSTATUS_j | No | N/A | |
CAL_HL_IRQENABLE_SET_j | No | N/A | |
CAL_HL_IRQENABLE_CLR_j | No | N/A | |
CAL_PIX_PROC_i[0] EN | Yes | FS @ pixel processing input | Format received on C-Port may change (for example between viewfinder and full frame). However, utilization of separate CPORTs is preferred (if camera sensor permits). |
CAL_PIX_PROC_i other bits | No | N/A | Use separate contexts and EN bits, if pixel processing for a given CPORT must be changed on a frame by frame basis |
CAL_CTRL | No | N/A | Typically not changed while there is active traffic |
CAL_LINE_NUMBER_EVT | No | N/A | |
CAL_VPORT_CTRL1 | Yes | FS @ video port input | Blanking / PCLK settings may need to be changed on each frame; for example when binning / digital zoom settings change. |
CAL_VPORT_CTRL2[] FSRESET bit | No | N/A | Control bit for debug only |
CAL_VPORT_CTRL2 other bits | Yes | FS @ video port input | Pixel rate and source CPORT may need to change on the fly (that is, switch between camera modes that use separate CPORTs) |
CAL_BYS_CTRL1[31] BYSINEN | Yes | FS @ BYS input port | |
CAL_BYS_CTRL1[30:25] YBLK | Yes | FS @ BYS output port | |
CAL_BYS_CTRL1[24:17] XBLK | Yes | FS @ BYS output port | |
CAL_BYS_CTRL1[16:0] PCLK | Yes | FS @ BYS output port | |
CAL_BYS_CTRL2[10] DUPLICATEDATA | Yes | FS @ BYS output port | |
CAL_BYS_CTRL2[9:5] CPORTOUT | Yes | FS @ BYS output port | |
CAL_BYS_CTRL2[4:0] CPORTIN | Yes | FS @ BYS input port | |
CAL_RD_DMA_CTRL | No | N/A | One-shot-operation only |
CAL_RD_DMA_PIX_ADDR | No | N/A | One-shot-operation only |
CAL_RD_DMA_PIX_OFST | No | N/A | One-shot-operation only |
CAL_RD_DMA_XSIZE | No | N/A | One-shot-operation only |
CAL_RD_DMA_YSIZE | No | N/A | One-shot-operation only |
CAL_RD_DMA_INIT_ADDR | No | N/A | One-shot-operation only |
CAL_RD_DMA_INIT_OFST | No | N/A | One-shot-operation only |
CAL_WR_DMA_CTRL_k[1:0] MODE | Yes | FS @ CPORT = CAL_WR_DMA_CTRL_k[13:9] CPORT | Resolution may change for a given CPORT. That is not preferred but some sensors may require this mode. |
CAL_WR_DMA_CTRL_k other bits | No | N/A | Use separate contexts and MODE bits, if size changes for a given CPORT. |
CAL_WR_DMA_ADDR_k | Yes | FS @ CPORT = CAL_WR_DMA_CTRL_k[13:9] CPORT | Output is typically double buffered so that CAL writes one buffer when the other buffer is read. |
Registers that are not shadowed are busy writable. Changes are immediately taken into account and may cause failure, if they are done while the hardware is using the register (that is, outside of the blanking periods).
For all shadowed registers, except CAL_WR_DMA_ADDR_k, the content of the shadowed register is copied into the internal copy when the FS of the newly enabled stream is received by the corresponding engine. Said differently, new settings are taken into account just before they are needed. That maximizes time available to the software to change register settings. In particular, the first received FS copies initial settings into a shadow register.
The FS event is detected at the location in the pipeline where the setting applies. Said differently, the copy from shadow to working register does not occur exactly at the same time in all pipeline stages and there is no risk that the shadowing mechanism is activated too late or too early.
Figure 9-26 shows an example. Software writes configuration #A and then starts the processing step. The value from the configuration register is copied into the shadowed register that is used by hardware when the PIX_DAT_FS tag is received by relevant pipeline stage. Software may use an IRQ to detect the frame start and provide the settings for the next frame. The frame start interrupt is triggered by the low-level protocol. This happens up to 8 cycles before the PIX_DAT_FS tag reaches the processing stage. Therefore, software must ensure that there is a delay of at least 8 functional clock cycles from the FS_IRQ to the configuration update. In a real world case, this delay is ensured by the IRQ controller plus software latency. Software must first read the CAL_HL_IRQSTATUS_j registers to detect which event has triggered the IRQ before it can update configuration registers.
The CAL_WR_DMA_ADDR_k register has a specific shadowing to avoid that multibuffer management is on the critical software path. For more details, see Section 9.2.3.10.4, Write DMA OCP Address Generation.