From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752098AbbLUUye (ORCPT ); Mon, 21 Dec 2015 15:54:34 -0500 Received: from mga04.intel.com ([192.55.52.120]:32187 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751424AbbLUUyc (ORCPT ); Mon, 21 Dec 2015 15:54:32 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,461,1444719600"; d="scan'208";a="866647378" Message-ID: <1450731289.30729.282.camel@linux.intel.com> Subject: Re: [PATCH 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel From: Andy Shevchenko To: =?ISO-8859-1?Q?M=E5ns_Rullg=E5rd?= Cc: Andy Shevchenko , Julian Margetson , Tejun Heo , linux-ide@vger.kernel.org, "linux-kernel@vger.kernel.org" Date: Mon, 21 Dec 2015 22:54:49 +0200 In-Reply-To: References: <1450221935-6034-1-git-send-email-mans@mansr.com> <567541EE.9010308@candw.ms> <56758F33.20804@candw.ms> <5675A84F.2070208@candw.ms> <5675BB2F.6060107@candw.ms> <5675C452.2080206@candw.ms> <5676E906.1060603@candw.ms> <1450724880.30729.250.camel@linux.intel.com> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.2-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2015-12-21 at 19:27 +0000, Måns Rullgård wrote: > Andy Shevchenko writes: > > > On Mon, 2015-12-21 at 01:19 +0000, Måns Rullgård wrote: > > > Andy Shevchenko writes: > > >   > > > > P.S. I also noticed that original driver enables interrupt per > > > > each > > > > block > > > > > > And then ignores all but the transfer complete interrupt. > > > > > > > and sets protection control bits. > > > > > > With no indication what the value it sets is supposed to mean. > > > > Okay, let's summarize what we have: > > > > 0. AR: Get a working reference for PPC 460EX SATA driver > > Do we consider Julian's latest result working? I think so. > > > 1. AR: Clear LLP_EN bits at the last block of LLP transfer > > Patch sent. Acked. > > > 2. AR: Rename masters to 'memory' and 'peripheral' and change them > > per > > DMA direction > > Good idea.  I'd call them memory and device though to match existing > dmaengine nomenclature. I remember how I called in my patch. So, there is no problem to rename, but will see. > > > 3. AR: Set LMS (LLP master) to 'memory' when do LLP transfers > > I started working on a patch for that already. Thanks. > > > 4. CHECK: PROTCTL bit (documentation says that recommended value is > > 0x01) > > Any idea what the value of 0x3 used by the old sata driver means? > Presumably that's decided by the bus. Nope, documentation says that it is direct representation of hprot[3:1] wires on the master interface. Also it refers to AMBA spec, so, if you have access to AMBA spec I think we might get it from there. > > > 5. CHECK: Other bits in CFG register (FIFO_MODE, FCMODE) > > 6. CHECK: Block interrupts vs. one interrupt at the end of block > > chain > > (Måns, I missed how any of them is ignored) > > The interrupt handler looks at the StatusTfr and StatusErr registers > and > ignores StatusBlock. I have to refresh my memory, since BLOCK interrupts should be enabled (unmasked) separately. I have forgotten which type of interrupt is generated in this case, BLOCK, or XFER after each block, or only one XFER at the last block (LLP.LOC = 0) and BLOCK are ignored. So, will check later. > > > 7. AR: Test everything on Intel SoCs such as Baytrail, CherryTrail, > > etc > > (SPI, UART, dmatest), AVR32 (MMC, dmatest), PPC 460EX (Onboard > > SATA) > > I can test on AVR32.  That is as far as I know the only system I have > with this DMA engine. If you have Intel Haswell, BayTrail, Braswell, CherryTrail, Broadwell, you have it as well as long you have LPSS block there. (Most of them are Atoms). > > > I can share my working branch with a set of patches regarding to > > dw_dmac. We may do our work based on that code and after I'll > > submit > > everything to upstream. Does it sound okay for you, guys? > > I'm going away for the holidays, so I won't be able to do any serious > work on this until January, but I'll keep an eye on emails and may > even > reply occasionally.  Before I go, I'll publish my patches so far > whatever shape they're in. Okay, thanks! I will include them in my branch which I'm going to publish on GitHUB. Happy holidays! -- Andy Shevchenko Intel Finland Oy