On 30/07/15 18:56, Jassi Brar wrote:
On Wed, Jul 29, 2015 at 6:20 PM, Sudeep Holla <sudeep.ho...@arm.com> wrote:
On 29/07/15 12:19, Jassi Brar wrote:
Assuming the former, let me explain. When a client receives a
response, it can be sure that the request has already been read by the
remote.
Waiting for the response would be too late for few expensive commands
(e.g setting up external regulators). The remote firmware acknowledges
Tx by setting status flags and will be ready to accept new commands.
No. Polling still happens. If anything, mbox_client_txdone() should
only speed up things.
If the protocol specifies every request has some response, the
Not always true there can be few commands without response. The protocol
specifies that we need check the status flag before sending the new
command as it's bidirectional, hence polling is recommended (Section 2.2
Communication flow in the SCPI specification)
mbox_client_txdone() will only be called for commands that has some
response. Commands that don't have a response would be completed by
polling.
I forgot to mention, we have a the following description in
mbox_client_txdone which is misleading:
"The client/protocol had received some 'ACK' packet and it notifies the
API that the last packet was sent successfully. This only works if the
controller can't sense TX-Done."
which is clearly not the case in SCPI. IMO we may have to reword that.
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
