From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 00806C76188 for ; Fri, 19 Jul 2019 11:03:32 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B7A7420659 for ; Fri, 19 Jul 2019 11:03:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="SbwNprlG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B7A7420659 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Ev3J53Vq2B/P0lnWElTWhuE5TOGm/2FpqVdYC/9R7Ww=; b=SbwNprlGzDeefZ J8FMvwjfAlvpZhBjwCvKG7NpHcBedXCsX7rdlpjoaiUSJHGbN896G1RcYtWckGPde1DyESVSSqXEh yOrOpSsJzuCrmAbHRzCs1qSZb7qDsfV8I/iZNFym0n3JuBwuSriM4uCgH3nB8tUIwk8IeofvGHViN vWWI6fsrjqCoBkwcO11LSCCtY9u7lcHZJZqiucc9m22eJOwjbDQQlsm2at+w35DmIGVrS3uDc0pUk JfRUgrnhSs3cw5Cot2lH/0qbYRcS66DRcz8LbjnjZO9Tt6ih7GHMtnXQhWZzNI/VbFZSYCzUc0tO7 P0dzi5E7vuFHgeLG0Ovg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hoQfh-0000kY-R1; Fri, 19 Jul 2019 11:03:29 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hoQfe-0000jk-1p for linux-arm-kernel@lists.infradead.org; Fri, 19 Jul 2019 11:03:27 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C1676337; Fri, 19 Jul 2019 04:03:23 -0700 (PDT) Received: from e107155-lin (e107155-lin.cambridge.arm.com [10.1.196.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D5BE23F59C; Fri, 19 Jul 2019 04:03:22 -0700 (PDT) Date: Fri, 19 Jul 2019 12:03:20 +0100 From: Sudeep Holla To: Jim Quinlan Subject: Re: [PATCH 07/11] firmware: arm_scmi: Add support for asynchronous commands and delayed response Message-ID: <20190719110320.GC18022@e107155-lin> References: <20190708154730.16643-1-sudeep.holla@arm.com> <20190708154730.16643-8-sudeep.holla@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190719_040326_137315_2E169D97 X-CRM114-Status: GOOD ( 20.34 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peng Fan , Bo Zhang , Volodymyr Babchuk , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jul 18, 2019 at 05:38:06PM -0400, Jim Quinlan wrote: > Hi Sudeep, > > Just a comment in general. The asynchronous commands you are > implementing are not really asynchronous to the caller. Yes, but as per specification, the idea is to release the channel for other communication. > Yes it is is "async" at the low level, but there is no way to use > scmi_do_xfer() or scmi_do_xfer_with_response() and have the calling > thread be able to continue on in parallel with the command being > processed by the platform. This will limit the types of applications > that can use SCMI (perhaps this is intentional). Yes indeed, it's intentional and async is applicable for channel usage. > I was hoping that true async would be possible, and that the caller > could also register a callback function to be invoked when the command > was completed. Is this something that may be added in the future? This is how notifications are designed and must work. I would suggest to use notifications instead. Do you see any issues with that approach ? > It does overlap with notifications, because with those messages you > will need some kind of callback or handler thread. > Ah you do mention about overlap. I am replying as I read, sorry for that. Anyways, let me know if we can just use notifications. Also the current sync users(mainly clocks and sensors), may need even change in Linux infrastructure if we need to make it work in notification style. It would be good to know the use case you are referring. > BTW, if scmi_do_xfer_with_response() returns --ETIMEDOUT the caller > has no way of knowing whether it was the command ack timeout or the > command execution timeout. > Yes, I did think about this but I left it as is thinking it may not be important. Do you think that makes a difference ? I am fine to change if there are users that needs to handle the difference. -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel