Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758958AbbFBMr7 (ORCPT ); Tue, 2 Jun 2015 08:47:59 -0400 Received: from mga01.intel.com ([192.55.52.88]:33495 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752948AbbFBMru (ORCPT ); Tue, 2 Jun 2015 08:47:50 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,539,1427785200"; d="scan'208";a="719301249" Date: Tue, 2 Jun 2015 18:19:03 +0530 From: Vinod Koul To: Andy Shevchenko Cc: Andy Shevchenko , "Rafael J. Wysocki" , "linux-acpi@vger.kernel.org" , "linux-pm@vger.kernel.org" , Greg Kroah-Hartman , Lee Jones , Andrew Morton , Mika Westerberg , "linux-kernel@vger.kernel.org" , dmaengine , Heikki Krogerus , Jarkko Nikula Subject: Re: [PATCH v2 7/8] dmaengine: add a driver for Intel integrated DMA 64-bit Message-ID: <20150602124903.GR3140@localhost> References: <1432570172-86963-1-git-send-email-andriy.shevchenko@linux.intel.com> <1432570172-86963-8-git-send-email-andriy.shevchenko@linux.intel.com> <20150526040651.GP3140@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2238 Lines: 49 On Tue, May 26, 2015 at 09:49:57AM +0300, Andy Shevchenko wrote: > On Tue, May 26, 2015 at 7:06 AM, Vinod Koul wrote: > > On Mon, May 25, 2015 at 07:09:31PM +0300, Andy Shevchenko wrote: > >> Intel integrated DMA (iDMA) 64-bit is a specific IP that is used as a part of > >> LPSS devices such as HSUART or SPI. The iDMA IP is attached for private > >> usage on each host controller independently. > >> > >> While it has similarities with Synopsys DesignWare DMA, the following > >> distinctions doesn't allow to use the existing driver: > >> - 64-bit mode with corresponding changes in Hardware Linked List data structure > >> - many slight differences in the channel registers > >> > >> Moreover this driver is based on the DMA virtual channels framework that helps > >> to make the driver cleaner and easy to understand. > >> > > Looking at code and iDMA controllers (if this is the same as I have used), we > > have register compatibility with DW controller, so why new driver and why not > > use and enhance dw driver ? > > Take a look closer. There are many, like I mentioned, slight but not > least changes in the registers, besides *64-bit mode*: > - ctl_hi represents bytes, not items > - 2 bytes of burst is supported (dw has no gap there) > - shuffling bits between ctl_* and cfg_* > - new bits with different meaning in ctl_* and cfg_*. Yes these are the changes which I was thinking and these would impact only calculating different values for a descriptor, so based on device probed you cna load a specfic operation for calculating, rest of the driver code is agnostic > > Preliminary we did a patchset for dw_dmac, but above hw changes blows > up and messes the driver code. I really would prefer to have those two > separate I think it should be doable and reading this patch also doesnt convince me for that > > However, the 32-bit iDMA which is used in Baytrail might be driven by dw_dmac. Also what part here is specfic to *64* bit ? -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/