From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752509AbbGaJsI (ORCPT ); Fri, 31 Jul 2015 05:48:08 -0400 Received: from foss.arm.com ([217.140.101.70]:43925 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751284AbbGaJkH (ORCPT ); Fri, 31 Jul 2015 05:40:07 -0400 Message-ID: <55BB4274.2050905@arm.com> Date: Fri, 31 Jul 2015 10:40:04 +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> 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 30/07/15 18:56, Jassi Brar wrote: > On Wed, Jul 29, 2015 at 6:20 PM, Sudeep Holla 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