DRA829V: J721E: CSI_RX_IF DMA/PSILSS Support

Team, can we get a feedback on this please.

Hi Ahsan,

Could you please use OpenVX Capture Node interface? The configuration for these registers would be taken care by the driver internally.

Regards,

Brijesh

Brijesh,

I do not understand; can you please elaborate

Ahsan,

Please use either OpenVX node or PDK driver. SW takes care of configuring these modules internally.

Rgds,

Brijesh

Brijesh,

a) Point taken for CSI_RX_IF_SHIM_PSI_CFG0 and CSI_RX_IF_SHIM_PSI_CFG1 registers; I see that pdk driver is hardcoding these values (PSI source and destination tags, ps flags and PSI packet type) in pdk/packages/ti/drv/csirx/src/csirx_drvUdma.c to 0 or 1 and writing to shim register in csirx_drv.c. Would these values work with any configuration? e.g. we're going to input YUV422 8 bit on CSI_RX0 and RGB888 on CSI_RX1.

b) We're going to have to translate the PDK driver to PSDKLA for our use case; therefore can you please have original question no. 1 and 2 answered by a Linux engineer because K3 UDMA driver on Linux supports PSILSS. Let me know if I should open a separate thread for it.

Hello Ahsan,

Sorry for the late reply.

Please find answers to your questions below.

1, yes, you could same values for tags, flags and psi packet type, they need not be changed because of data type. In fact, we have used same PDK driver to capture YUV422 and RGB formats. So it should work.

2, we are working on providing CSIRX driver on PSDKLA by SDK7.3 release. This will support single channel capture on Linux. So can you please wait for sometime? 

Please find below answers to your first questions,

1, we are using TR mode for the CSIRX module, we have not really tested packet mode. but it should work, not reason for it not to work.

2, scatter-gather mechanism should work, but we have not really test it, and as of now, no plan to test this feature.

3, As i mentioned, we have raised this issue and will be included in the documentation.

Regards,

Brijesh

Hi Brijesh,

Thanks for the update. We're time-bound for the current project but will be looking forward to any relevant updates in the docs as well as the PSDKLA release if those arrive in time. Do you have an ETA for 7.3 release?

As for the DMA channel configuration we'll go ahead and try both the packet mode and TR mode with scatter-gather. From the routine names I can tell that K3 UDMA driver uses type1 TR in DEV_TO_MEM scatter-gather implementation, and the RTOS uses type15 TR for CSIRX capture channel. The problem is there's no consolidated information for TR mode transfers (if any at all) in the TRM, including whether these are inter-compatible and if there are any pros or cons of using one type over the other. Could you please raise this issue internally as well.

There's potentially another misinformation in the TRM where CSI_RX_IF_SHIM_DMACNTX register detail mentions "Configuration for each of 32 possible channel contexts..." but provides only one corresponding register in the register definitions; this is unlike CSI_TX_IF_DMACNTX_j with formula for 32 register offsets. SHIM reg map in RTOS also repeats this mistake by defining 32 instances for DMACNTX MMRs

typedef struct {
    volatile uint32_t CSIRX_ID;
    volatile uint8_t  Resv_8[4];
    volatile uint32_t VP0;                       /* Video Port 0 config */
    volatile uint32_t VP1;                       /* Video Port 1 config */
    volatile uint32_t CNTL;                      /* control register for csi rx wrapper */
    volatile uint8_t  Resv_32[12];
    CSL_csi_rx_ifRegs_cntx_cntl CNTX_CNTL[32];
} CSL_csi_rx_ifRegs;

which I think is mitigated by that fact that the max capture channels are hardcoded to 1 in the application. With the following register address given in the TRM I don't think that DMACNTX MMR can support more than one instance of capture channel

CSI_RX_IF_SHIM_DMACNTX 0451 0020h
CSI_RX_IF_SHIM_PSI_CFG0 0451 0024h

So probably another thing to get corrected in the TRM.

Hello Brijesh,

I configured packet mode for the dma channel. My device tree configuration looks like this:

    media_controller0: ti-media-controller@0 {
...
        ti,psil-base = <0x4940>;
   
        csi = <&csi_rx_if0>;
        dmas = <&main_udmap &media_controller0 0 UDMA_DIR_RX>;
        dma-names = "rx_capture_chan0";

        ti,psil-config0 {
            linux,udma-mode = <UDMA_PKT_MODE>;
            ti,channel-tpl = <2>;
            ti,psd-size = <64>;
            ti,needs-epib;
            ti,notdpkt;
        };
    };

When I try to acquire the channel using dma_request_slave_channel() the firmware request tisci_psil_ops->pair fails with the following error from k3 UDMA driver:

[   31.349056] ti-udma 31150000.udmap: PSI-L pairing failed: 0x4940 -> 0x9000
[   31.356222] ti-udma 31150000.udmap: get channel fail in udma_of_xlate.

Do I need to assign resources to A72 core under imggen utility and rebuild ti-sci-fw for this op to succeed? Can you please point out what changes would I require here.

Hello team,

Is there an update on this?