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.

TDA4VH-Q1: Mailbox Communication Latency Test

Part Number: TDA4VH-Q1

Hi TI Expert,

Customer is working on SDK8.6. They have done the following 4 mailbox communication tests.

(1) r5 -> r5, the latency is 2.4us

(2) a72 -> r5, the latency is 0.9us

(3) r5 -> a72, the latency is 5ms

(4) a72 mailbox loop test, the latency is 5ms

Based on the test results, the test 3 & 4 is not normal, as our benchmark is provided in the below link section 1.1.2.6 .

https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/09_00_00_02/exports/docs/pdk_jacinto_09_00_00_45/docs/datasheet/jacinto/datasheet_j721e.html#ipc

The detailed setup of test 4 is described below.

The file used is: driver/mailbox/mailbox-test.c

Both of the Tx & Rx use FiFo_1 in mailbox0_cluster6 shown below.

After the driver/mailbox/omap-mailbox.c sends out the tx, customer used below coding to record the GTC_CNT.

Then in the rx interrupt, using the below code to record the GTC_CNT again, & print out the latency.

As we know the 5ms performance result is not normal, may I know what could be the reasons for this test case. Could you provide some suggestions please?

Thanks a lot!

Kevin

  • Hi Kevin,

    (3) r5 -> a72, the latency is 5ms

    (4) a72 mailbox loop test, the latency is 5ms

    I am not sure how or where these measurements are done, but these look totally bogus. The numbers are expected to be in microsecs, not milliseconds. We won't even be able to run any complex OpenVX graphs/usecases with 5 ms delay time.

    FWIW, __mbox_rx_interrupt is a true interrupt handler function, you shouldn't be adding a kernel trace in that function. Also, the tick_tx computation is done after the mailbox message is already written to the queue, which should immediately trigger an interrupt if using local queues. This write is typically outside of an interrupt context, so you will immediately get pre-empted.

    regards

    Suman

  • Hi Suman,

    Thanks for your suggestions, this problem is solved now.

    Kind Regards,

    Kevin