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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 D2068C433E2 for ; Wed, 15 Jul 2020 10:59:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AEE11206F5 for ; Wed, 15 Jul 2020 10:59:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594810751; bh=gQDuwnfiYL4Tg4MTPc2Nx5XzK8KZyztd78Q4IrCdP/c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=WfadhoDgGt8t+6hzUvaiziH2XIxBSL4YmmX1JdaZQm7TVZwaVmHwJdII3A7crGHyr q/39UiOTagj6GO3KCJhmTo7/8DEscG8obuT8Xv4VCV2tO6fLL3A+j68847BZhIGHNZ +WPz4xLjnB+jdpu5d58be6/mV2orALVVOPgReCFI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728861AbgGOK7L (ORCPT ); Wed, 15 Jul 2020 06:59:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:43984 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728385AbgGOK7L (ORCPT ); Wed, 15 Jul 2020 06:59:11 -0400 Received: from localhost (unknown [122.171.202.192]) (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 CC5E7206E9; Wed, 15 Jul 2020 10:59:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594810750; bh=gQDuwnfiYL4Tg4MTPc2Nx5XzK8KZyztd78Q4IrCdP/c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QO6BK+yNqXYbJVg/T/fX7N7KuNMRhxntihPKqWhuwZKwgso2s0Wb8RkgJVyCDpZ+v paBdUjj76KIFN8x/POZ5H7K1STLSBUTzYXMBMSW5GowjNYLNi91Y+kFEx4AyCs+1ej tBff+Y2zkMMmnD7k78Fiu8Od/lt+I1p79qzSuwbY= Date: Wed, 15 Jul 2020 16:29:06 +0530 From: Vinod Koul To: Laurent Pinchart Cc: dmaengine@vger.kernel.org, Michal Simek , Hyun Kwon , Tejas Upadhyay , Satish Kumar Nagireddy , Peter Ujfalusi Subject: Re: [PATCH v6 4/6] dmaengine: xilinx: dpdma: Add the Xilinx DisplayPort DMA engine driver Message-ID: <20200715105906.GI34333@vkoul-mobl> References: <20200708201906.4546-1-laurent.pinchart@ideasonboard.com> <20200708201906.4546-5-laurent.pinchart@ideasonboard.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200708201906.4546-5-laurent.pinchart@ideasonboard.com> Sender: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org On 08-07-20, 23:19, Laurent Pinchart wrote: > +static struct dma_async_tx_descriptor * > +xilinx_dpdma_prep_interleaved_dma(struct dma_chan *dchan, > + struct dma_interleaved_template *xt, > + unsigned long flags) > +{ > + struct xilinx_dpdma_chan *chan = to_xilinx_chan(dchan); > + struct xilinx_dpdma_tx_desc *desc; > + > + if (xt->dir != DMA_MEM_TO_DEV) > + return NULL; > + > + if (!xt->numf || !xt->sgl[0].size) > + return NULL; > + > + if (!(flags & DMA_PREP_REPEAT)) > + return NULL; is the hw be not capable of supporting single interleave txn? Also as replied the comment to Peter, we should check chan->running here and see that DMA_PREP_LOAD_EOT is set. There can still be a case where descriptor is submitted but not issued causing you to miss, but i guess that might be overkill for your scenarios > +static int xilinx_dpdma_config(struct dma_chan *dchan, > + struct dma_slave_config *config) > +{ > + struct xilinx_dpdma_chan *chan = to_xilinx_chan(dchan); > + unsigned long flags; > + > + /* > + * The destination address doesn't need to be specified as the DPDMA is > + * hardwired to the destination (the DP controller). The transfer > + * width, burst size and port window size are thus meaningless, they're > + * fixed both on the DPDMA side and on the DP controller side. > + */ But we are not doing peripheral transfers, this is memory to memory (interleave) here right? > + > + spin_lock_irqsave(&chan->lock, flags); > + > + /* > + * Abuse the slave_id to indicate that the channel is part of a video > + * group. > + */ > + if (chan->id >= ZYNQMP_DPDMA_VIDEO0 && chan->id <= ZYNQMP_DPDMA_VIDEO2) > + chan->video_group = config->slave_id != 0; Okay looking closely here, the video_group is used to tie different channels together to ensure sync operation is that right? And this seems to be only reason for DMA_SLAVE capabilities, i don't think I saw slave ops > +static int xilinx_dpdma_terminate_all(struct dma_chan *dchan) > +{ > + struct xilinx_dpdma_chan *chan = to_xilinx_chan(dchan); > + struct xilinx_dpdma_device *xdev = chan->xdev; > + LIST_HEAD(descriptors); > + unsigned long flags; > + unsigned int i; > + > + /* Pause the channel (including the whole video group if applicable). */ > + if (chan->video_group) { > + for (i = ZYNQMP_DPDMA_VIDEO0; i <= ZYNQMP_DPDMA_VIDEO2; i++) { > + if (xdev->chan[i]->video_group && > + xdev->chan[i]->running) { > + xilinx_dpdma_chan_pause(xdev->chan[i]); so there is no terminate here, only pause? -- ~Vinod