Hi, Jassi,

On 10/18/24 8:49 AM, Tudor Ambarus wrote:

quoted

quoted

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.

quoted

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.

quoted

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?

quoted

fact, only minority of platforms expect RX after each TX. Btw, what if

Right, I noticed.

quoted

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.

quoted

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