From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753159Ab1JJJ0D (ORCPT ); Mon, 10 Oct 2011 05:26:03 -0400 Received: from mga03.intel.com ([143.182.124.21]:44306 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753034Ab1JJJ0C (ORCPT ); Mon, 10 Oct 2011 05:26:02 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,516,1312182000"; d="scan'208";a="24790490" Subject: Re: [PATCHv4] DMAEngine: Define interleaved transfer request api From: Vinod Koul To: Jassi Brar Cc: "Williams, Dan J" , Russell King , Barry Song <21cnbao@gmail.com>, linux-kernel@vger.kernel.org, DL-SHA-WorkGroupLinux , Dave Jiang In-Reply-To: References: <1317191992-3635-1-git-send-email-jaswinder.singh@linaro.org> <1317200618.1573.1765.camel@vkoul-udesk3> <1317295068.1573.1780.camel@vkoul-udesk3> <20111003161349.GB28287@flint.arm.linux.org.uk> <1317966346.1573.2252.camel@vkoul-udesk3> <1317997177.1573.2275.camel@vkoul-udesk3> <1318229592.1573.2298.camel@vkoul-udesk3> Content-Type: text/plain; charset="UTF-8" Date: Mon, 10 Oct 2011 14:48:16 +0530 Message-ID: <1318238296.1546.3.camel@vkoul-udesk3> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2011-10-10 at 14:46 +0530, Jassi Brar wrote: > On 10 October 2011 12:23, Vinod Koul wrote: > > > > +struct dmaxfer_memcpy_template { > > + dma_addr_t src_start; > > + dma_addr_t dst_start; > > + bool src_inc; > > + bool dst_inc; > > + bool src_sgl; > > + bool dst_sgl; > > + size_t numf; > > + size_t frame_size; > > + struct data_chunk sgl[0]; > > +}; > > + > > +struct dmaxfer_slave_template { > > + dma_addr_t mem; > > + bool mem_inc; > > + size_t numf; > > + size_t frame_size; > > + struct data_chunk sgl[0]; > > +}; > > > (1) Please tell how is dmaxfer_slave_template supposed to work on > bi-directional channels? > Keeping in mind, dma_slave_config.direction is marked to go away > in future. I didn't use dma_slave_config.direction. There is direction field in corresponding prepare function. > > (2) > * slave_template.mem <=> memcpy_template.src_start > * slave_template.mem_inc <=> memcpy_template.src_inc > > So essentially > memcpy_template := slave_template + src/dst_sgl + dst_start + dst_inc > > Even after this separation, there is nothing slave specific in > dmaxfer_slave_template. The slave client still needs DMA_SLAVE_CONFIG > to specify slave parameters of the transfer. > You only save a few bytes in a _copy_ of memcpy_template. Yes DMA_SLAVE_CONFIG is always required, this attempt was not aimed to remove that, but I would be interested in it :) -- ~Vinod