[PATCH 13/18] rpmsg: glink: Add rx done command
From: Arun Kumar Neelakantam <hidden>
Date: 2017-08-23 04:44:50
Also in:
linux-arm-msm, linux-remoteproc, lkml
On 8/22/2017 7:46 PM, Sricharan R wrote:
Hi,quoted
quoted
+??? /* Take it off the tree of receive intents */ +??? if (!intent->reuse) { +??????? spin_lock(&channel->intent_lock); +??????? idr_remove(&channel->liids, intent->id); +??????? spin_unlock(&channel->intent_lock); +??? } + +??? /* Schedule the sending of a rx_done indication */ +??? spin_lock(&channel->intent_lock); +??? list_add_tail(&intent->node, &channel->done_intents); +??? spin_unlock(&channel->intent_lock); + +??? schedule_work(&channel->intent_work);Adding one more parallel path will hit performance, if this worker could not get CPU cycles or blocked by other RT or HIGH_PRIO worker on global worker pool.The idea is, by design to have parallel non-blocking paths for rx and tx (that is done as a part of rx by sending the rx_done command), otherwise trying to send the rx_done command in the rx isr context is a problem since the tx can wait for the FIFO space and in worst case, can even lead to a potential deadlock if both the local and remote try the same. Having said that, instead of queuing this work in to the global queue, this can be put in to a local glink edge owned queue (or) a threaded isr ?, downstream does the rx_done in a client specific worker.
Yes, mixing RX and TX path will cause dead lock. I am okay to use specific queue with HIGH_PRIO or a threaded isr. down stream uses both client specific worker and client RX cb [this mix the TX and RX path] which want to avoid.
Regards, Sricharan