Hi Jassi, Thank you very much for your feedback.
On Sun, 2021-02-14 at 22:54 -0600, Jassi Brar wrote: > IIUIC, maybe the solution is simpler .... What if we set txdone_poll. > Always return success in send_data(). And check if we overflew the > fifo in last_tx_done(). If we did overflow, try to rewrite the data > and check again. Return true, if not overflew this time, otherwise > return false so that mailbox api can ask us to try again in next > last_tx_done(). This way we can do away with the tasklet and, more > importantly, avoid send_data() failures and retries on clients' part. That's a clever solution to avoid the tasklet. The only issue for us is the automatic TX retry from the controller. I understand that's generally a desirable feature, but in our case we'd like the client to have full control on re-transmission attempts. That's because some of our data is time-sensitive. For instance, when we process frames from a video stream we prefer dropping a frame rather than re-transmitting it and delaying the processing of the rest. Now, I understand that the client can set the 'tx_block' and 'tx_tout' channel fields to specify how long it wishes to wait, but the problem is that our (single) channel is shared between multiple applications having different timing requirements. That's why we prefer to let applications deal we re-transmissions. Given the above, do you think it's reasonable to leave the implementation as it is now? (from initial analysis, the tasklet doesn't seem to affect the performance of our use cases significantly, so we are fine with it)