From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jassi Brar Subject: Re: [PATCH v4 3/5] soc: qcom: Introduce APCS IPC driver Date: Sat, 6 May 2017 01:52:43 +0530 Message-ID: References: <20170504200539.27027-1-bjorn.andersson@linaro.org> <20170504200539.27027-3-bjorn.andersson@linaro.org> <20170505183729.GG15143@minitux> <338c4262-cc6b-bed2-16fe-1767d1f0d5f6@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <338c4262-cc6b-bed2-16fe-1767d1f0d5f6@codeaurora.org> Sender: linux-kernel-owner@vger.kernel.org To: Jeffrey Hugo Cc: Bjorn Andersson , Andy Gross , Rob Herring , Mark Rutland , Ohad Ben-Cohen , linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org, Devicetree List , Linux Kernel Mailing List , linux-remoteproc@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org On Sat, May 6, 2017 at 1:23 AM, Jeffrey Hugo wrote: > On 5/5/2017 1:22 PM, Jassi Brar wrote: >> >> On Sat, May 6, 2017 at 12:07 AM, Bjorn Andersson >> wrote: >>> > > There is no way to determine if the remote processor has observed a message, > that does not involve pretty trivial race conditions. > Thanks for chiming in. How is it supposed to work if a client queues more than one request? How do you know when it's ok to overwrite the FIFO and send the next command? Usually if h/w doesn't indicate, we cook up some ack packet for each command. Otherwise the protocol seems badly broken. If there is really nothing that can be done to check delivery of a message, I'll pick the driver as such. Best of luck :)