This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA2PXEVM: Inquiry on supporting RGB/YUV444/YUV422 dataflow from CSI-2 PHY to Vision SDK

Part Number: TDA2PXEVM

Hello,

We are planning to use HDMI IN as source of video frame but the data path is as follows:

HDMI IN --> SerDes --> TDA2px CSI-2 DPHY


From the SW links architecture description, [ISS Capture]  expects RAW RGB bayer format from sensor then passes it to [ISS M2M ISP] to convert it into YUV frame which can then be passed to subsequent links in the Vision SDK pipeline.

Since the HDMI IN data format are RGB/YUV422/YUV444 can the data path from [ISS Capture] be modified such that the output is already YUV and M2M ISP no longer needs to perform the conversion pipeline?

Unfortunately, we are still in discussion phase and have yet to perform trial with code revision for this topic.
But from my understanding, we can create a ISP sensor module and use the following datapath:

VPS_ISS_IPIPE_DATA_PATH_YUV422_YUV422 = 0x3

Hoping to get some insights if this idea is feasible in the current TDA2px and Vision SDK framework.

  • Hi Norman,

    Since capture is already in YUV format, there is no need to use ISP link. You could just directly connect capture link to your next processing link..

    Rgds,

    Brijesh

  • Hello Brijesh,

    Thank you for this information and confirmation.
    From a rough imagination of the necessary support, we can create a mock sensor module for capture link, then provide NULL ISP configuration, and  completely remove the [M2M ISP] link.

    Is this correct?

  • Hi Normal,

    I could not get, what is null isp configuration? 

    we just need to create iss capture link, provide correct csi2 parameters. Since there is no isp, there is no isp configuration. 

    sensor could be configured from usecase itself. or we could use sensor framework.

    Rgds,

    Brijesh

  • My idea is to use sensor framework so that integration with Capture link (consequently with usecase) is as straightforward as the current sensor support.
    Thus since there is no actual sensor and ISP will not be used, the following structure params:

    struct IssSensorIf_Params_t {
        char                            name[ISS_SENSORS_MAX_NAME];
        /**< Name of the sensor, using which it is registered to this framework */
    
        IssSensor_Info                  info;
        /**< Sensor information, which does not change */
    
        UInt32                          dccId;
        /**< DCC Id of the sensor,
             typically sensor driver provides dcc id, but if sensor driver
             is not opened and it is required to flash dcc profile in qspi,
             this id will be used.
             Note: it should be same as the id in the driver */
    
        IssSensorIf_Start               start;
        IssSensorIf_Stop                stop;
        IssSensorIf_GetExpParams        getExpParams;
        IssSensorIf_SetAeParams         setAeParams;
        IssSensorIf_GetDccParams        getDccParams;
        IssSensor_InitAewbConfig        initAewbConfig;
        IssSensor_GetIspConfig          getIspConfig;
        IssSensor_ReadWriteRegister     readWriteReg;
    };
    

    will have NULL values for the getIspConfig (and others I presume).

  • Anyway, the inquiry has been clearly answered.

    Thank you very much for the support Brijesh.
    I think we can close this thread.