From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752931Ab1JJQgS (ORCPT ); Mon, 10 Oct 2011 12:36:18 -0400 Received: from mail-yw0-f46.google.com ([209.85.213.46]:55654 "EHLO mail-yw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751776Ab1JJQgR convert rfc822-to-8bit (ORCPT ); Mon, 10 Oct 2011 12:36:17 -0400 MIME-Version: 1.0 In-Reply-To: <1318262559.1546.31.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> <1318243501.1546.12.camel@vkoul-udesk3> <1318262559.1546.31.camel@vkoul-udesk3> Date: Mon, 10 Oct 2011 21:58:43 +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 21:32, Vinod Koul wrote: > On Mon, 2011-10-10 at 16:46 +0530, Jassi Brar wrote: >> On 10 October 2011 16:15, Vinod Koul wrote: >> > >> > But I am fine if we find a common ground and merge the two where dmac >> > can cleanly identify direction and mode it is operating. >> > >> The client would set the xfer_direction and dmac would interpret as >> >> enum xfer_direction { >>      MEM_TO_MEM,   ->  Async/Memcpy mode >>      MEM_TO_DEV,    ->  Slave mode & From Memory to Device >>      DEV_TO_MEM,    ->  Slave mode & From Device to Memory >>      DEV_TO_DEV,     ->  Slave mode & From Device to Device >> } >> >> How could it get any cleaner? > Consider the case of a dmac driver which supports interleaved dma as > well as memcpy and slave > It needs to interpret dma_data_direction for later cases and > xfer_direction for former ones. dma_data_direction is the mapping attribute of a buffer and is not meant to tell type of source and destination of a transfer. xfer_direction is meant for that purpose. So I'd rather convert device_prep_dma_cyclic and device_prep_slave_sg to use xfer_direction.