From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753290Ab1JJJxu (ORCPT ); Mon, 10 Oct 2011 05:53:50 -0400 Received: from mail-wy0-f174.google.com ([74.125.82.174]:65367 "EHLO mail-wy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753097Ab1JJJxt convert rfc822-to-8bit (ORCPT ); Mon, 10 Oct 2011 05:53:49 -0400 MIME-Version: 1.0 In-Reply-To: <1318238296.1546.3.camel@vkoul-udesk3> 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> <1318238296.1546.3.camel@vkoul-udesk3> Date: Mon, 10 Oct 2011 15:23:46 +0530 Message-ID: Subject: Re: [PATCHv4] DMAEngine: Define interleaved transfer request api From: Jassi Brar To: Vinod Koul Cc: "Williams, Dan J" , Russell King , Barry Song <21cnbao@gmail.com>, linux-kernel@vger.kernel.org, DL-SHA-WorkGroupLinux , Dave Jiang Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10 October 2011 14:48, Vinod Koul wrote: > 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. > ok but why not reduce 1 argument from api and embed that as the transfer's property in dmaxfer_slave_template, as I did ? >> >> (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 :) > Sorry then I don't see this "ambiguity"(if there really is any) removal worth adding an extra prepare when we already have 10 of them.