From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760058Ab1JGO0x (ORCPT ); Fri, 7 Oct 2011 10:26:53 -0400 Received: from mga14.intel.com ([143.182.124.37]:6439 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752664Ab1JGO0w (ORCPT ); Fri, 7 Oct 2011 10:26:52 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.68,502,1312182000"; d="scan'208";a="24179156" 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> Content-Type: text/plain; charset="UTF-8" Date: Fri, 07 Oct 2011 19:49:37 +0530 Message-ID: <1317997177.1573.2275.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 Fri, 2011-10-07 at 16:57 +0530, Jassi Brar wrote: > On 7 October 2011 11:15, Vinod Koul wrote: > > > Thru this patch Jassi gave a very good try at merging DMA_SLAVE and > > memcpy, but more we debate this, I am still not convinced about merging > > memcpy and DMA_SLAVE yet. > > > Nobody is merging memcpy and DMA_SLAVE right away. > The api's primary purpose is to support interleave transfers. > Possibility to merge other prepares into this is a side-effect. For interleaved isn't that what you are trying? > > > I would still argue that if we split this on same lines as current > > mechanism, we have clean way to convey all details for both cases. > > > Do you mean to have separate interleaved transfer apis for Slave > and Mem->Mem ? Please clarify. If we can make API cleaner and well defined that way then Yes :) -- ~Vinod