Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp4326858pxu; Mon, 21 Dec 2020 09:35:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJyuzUhZgQwfkk2Q5wgOcL+70ZW1LFUcC/heoaeg2/2VNihu7iUw8wycDjRS38hfFWDtOOB+ X-Received: by 2002:a17:906:af5a:: with SMTP id ly26mr16332433ejb.416.1608572152369; Mon, 21 Dec 2020 09:35:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608572152; cv=none; d=google.com; s=arc-20160816; b=PBcBx95pcTo5yj0pRZcv5L/wNZm7uKVaGTusYFcBdzJQzXGybSYW//d/rs+NGF2gqj l08Ya6JSd/jRxaqKsuL0gtWZRr3SR+pNKi5nM1QruQeROU/iYwjKHpLVaAFWRoMStHGa 1XxSwBrOPmI9SnSn6Mp5fwi/NMmsrkEHmXrIZaanzHsOUyi2y0W7PLR37mZnG89qGVq/ 2bgzLJZfGpqhRFYKquK8p3o4RByUr4755+JEOLMX1d2ZpDl7lm4BvIZ3HDIfHsYGF0sL xglLyZB/5CrUPVdEBhD+Wkcx7T5qpP9+HXkZZ9c4Ew0DFLOrWqdILDeIjvDX11V3MAMP YZzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:message-id:references:in-reply-to :subject:cc:to:from:date:content-transfer-encoding:mime-version :sender:dkim-signature; bh=LVlBGXTzBukiwVBxNOa2Ps3aJ/OPXjBHqjWMMrEzyd0=; b=YKSMAPU/MsF6f+Jfghw1F8+49Grqm7Gxz6gZWM4f+EV2SD8VkUIVwdFprNh7nAdr+s ZYH8x4MgRGI6UD2e/I/x5aWgI/1lCdjCFjz9siRpwQhCAlI7nIJ7e3x8bGFmoa/5zYZ0 J9gYCQpB/ouxi3XRuBtY1cbe62Mf3Y5uALfdn/aS6eoDe9RyJechx5IhhNNRBTVX4Wk6 vVuOMQibq7BdK1Qw5OmUym7JdBWMTHK89Hw9JjAW32dCunUsRg9EUi2raHeDXLApRCV4 f4TfD7K94XIW+5RQNoHLc5yMyfgY5HLQAn/3y2YN06QAtlpd42pcUSwWTVSPgZwC2uW8 yj1Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mg.codeaurora.org header.s=smtp header.b="a/HjDSv6"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y11si9285682ejp.753.2020.12.21.09.35.20; Mon, 21 Dec 2020 09:35:52 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@mg.codeaurora.org header.s=smtp header.b="a/HjDSv6"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725820AbgLURec (ORCPT + 99 others); Mon, 21 Dec 2020 12:34:32 -0500 Received: from so254-31.mailgun.net ([198.61.254.31]:31479 "EHLO so254-31.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725783AbgLURec (ORCPT ); Mon, 21 Dec 2020 12:34:32 -0500 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1608572050; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=LVlBGXTzBukiwVBxNOa2Ps3aJ/OPXjBHqjWMMrEzyd0=; b=a/HjDSv6SuqnZRwPRs6cMC//rqEuzcZtlDRPkZDR1159YJZsaSdeVQ61Vxg0M8/iovhpoXDw d64qVjXp6dbtIB6+PR9OuvyDlHAY8H9mRZ7TMubKQjvu6sDmun1d+NFVFxznGV3yv6lBeaMJ 4Doep+GOmuPamwraZMvEPGp3EZ0= X-Mailgun-Sending-Ip: 198.61.254.31 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n08.prod.us-east-1.postgun.com with SMTP id 5fe0dc787bc801dc4fbf85a6 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Mon, 21 Dec 2020 17:33:44 GMT Sender: mdalam=codeaurora.org@mg.codeaurora.org Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 572A1C43462; Mon, 21 Dec 2020 17:33:43 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=ALL_TRUSTED,BAYES_00, URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mdalam) by smtp.codeaurora.org (Postfix) with ESMTPSA id 49C44C433C6; Mon, 21 Dec 2020 17:33:42 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 21 Dec 2020 23:03:42 +0530 From: mdalam@codeaurora.org To: Vinod Koul Cc: corbet@lwn.net, agross@kernel.org, bjorn.andersson@linaro.org, dan.j.williams@intel.com, dmaengine@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, sricharan@codeaurora.org Subject: Re: [PATCH] dmaengine: qcom: bam_dma: Add LOCK and UNLOCK flag bit support In-Reply-To: <20201221092355.GA3323@vkoul-mobl> References: <1608215842-15381-1-git-send-email-mdalam@codeaurora.org> <20201221092355.GA3323@vkoul-mobl> Message-ID: X-Sender: mdalam@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-12-21 14:53, Vinod Koul wrote: > Hello, > > On 17-12-20, 20:07, Md Sadre Alam wrote: >> This change will add support for LOCK & UNLOCK flag bit support >> on CMD descriptor. >> >> If DMA_PREP_LOCK flag passed in prep_slave_sg then requester of this >> transaction wanted to lock the DMA controller for this transaction so >> BAM driver should set LOCK bit for the HW descriptor. >> >> If DMA_PREP_UNLOCK flag passed in prep_slave_sg then requester of this >> transaction wanted to unlock the DMA controller.so BAM driver should >> set >> UNLOCK bit for the HW descriptor. > > Can you explain why would we need to first lock and then unlock..? How > would this be used in real world. > > I have read a bit of documentation but is unclear to me. Also should > this be exposed as an API to users, sounds like internal to driver..? > IPQ5018 SoC having only one Crypto Hardware Engine. This Crypto Hardware Engine will be shared between A53 core & ubi32 core. There is two separate driver dedicated to A53 core and ubi32 core. So to use Crypto Hardware Engine parallelly for encryption/description we need bam locking mechanism. if one driver will submit the request for encryption/description to Crypto then first it has to set LOCK flag bit on command descriptor so that other pipes will get locked. The Pipe Locking/Unlocking will be only on command-descriptor. Upon encountering a command descriptor with LOCK bit set, The BAM will lock all other pipes not related to the current pipe group, and keep handling the current pipe only until it sees the UNLOCK set then it will release all locked pipes. locked pipe will not fetch new descriptors even if it got event/events adding more descriptors for this pipe (locked pipe). No need to expose as an API to user because its internal to driver, so while preparing command descriptor just we have to update the LOCK/UNLOCK flag. > >> >> Signed-off-by: Md Sadre Alam >> --- >> Documentation/driver-api/dmaengine/provider.rst | 9 +++++++++ >> drivers/dma/qcom/bam_dma.c | 9 +++++++++ >> include/linux/dmaengine.h | 5 +++++ >> 3 files changed, 23 insertions(+) >> >> diff --git a/Documentation/driver-api/dmaengine/provider.rst >> b/Documentation/driver-api/dmaengine/provider.rst >> index ddb0a81..d7516e2 100644 >> --- a/Documentation/driver-api/dmaengine/provider.rst >> +++ b/Documentation/driver-api/dmaengine/provider.rst >> @@ -599,6 +599,15 @@ DMA_CTRL_REUSE >> - This flag is only supported if the channel reports the >> DMA_LOAD_EOT >> capability. >> >> +- DMA_PREP_LOCK >> + >> + - If set , the client driver tells DMA controller I am locking you >> for >> + this transcation. >> + >> +- DMA_PREP_UNLOCK >> + >> + - If set, the client driver will tells DMA controller I am >> releasing the lock >> + >> General Design Notes >> ==================== >> >> diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c >> index 4eeb8bb..cdbe395 100644 >> --- a/drivers/dma/qcom/bam_dma.c >> +++ b/drivers/dma/qcom/bam_dma.c >> @@ -58,6 +58,8 @@ struct bam_desc_hw { >> #define DESC_FLAG_EOB BIT(13) >> #define DESC_FLAG_NWD BIT(12) >> #define DESC_FLAG_CMD BIT(11) >> +#define DESC_FLAG_LOCK BIT(10) >> +#define DESC_FLAG_UNLOCK BIT(9) >> >> struct bam_async_desc { >> struct virt_dma_desc vd; >> @@ -644,6 +646,13 @@ static struct dma_async_tx_descriptor >> *bam_prep_slave_sg(struct dma_chan *chan, >> >> /* fill in temporary descriptors */ >> desc = async_desc->desc; >> + if (flags & DMA_PREP_CMD) { >> + if (flags & DMA_PREP_LOCK) >> + desc->flags |= cpu_to_le16(DESC_FLAG_LOCK); >> + if (flags & DMA_PREP_UNLOCK) >> + desc->flags |= cpu_to_le16(DESC_FLAG_UNLOCK); >> + } >> + >> for_each_sg(sgl, sg, sg_len, i) { >> unsigned int remainder = sg_dma_len(sg); >> unsigned int curr_offset = 0; >> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h >> index dd357a7..79ccadb4 100644 >> --- a/include/linux/dmaengine.h >> +++ b/include/linux/dmaengine.h >> @@ -190,6 +190,9 @@ struct dma_interleaved_template { >> * transaction is marked with DMA_PREP_REPEAT will cause the new >> transaction >> * to never be processed and stay in the issued queue forever. The >> flag is >> * ignored if the previous transaction is not a repeated >> transaction. >> + * @DMA_PREP_LOCK: tell the driver that DMA HW engine going to be >> locked for this >> + * transaction , until not seen DMA_PREP_UNLOCK flag set. >> + * @DMA_PREP_UNLOCK: tell the driver to unlock the DMA HW engine. >> */ >> enum dma_ctrl_flags { >> DMA_PREP_INTERRUPT = (1 << 0), >> @@ -202,6 +205,8 @@ enum dma_ctrl_flags { >> DMA_PREP_CMD = (1 << 7), >> DMA_PREP_REPEAT = (1 << 8), >> DMA_PREP_LOAD_EOT = (1 << 9), >> + DMA_PREP_LOCK = (1 << 10), >> + DMA_PREP_UNLOCK = (1 << 11), >> }; >> >> /** >> -- >> 2.7.4