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.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 506C3C43331 for ; Tue, 12 Nov 2019 05:34:51 +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 2559D2084F for ; Tue, 12 Nov 2019 05:34:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="OKO/a+a2"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="swnFRxTo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2559D2084F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=+EIJo+lYFg+xv8hZZEC+PpdSF1Ycq43naa3+dTTI2eg=; b=OKO/a+a25IbfsK bzqoLOOjsUofxfR82TbAjEh1gx4ZsgBCyIB0i7zYrUDo/9ncuB6XZjCnV3mYAwkuRHfspEK4I4eFV 6bjxnMiLWMtwPBVopsvARnL55tpftvWVYddzARyWhjCNKoK9VAv+yhcZGfPxE6Fci0WfI9Pog+c2v HVF2SlqiR1AekD8nyX36hs33vDUQrirdi3zZ2NpO2/OCJF7JgtDgaoYBMjkLKN41l77Q/kKtLWakc Nwb06/CpT16zZxNPxU/Li0xtKmGwF57JZsA1Hiqlbt58MGTOOAytdS+y8k5MEDEnIfHwhao9FkLy2 2gsGxSE2PHOMvUo6V2cA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1iUOpG-0004q9-P3; Tue, 12 Nov 2019 05:34:50 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1iUOpD-0004pH-Tv for linux-arm-kernel@lists.infradead.org; Tue, 12 Nov 2019 05:34:49 +0000 Received: from localhost (unknown [122.167.70.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 80D8D2084F; Tue, 12 Nov 2019 05:34:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573536887; bh=Jb7dYixP6yIjsrokC6NTgrZ/74+6EVtRM48rK5FZNvY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=swnFRxTopGg49WadsvYOwM4ZljN75NOKNOp1Z9e5BW0FyYQHYvejgIuS/T6ZaeS+f gxIT4lF0hqOk50dDZyDJJSafiZ3bZ8R9mleb8cOsMrZAepP86BKYPsfg0wzquvM826 YuIVlpKmlK7CHZSlLwZbDQfxBtffsMv1FmSgU/Ak= Date: Tue, 12 Nov 2019 11:04:40 +0530 From: Vinod Koul To: Peter Ujfalusi Subject: Re: [PATCH v4 10/15] dmaengine: ti: New driver for K3 UDMA - split#2: probe/remove, xlate and filter_fn Message-ID: <20191112053440.GV952516@vkoul-mobl> References: <20191101084135.14811-1-peter.ujfalusi@ti.com> <20191101084135.14811-11-peter.ujfalusi@ti.com> <20191111053301.GO952516@vkoul-mobl> <9b0f8bec-4964-8136-4173-7b45e479c0c5@ti.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9b0f8bec-4964-8136-4173-7b45e479c0c5@ti.com> User-Agent: Mutt/1.12.1 (2019-06-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191111_213447_983748_88282149 X-CRM114-Status: GOOD ( 16.66 ) 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: nm@ti.com, devicetree@vger.kernel.org, grygorii.strashko@ti.com, lokeshvutla@ti.com, j-keerthy@ti.com, linux-kernel@vger.kernel.org, t-kristo@ti.com, tony@atomide.com, robh+dt@kernel.org, ssantosh@kernel.org, dmaengine@vger.kernel.org, dan.j.williams@intel.com, 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 11-11-19, 11:16, Peter Ujfalusi wrote: > > > On 11/11/2019 7.33, Vinod Koul wrote: > > On 01-11-19, 10:41, Peter Ujfalusi wrote: > > > >> +static bool udma_dma_filter_fn(struct dma_chan *chan, void *param) > >> +{ > >> + struct psil_endpoint_config *ep_config; > >> + struct udma_chan *uc; > >> + struct udma_dev *ud; > >> + u32 *args; > >> + > >> + if (chan->device->dev->driver != &udma_driver.driver) > >> + return false; > >> + > >> + uc = to_udma_chan(chan); > >> + ud = uc->ud; > >> + args = param; > >> + uc->remote_thread_id = args[0]; > >> + > >> + if (uc->remote_thread_id & K3_PSIL_DST_THREAD_ID_OFFSET) > >> + uc->dir = DMA_MEM_TO_DEV; > >> + else > >> + uc->dir = DMA_DEV_TO_MEM; > > > > Can you explain this a bit? > > The UDMAP in K3 works between two PSI-L endpoint. The source and > destination needs to be paired to allow data flow. > Source thread IDs are in range of 0x0000 - 0x7fff, while destination > thread IDs are 0x8000 - 0xffff. > > If the remote thread ID have the bit 31 set (0x8000) then the transfer > is MEM_TO_DEV and I need to pick one unused tchan for it. If the remote > is the source then it can be handled by rchan. > > dmas = <&main_udmap 0xc400>, <&main_udmap 0x4400>; > dma-names = "tx", "rx"; > > 0xc400 is a destination thread ID, so it is MEM_TO_DEV > 0x4400 is a source thread ID, so it is DEV_TO_MEM > > Even in MEM_TO_MEM case I need to pair two UDMAP channels: > UDMAP source threads are starting at offset 0x1000, UDMAP destination > threads are 0x9000+ Okay so a channel is set for a direction until teardown. Also this and other patch comments are quite useful, can we add them here? > Changing direction runtime is hardly possible as it would involve > tearing down the channel, removing interrupts, destroying rings, > removing the PSI-L pairing and redoing everything. okay I would expect the prep_ to check for direction and reject the call if direction is different. -- ~Vinod _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel