From patchwork Mon Jul 8 15:47:26 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sudeep Holla X-Patchwork-Id: 168684 Delivered-To: patch@linaro.org Received: by 2002:a92:4782:0:0:0:0:0 with SMTP id e2csp7331674ilk; Mon, 8 Jul 2019 08:48:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqxSQ+y5fdbgQI6nQth/r7W/oBmHMD8CnfjK3h7f8GQ1ze+4Q67xLqBDw1JulwA4aivODFwd X-Received: by 2002:a17:902:28e9:: with SMTP id f96mr24910610plb.114.1562600901792; Mon, 08 Jul 2019 08:48:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562600901; cv=none; d=google.com; s=arc-20160816; b=wkFm84BBXhtAT6D1lNuSVKd9Xf7yZdTwTNu76MFSQy14q68t65EZtgj36MGTjzd/ig rgp4qdnlN4r2VTCk7pixkMxdvWffQq6SAc8KqpxmF/HVoutcQFu6kDbWkGjXyFRS4FC6 vDyrVrR8u77d5WvdRL6QbgGoBmgSjSIHS/MgHZXb7FTIwqugjkd4emYy5l8yV1TlgR+b eUlQqfWGjSG+mfVGx+bjZlRuL+hFoHo3xKNHeXwytygqyJOLh+OM4h61kpSPV7Oi5FK9 Ur4E9OCXyjDGhPNTPdx9li5X+CcgEwofnuSL8+LfB2cC6bchc4pCJaNYzXd08dHzyPOz Jv0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=ISRVkqg3muPnIGnVBRuwT/HxImaeDEUdcX4kyPsUq5k=; b=uT23sLuvAkOYh/uyNrLKAcPWBji0ick6ABGEzPqmEqKSkRKcumRnvL49Nq6/hj80ce e5JxxA86o7iGhLnqvt9fVG/b53taoSisc9Y4etn4z1YSWBEz56xxfpMjL6kMkEM8arIo UK84f7vJzqcNq3xTD5OvsnsIXQdc77TkcHf52/0jOwoQselBZHvuuj3mdwCo9Ex1Umuf 7OslXyviYlF/3vhvDbOB20R8F5qv4JJNLIoo3jscEKgBf3a1zem2c059cbqKVrV+VkJW OcM62P8iGMMnZ68EvA9CeRiSZ40aYbQQG43uaisURax5/tdEBc8rEynywy6rAHNkR8x8 p3GA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r8si8652450pgr.243.2019.07.08.08.48.21; Mon, 08 Jul 2019 08:48:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2403913AbfGHPsP (ORCPT + 30 others); Mon, 8 Jul 2019 11:48:15 -0400 Received: from foss.arm.com ([217.140.110.172]:52392 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391324AbfGHPru (ORCPT ); Mon, 8 Jul 2019 11:47:50 -0400 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 E2BEB360; Mon, 8 Jul 2019 08:47:49 -0700 (PDT) Received: from usa.arm.com (e107155-lin.cambridge.arm.com [10.1.196.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id DFF7C3F59C; Mon, 8 Jul 2019 08:47:48 -0700 (PDT) From: Sudeep Holla To: linux-arm-kernel@lists.infradead.org Cc: Sudeep Holla , linux-kernel@vger.kernel.org, Peng Fan , Jim Quinlan , Bo Zhang , Volodymyr Babchuk Subject: [PATCH 07/11] firmware: arm_scmi: Add support for asynchronous commands and delayed response Date: Mon, 8 Jul 2019 16:47:26 +0100 Message-Id: <20190708154730.16643-8-sudeep.holla@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20190708154730.16643-1-sudeep.holla@arm.com> References: <20190708154730.16643-1-sudeep.holla@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Messages that are sent to platform, also known as commands and can be: 1. Synchronous commands that block the channel until the requested work has been completed. The platform responds to these commands over the same channel and hence can't be used to send another command until the previous command has completed. 2. Asynchronous commands on the other hand, the platform schedules the requested work to complete later in time and returns almost immediately freeing the channel for new commands. The response indicates the success or failure in the ability to schedule the requested work. When the work has completed, the platform sends an additional delayed response message. Using the same transmit buffer used for sending the asynchronous command even for the delayed response corresponding to it simplifies handling of the delayed response. It's the caller of asynchronous command that is responsible for allocating the completion flag that scmi driver can complete to indicate the arrival of delayed response. Signed-off-by: Sudeep Holla --- drivers/firmware/arm_scmi/common.h | 6 ++++- drivers/firmware/arm_scmi/driver.c | 43 ++++++++++++++++++++++++++++-- 2 files changed, 46 insertions(+), 3 deletions(-) -- 2.17.1 diff --git a/drivers/firmware/arm_scmi/common.h b/drivers/firmware/arm_scmi/common.h index 4349d836b392..f89fa3f74a6f 100644 --- a/drivers/firmware/arm_scmi/common.h +++ b/drivers/firmware/arm_scmi/common.h @@ -84,17 +84,21 @@ struct scmi_msg { * @rx: Receive message, the buffer should be pre-allocated to store * message. If request-ACK protocol is used, we can reuse the same * buffer for the rx path as we use for the tx path. - * @done: completion event + * @done: command message transmit completion event + * @async: pointer to delayed response message received event completion */ struct scmi_xfer { struct scmi_msg_hdr hdr; struct scmi_msg tx; struct scmi_msg rx; struct completion done; + struct completion *async_done; }; void scmi_xfer_put(const struct scmi_handle *h, struct scmi_xfer *xfer); int scmi_do_xfer(const struct scmi_handle *h, struct scmi_xfer *xfer); +int scmi_do_xfer_with_response(const struct scmi_handle *h, + struct scmi_xfer *xfer); int scmi_xfer_get_init(const struct scmi_handle *h, u8 msg_id, u8 prot_id, size_t tx_size, size_t rx_size, struct scmi_xfer **p); int scmi_handle_put(const struct scmi_handle *handle); diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c index b384c818d8dd..049bb4af6b60 100644 --- a/drivers/firmware/arm_scmi/driver.c +++ b/drivers/firmware/arm_scmi/driver.c @@ -347,6 +347,8 @@ __scmi_xfer_put(struct scmi_xfers_info *minfo, struct scmi_xfer *xfer) */ static void scmi_rx_callback(struct mbox_client *cl, void *m) { + u8 msg_type; + u32 msg_hdr; u16 xfer_id; struct scmi_xfer *xfer; struct scmi_chan_info *cinfo = client_to_scmi_chan_info(cl); @@ -355,7 +357,12 @@ static void scmi_rx_callback(struct mbox_client *cl, void *m) struct scmi_xfers_info *minfo = &info->tx_minfo; struct scmi_shared_mem __iomem *mem = cinfo->payload; - xfer_id = MSG_XTRACT_TOKEN(ioread32(&mem->msg_header)); + msg_hdr = ioread32(&mem->msg_header); + msg_type = MSG_XTRACT_TYPE(msg_hdr); + xfer_id = MSG_XTRACT_TOKEN(msg_hdr); + + if (msg_type == MSG_TYPE_NOTIFICATION) + return; /* Notifications not yet supported */ /* Are we even expecting this? */ if (!test_bit(xfer_id, minfo->xfer_alloc_table)) { @@ -368,7 +375,11 @@ static void scmi_rx_callback(struct mbox_client *cl, void *m) scmi_dump_header_dbg(dev, &xfer->hdr); scmi_fetch_response(xfer, mem); - complete(&xfer->done); + + if (msg_type == MSG_TYPE_DELAYED_RESP) + complete(xfer->async_done); + else + complete(&xfer->done); } /** @@ -472,6 +483,34 @@ int scmi_do_xfer(const struct scmi_handle *handle, struct scmi_xfer *xfer) return ret; } +#define SCMI_MAX_RESPONSE_TIMEOUT (2 * MSEC_PER_SEC) + +/** + * scmi_do_xfer_with_response() - Do one transfer and wait until the delayed + * response is received + * + * @handle: Pointer to SCMI entity handle + * @xfer: Transfer to initiate and wait for response + * + * Return: -ETIMEDOUT in case of no delayed response, if transmit error, + * return corresponding error, else if all goes well, return 0. + */ +int scmi_do_xfer_with_response(const struct scmi_handle *handle, + struct scmi_xfer *xfer) +{ + int ret, timeout = msecs_to_jiffies(SCMI_MAX_RESPONSE_TIMEOUT); + DECLARE_COMPLETION_ONSTACK(async_response); + + xfer->async_done = &async_response; + + ret = scmi_do_xfer(handle, xfer); + if (!ret && !wait_for_completion_timeout(xfer->async_done, timeout)) + ret = -ETIMEDOUT; + + xfer->async_done = NULL; + return ret; +} + /** * scmi_xfer_get_init() - Allocate and initialise one message for transmit *