From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752353AbbHEK5k (ORCPT ); Wed, 5 Aug 2015 06:57:40 -0400 Received: from foss.arm.com ([217.140.101.70]:33610 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751591AbbHEK5j (ORCPT ); Wed, 5 Aug 2015 06:57:39 -0400 Message-ID: <55C1EC1F.7080607@arm.com> Date: Wed, 05 Aug 2015 11:57:35 +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> <55BB735B.7010501@arm.com> In-Reply-To: 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 14:45, Jassi Brar wrote: > On Fri, Jul 31, 2015 at 6:38 PM, Sudeep Holla wrote: >> >> >> 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 ? >> > Yeah, that could happen. But the race can be fixed by checking > last_tx_done if the controller provides that. If last_tx_done is not > implemented, polling won't race. > > Please try the following... > Looks good to me. Sometimes it takes very long time(days) to hit race conditions(esp. in firmware), so I need some time to think before I cook up a patch to start stress test this on Juno so that I don't waste time waiting for result. Regards, Sudeep