CDD Driver Interface#

Determining the Origin of an Interrupt Signal#

The procedure to determine the originating sources of an interrupt signal (such as Interrupt Localization) is implemented in Deserializer and Camera Module drivers, in the GetInterruptStatus() API. They are called whenever SIPL receives an external interrupt signal , and every driver has an opportunity to execute an error localization routine to query the hardware status.

The default SIPL error configuration monitors two input GPIO pins per Camera Group, one of each for falling-edge and rising-edge triggered interrupts. Interrupt signals of the same type from hardware devices are combined externally (logical AND and OR for falling-edge and rising-edge triggered interrupts, respectively) within the deserializer or an independent logic circuit. Consequently, a combined interrupt signal at the Tegra SoC is the result of one or more simultaneous interrupt signal assertions, therefore all possible device sources must be individually absolved or have their error status read and cleared.

The are two types of GetInterruptStatus() implementations in the CNvMDeserializer and CNvMCameraModule drivers. Interrupt Localization for Device Block-scope and unitary devices are implemented in the former. This includes Deserializers and POC ICs, whereas those for devices in Camera Modules are in the latter (such as image sensors, PMICs, heaters, and EEPROMs).

When an interrupt arrives at SIPL, GetInterruptStatus() is called at each of the CNvMCameraModule instances, followed by the CNvMDeserializer instance. Each driver determines whether the interrupt GPIO is triggered by the same level transition as the devices they are responsible for, and then the driver proceeds with querying all possible originating devices to localize the sources and query their statuses.

The recommendation, where possible, is to perform a breadth-first traversal to probe devices. This optimization identifies links in error early and prevents delays in attempting to read from inaccessible hardware. For example, link status and remote error registers should be queried at the Deserializer and power confirmed at the POC, and then at the Camera Modules’ Serializers and PMICs, all prior to accessing image sensors located at the leaves of the topological path. If the communication pathway for a link is inaccessible, early termination of the interrupt localization routine should be done once the link is identified. In the event of a prolonged delay, bus failure, or hang in communicating with a device, SIPL provides a timeout mechanism that emits an error notification to the client upon reaching the configured execution duration.

Interrupt Notifications delivered to the client contain a NotificationType enum that broadly identifies the generic origin (DESERIALIZER, SERIALIZER and SENSOR), and implementation-specific intrCode and intrData attributes set by drivers to give specific identification and diagnosis information. The uLinkMask identifies specific links (or no specific links) for which the notification pertains to, and may be acted on immediately to repudiate inputs, activate link recovery, or request drivers to query detailed status information and diagnostics.

When an interrupt arrives at SIPL, a dedicated interrupt handler thread (per device block) sequentially calls theIInterruptStatus::GetInterruptStatus() interface at all active CNvMCameraModule driver instances and then the one for the CNvMDeserializer driver.

linux_image1

SIPL Interrupt Localization is not a true interrupt handler, and executions are not preemptable. Concurrent interrupt events queued are processed sequentially. The CamGPIO index is passed to the GetInterruptStatus() handler of the drivers, and the drivers may return immediately if the index is not being monitored or is not otherwise relevant.

The driver may perform I2C reads of status registers at devices to determine if they are in an error state and may contribute to the assertion of the muxed interrupt. If GetInterruptStatus() returns an error code, an internal fault is reported to the client as an error notification.

virtual SIPLStatus GetInterruptStatus(
    uint32_t const gpioIdx,
    std::array<InterruptNotification, MAX_DEVGRP_NTFNS_PER_INTR> &intrNtfns) const
{
    return NVSIPL_STATUS_NOT_SUPPORTED;
}

Interrupt Notifications#

Error notifications are returned in an array of IInterruptStatus::InterruptNotification structures, notwithstanding that the maximum capacity is unlikely to be reached, drivers should prioritize inclusion of notifications appropriately. Each InterruptNotification populates a singleNvSIPLPipelineNotifier::NotificationData message dispatched to the client.

The code field is mapped to a NvSIPLPipelineNotifier::NotificationType(see #lc9ytdp2e30n__section_ub2_nnz_yxb), and linkMask identifies links in Camera Group. The data (custom user-defined 64-bit payload) and gpioIdx are forwarded without side effects, and the valid flag must be set to true for populated notifications.

/**
 * @brief Interrupt Notification from hardware device drivers to be
 * delivered to the client.
 */
struct InterruptNotification {
    /** The interrupt code to send to the client in the notification. */
    InterruptCode code;
    /** Fixed-sized storage for custom driver-defined payload. */
    uint64_t data;
    /** The interrupt CDAC GPIO index. */
    uint32_t gpioIdx;
    /**
     * The one-hot link masks indicating which Camera Module link(s) this
     * notification describes.
     */
    uint32_t linkMask;
    /**
     * Whether this interrupt notification is valid (filled). Ignored if set
     * to false.
     */
    bool valid;
};

Interrupt Code to Notification Type Mappings#

The Interrupt Code code in interrupt notifications are mapped to a NvSIPLPipelineNotifier::NotificationType, even though it is included as an independent attribute in the NvSIPLPipelineNotifier::NotificationData message.

InterruptCode

NotificationType

Link Mask Set

INTR_STATUS_DES_*

NOTIF_ERROR_DESERIALIZER_FAILURE

No

INTR_STATUS_PWR_*

Yes

INTR_STATUS_SER_*

NOTIF_ERROR_SERIALIZER_FAILURE

Yes

INTR_STATUS_SEN_*

INTR_STATUS_PMIC_*

INTR_STATUS_EEPROM_*

NOTIF_ERROR_SENSOR_FAILURE

Yes

INTR_STATUS_LOCALIZATION_FAILURE

NOTIF_ERROR_INTR_LOCALIZATION_FAILURE

Yes

INTR_STATUS_TIMEOUT

NOTIF_ERROR_INTR_LOCALIZATION_TIMEOUT

Yes

INTR_STATUS_FAILURE

(All others codes)

NOTIF_ERROR_INTERNAL_FAILURE

Yes
On this page