Hi, Jassi, On 10/18/24 8:49 AM, Tudor Ambarus wrote: >>> The active request is considered completed when TX completes. But it seems >>> that TX is not in direct relation with RX, >>> >> Correct, and it is not meant to be. >> You are assuming there is always an RX in response to a TX, which is > Not really. If there's no response expected, clients can set req->rx to > NULL. Then the controllers know that no response is expected and can > complete the request when TX completes. > >> not the case. Many platforms just send a message and only need to know >> when it is sent. Many platforms only listen for incoming messages. > these 2 cases are covered with the req approach. > >> Many platforms have TX and RX but not as parts of one exchange. In > I don't think I understand this case. Is it related to what you describe > below? > >> fact, only minority of platforms expect RX after each TX. Btw, what if > Right, I noticed. > >> some platform sends only and always after each receive? For these > This case is covered as well with the req approach. One just needs to > serialize the requests: > > ret = mbox_send_request(dc->mbox_chan, req1); > ret = mbox_wait_request(ret, req1->wait); > if (ret) > return ret; > > // req1 completed, send req2 > ret = mbox_send_request(dc->mbox_chan, req2); > ret = mbox_wait_request(ret, req2->wait); > if (ret) > return ret; > > This shall work regardless if the client expects a response or not. If > no response is expected, but just a TX completion, then the client can > set req->rx = NULL. > >> reasons, it is left to the user to tie an incoming RX to some previous >> TX, or not. Is there a specific driver that I can look at in order to understand the case where RX is not tied to TX? It will speed me up a little. Also, if you think there's a better way to enable controllers to manage their hardware queues, please say. Thanks, ta
