Zynq synchronize transmission

[htibosch]

Zynq: wait for transmission-ready before sending a new packet

In his post Long delay between two splitted frames, Tam wrote that he sees many retransmissions when sending from a Zynq7000 to a local device.

I found that in the driver, after a packet is sent, a variable int txBusy is set and when sending a new packet, the variable is cleared again. The variable should be use to synchronise the two events: TX-start and TX-end.

Now when the system is fast, the GMAC gets overrun and setting the start-bit STARTTX in the register NWCTRL is ignored. As soon as any new packet is sent, the earlier one is flushed as well. This cause many annoying re-transmissions and timeouts on the remote side.

Solution:

SemaphoreHandle_t txMutex;

This mutex will be given to by the emacps_send_handler(). It is called from an ISR so it does;

    /* Take the mutex without blocking. */
    xSemaphoreGiveFromISR( xemacpsif->txMutex, &xHigherPriorityTaskWoken );

Tam, thank you for your valuable input, and your help while we were testing.

mentioned post in the FreeRTOS forum explains it all.

Checklist:

• I have tested my changes. No regression in existing tests.
• I have modified and/or added unit-tests to cover the code changes in this Pull Request.

Related Issue

There is no issue ID, the case was presented on the FreeRTOS forum.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[htibosch]

This patch has been tested by Tam, see here.
The test module now runs fine, but he did find a problem in another example. I'm looking at it now.

[htibosch]

@moninom1, thanks for approving, but we're not ready yet.
The patch works in one situation, not in another case.
I will report back here when the issue is solved,

[htibosch]

I continued testing the setup as described here.
My conclusion is that the Zynq network interface needs more protection against racing conditions. And also I suspect that the Python script was showing some weird characteristics.
In order to avoid confusions, I will create a new PR to solve this subject.

[htibosch]

I created a new PR 1286, which replaces this PR. It has the title "Zynq driver: avoid race conditions".

[htibosch]

Please refer to PR 1286 which will replace this PR.