From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754865Ab1JKP5T (ORCPT ); Tue, 11 Oct 2011 11:57:19 -0400 Received: from mail-ww0-f44.google.com ([74.125.82.44]:52906 "EHLO mail-ww0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753874Ab1JKP5R convert rfc822-to-8bit (ORCPT ); Tue, 11 Oct 2011 11:57:17 -0400 MIME-Version: 1.0 In-Reply-To: <1318334185.1546.344.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> <1318334185.1546.344.camel@vkoul-udesk3> Date: Tue, 11 Oct 2011 21:27:16 +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 11 October 2011 17:26, 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. > > If the conversion id done for all drivers, then it should be fine... > I already said that many days ago. Though I am not sure what blocks this patch if that conversion is done separately (which would touch many subsystems).