Camera SIPL Receive-Only Mode#
Receive-Only Mode is an operation mode of the Camera SIPL library, on a secondary NVIDIA® Tegra host, to receive and process MIPI CSI frames without interacting with the camera module hardware. The client on the primary host perform control and operation of the camera module hardware. Frame capture settings should be configured identically on the secondary receive only client for compatibility.
Use case Examples#
Data Recording
Load balancing, such as running different networks on the same inputs concurrently
Allowing data to cross safety boundaries:
Primary ASIL safety host is the sole controller of camera hardware on a particular camera hardware block
Secondary host may be QM or a lower ASIL level, such as a back-up camera, data recorder, or infotainment
Receive-Only Mode Operation#
Receive-only mode is enabled by setting the isPassiveModeEnabled flag in the device block platform configuration. The customer application should ensure that the SIPL platform configuration on both SoCs are mirrored identically, or are otherwise compatible for capture, and then synchronize the initialization and start of the primary client before the secondary client.
APIs with I2C accesses and power control calls to deserializers and camera modules, such as sensors, serializers, and EEPROMs, are rendered NOP, and they return a success status immediately. Replication mode or the similar functionality in the deserializer have to be enabled by Primary Tegra. For additional information, refer to Primary/Secondary Capture.
The NVCSI pad on the receiving Tegra must be enabled when the deserializer drives CSI output to the lanes. Otherwise, permanent damage to the chip is possible. It is not possible to enable replication mode on the deserializer from the primary SoC before the secondary SoC client is initialized.
External camera hardware interrupts continue to be monitored and propagated to the secondary client as usual if physically connected and configured. These signals may be shared and jointly delivered with the primary client if it is also physically connected and configured.
External Camera Hardware#
Camera hardware device errors and interrupts may be propagated to both the primary and secondary SoCs. Error interrupt lines are connected to both SoCs on reference Tegra boards, such as the NVIDIA Thor Devkit. SIPL propagates error interrupt notifications to the client only if the receive-only mode flag is not set in the platform configuration. The secondary mode client is typically unable to respond such errors; it may be forbidden from performing I2C communication to retrieve the detailed error status and effect a link recovery procedure. This indication of hardware fault may be useful to arrest a capture pipeline for a mission-critical application on the secondary SoC in the event of latent source corruption.
The client system architecture implements the inter-Tegra error notification delivery and handling strategy, which coordinates the responses, possibly synchronized, of the independent clients.
Tegra Capture and Processing#
Capture and processing errors originating from the secondary SoC are propagated to the client through SIPL and other mechanisms, such as 3LSS, as usual and without change.
Link Recovery#
The procedure to perform link recovery in response to error notifications can occur on the primary SoC client, but this will usually interfere with the secondary SoC capture.
Link recovery is currently not supported on the secondary SoC client. A re-launch of the non-safety receive-only mode SIPL client may be necessary to achieve restoration of service.
DriveOS 7.0.1.0 (T264) |
|
|---|---|
Linux (non-safety) |
Yes |
The SIPL library contains a basic callback-based camera module link error notification and recovery system. Each deserializer on the Camera Interface Module (CIM) has an error GPIO pin to indicate the appearance of an error in its links. An error monitor thread for each device block dumps the deserializer error status registers, automatically clears the error GPIO, and notifies the client via its pre-registered callback of a NOTIF_ERROR_DESER_LINK_FAILUREevent.
A mask indicating which of the camera modules is in error is communicated to the client, and the deserializer error status registers contain more information about the specific error conditions.
Camera module error recovery is not automatic and triggered by the client. Recovery occurs at the link granularity. Individual camera modules and their links are independently disabled at the deserializer and each subdevice is re-initialized, as shown in the following diagram.
The camera pipeline, NVCSI/VI/ISP, is not reset by SIPL. The client coordinates frame error handling and resubmission of capture and process requests during recovery.
