From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938383AbcHJSpa (ORCPT ); Wed, 10 Aug 2016 14:45:30 -0400 Received: from mga01.intel.com ([192.55.52.88]:40345 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935856AbcHJSpZ (ORCPT ); Wed, 10 Aug 2016 14:45:25 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,499,1464678000"; d="scan'208";a="1033102433" Message-ID: <1470831336.4887.22.camel@linux.intel.com> Subject: Re: dmatest no longer works on ARC SDP with DW DMAC From: Andy Shevchenko To: Eugeniy Paltsev , "dmaengine@vger.kernel.org" Cc: "vinod.koul@intel.com" , "linux-kernel@vger.kernel.org" , Vlad Zakharov , "linux-snps-arc@lists.infradead.org" , Alexey Brodkin , Nelson Pereira , "viresh.kumar@linaro.org" Date: Wed, 10 Aug 2016 15:15:36 +0300 In-Reply-To: <1470827209.21247.12.camel@synopsys.com> References: <1470827209.21247.12.camel@synopsys.com> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.4-1+b1 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 Wed, 2016-08-10 at 11:06 +0000, Eugeniy Paltsev wrote: > dmatest on ARC SDP with DW DMAC became broken after df5c7386 > ("dmaengine: dw: some Intel devices has no memcpy support") and > 30cb2639 ("dmaengine: dw: don't override platform data with autocfg") > commits. > * After df5c7386 commit "DMA_MEMCPY" capability option doesn't > get set correctly in platform driver version. > * After 30cb2639 commit > "data_width" and "nollp" parameters don't get set correctly in > platform > driver version. > > This happens because in old driver version there are three sources  > of parameters: pdata, device tree and autoconfig hardware registers.  > Some parameters were read from pdata and others from autoconfig > hardware registers. If pdata was absent some pdata structure  > fields were filled with parameters from device tree. But 30cb2639 > commit disabled overriding pdata with autocfg, so if we use platform > driver version without pdata some parameters will not be set. Yes, that's correct behaviour right now. You have to provide platform code which registers device with all platform data provided. > I'm wondering what would be the best way to fix this situation? Ideally we have to switch to use built-in device properties (drivers/base/property.c) and platform code in your case has to provide properties. > Should we strictly read parameters from only one source (pdata/device > tree/autoconfig) or we may mix some of them (for example getting > missing data from autoconf regs)? See above. -- Andy Shevchenko Intel Finland Oy