From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752694AbbGaNJB (ORCPT ); Fri, 31 Jul 2015 09:09:01 -0400 Received: from foss.arm.com ([217.140.101.70]:44965 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751000AbbGaNIr (ORCPT ); Fri, 31 Jul 2015 09:08:47 -0400 Message-ID: <55BB735B.7010501@arm.com> Date: Fri, 31 Jul 2015 14:08:43 +0100 From: Sudeep Holla User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Jassi Brar CC: Sudeep Holla , Linux Kernel Mailing List , Liviu Dudau , Punit Agrawal , "Jon Medhurst (Tixy)" , Lorenzo Pieralisi , Arnd Bergmann , Olof Johansson , Kevin Hilman Subject: Re: [PATCH v5 2/8] firmware: add support for ARM System Control and Power Interface(SCPI) protocol References: <1437649828-14540-1-git-send-email-sudeep.holla@arm.com> <1437649828-14540-3-git-send-email-sudeep.holla@arm.com> <55B89100.3020802@arm.com> <55B8CC23.5020306@arm.com> <55BB4274.2050905@arm.com> <55BB5138.2010004@arm.com> In-Reply-To: <55BB5138.2010004@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 31/07/15 11:43, Sudeep Holla wrote: > > > On 31/07/15 11:38, Jassi Brar wrote: >> On Fri, Jul 31, 2015 at 3:10 PM, Sudeep Holla wrote: >>> >>> 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. >>> >> Yes. And also see whether it could race with polling driven tx_tick. >> > > Yes I am also looking at that now while I am trying to check if > TXDONE_BY_ACK works on Juno, will keep you posted. > OK, I recollect the racy condition now which I had in my mind from the beginning convincing myself why we can't use that option. I was not good in words to explain it so far but let me try with the ASCII art this time. Note Tx ACK below means the remote setting the register flag and not to be confused with the ACK packet. For simplicity Rx can be assumed to be Tx ACK packet Time MHU/SCPI Remote SCP | | 1 |------------ Tx1 -------------->| | | 2 |<----------- Tx1 ACK -----------| | | 3 |------------ Tx2 -------------->| | | 4 |<----------- Rx1 ---------------| | | 5 |<----------- Tx2 ACK -----------| | | 6 |------------ Tx3 -------------->| | | 7 |<----------- Rx2 ---------------| Now lets consider the above scenario, suppose we have TXDONE_BY_ACK and use mbox_client_txdone in Rx interrupt(i.e. response packet), we end up in the race easily IIUC. E.g. A client would have sent Tx2(3) before Rx1 interrupt(4) and if we ACK Tx1 now in (3), we will end up acknowledging Tx2(5) as the mailbox core assumes only one Tx request at a time which is clearly not the case in our setup. The client can then go ahead and send Tx3(6) overwriting the payload while remote was processing or even result in remote missing the request completely. Does that make sense or am I missing something ? Regards, Sudeep