Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755549AbaDPKhN (ORCPT ); Wed, 16 Apr 2014 06:37:13 -0400 Received: from mga02.intel.com ([134.134.136.20]:41770 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755151AbaDPKhF (ORCPT ); Wed, 16 Apr 2014 06:37:05 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,871,1389772800"; d="scan'208";a="494066815" Date: Wed, 16 Apr 2014 15:56:57 +0530 From: Vinod Koul To: Srikanth Thokala Cc: "Williams, Dan J" , Michal Simek , Grant Likely , Rob Herring , Levente Kurusa , Lars-Peter Clausen , andriy.shevchenko@linux.jf.intel.com, Jaswinder Singh , dmaengine@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v7 2/2] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support Message-ID: <20140416102657.GS32284@intel.com> References: <1396008222-7058-1-git-send-email-sthokal@xilinx.com> <1396008222-7058-3-git-send-email-sthokal@xilinx.com> <20140416090605.GP32284@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 16, 2014 at 03:41:34PM +0530, Srikanth Thokala wrote: > On Wed, Apr 16, 2014 at 2:36 PM, Vinod Koul wrote: > > On Fri, Mar 28, 2014 at 05:33:42PM +0530, Srikanth Thokala wrote: > >> This is the driver for the AXI Video Direct Memory Access (AXI > >> VDMA) core, which is a soft Xilinx IP core that provides high- > >> bandwidth direct memory access between memory and AXI4-Stream > >> type video target peripherals. The core provides efficient two > >> dimensional DMA operations with independent asynchronous read > >> and write channel operation. > >> > >> This module works on Zynq (ARM Based SoC) and Microblaze platforms. > > > > Okay the series is fine and was going to apply it BUT > > 1) need ack on DT patch.. > > 2) issues below on managing the descriptor and resetting the cookie :( > > Ok. > > > > >> + > >> +/** > >> + * xilinx_vdma_tx_descriptor - Allocate transaction descriptor > >> + * @chan: Driver specific VDMA channel > >> + * > >> + * Return: The allocated descriptor on success and NULL on failure. > >> + */ > >> +static struct xilinx_vdma_tx_descriptor * > >> +xilinx_vdma_alloc_tx_descriptor(struct xilinx_vdma_chan *chan) > >> +{ > >> + struct xilinx_vdma_tx_descriptor *desc; > >> + unsigned long flags; > >> + > >> + if (chan->allocated_desc) > >> + return chan->allocated_desc; > > ?? > > > >> + > >> + desc = kzalloc(sizeof(*desc), GFP_KERNEL); > >> + if (!desc) > >> + return NULL; > >> + > >> + spin_lock_irqsave(&chan->lock, flags); > >> + chan->allocated_desc = desc; > > ah why do you need this? > > > > So this essentailly prevents you from preparing two trasactions at same time as > > you would overwrite?? > > This will allow to queue up multiple segments on to a single > transaction descriptor. > User will submit this single desc and in the issue_pending() we decode multiple > segments and submit to SG HW engine. We free up the allocated_desc when it is > submitted to the HW. This is added after my discussion with Jaswinder, to best > utilize HW SG engine. I think best utilization of HW SG engine would happen if we collate the pending list when you start dma.... -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/