Camera SIPL Receive-Only Mode

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. The exceptions are that I2C writes are still performed in the deserializer driver at Init() and Deinit() to enable and disable replication mode on the deserializer hardware respectively, and to run CSI deskew in D-Phy mode only.

  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 DDPX. SIPL propagates error interrupt notifications to the client regardless of whether the receive-only mode flag is set in the platform configuration. The secondary mode client is typically unable to respond such errors, since 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 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.