From mboxrd@z Thu Jan 1 00:00:00 1970 From: andriy.shevchenko@linux.intel.com (Andy Shevchenko) Date: Wed, 10 Aug 2016 15:46:15 +0300 Subject: dmatest no longer works on ARC SDP with DW DMAC In-Reply-To: <1470831659.3428.23.camel@synopsys.com> References: <1470827209.21247.12.camel@synopsys.com> <1470831336.4887.22.camel@linux.intel.com> <1470831659.3428.23.camel@synopsys.com> List-ID: Message-ID: <1470833175.4887.35.camel@linux.intel.com> To: linux-snps-arc@lists.infradead.org On Wed, 2016-08-10@12:22 +0000, Alexey Brodkin wrote: > Hi Andy, > > On Wed, 2016-08-10@15:15 +0300, Andy Shevchenko wrote: > > > > On Wed, 2016-08-10@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. > > But given autocfg registers exist in HW why don't we rely on their > contents? And how exactly we can get that mem2mem support is absent / broken by some reason? All those quirks (bool is_*) kinda semi-hardware related. What we can do is to have two categories of properties: a) genuine hardware properties, and b) quirks. So, refactor the ->probe() function in a way that will still copy quirks and other non-hardware properties from platform data, if provided, to the driver internals. > > > > > > > > > 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. > > What do you mean saying "built-in device properties"? > Setting pdata structure? In our particular case we use device tree > for DW DMAC setup. Providing device properties instead of platform data. Again see above. -- Andy Shevchenko Intel Finland Oy From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933895AbcHJUj5 (ORCPT ); Wed, 10 Aug 2016 16:39:57 -0400 Received: from mga14.intel.com ([192.55.52.115]:31200 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750828AbcHJSOm (ORCPT ); Wed, 10 Aug 2016 14:14:42 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,499,1464678000"; d="scan'208";a="153616509" Message-ID: <1470833175.4887.35.camel@linux.intel.com> Subject: Re: dmatest no longer works on ARC SDP with DW DMAC From: Andy Shevchenko To: Alexey Brodkin Cc: "vinod.koul@intel.com" , "linux-kernel@vger.kernel.org" , "Eugeniy.Paltsev@synopsys.com" , "Nelson.Pereira@synopsys.com" , "linux-snps-arc@lists.infradead.org" , "viresh.kumar@linaro.org" , "dmaengine@vger.kernel.org" Date: Wed, 10 Aug 2016 15:46:15 +0300 In-Reply-To: <1470831659.3428.23.camel@synopsys.com> References: <1470827209.21247.12.camel@synopsys.com> <1470831336.4887.22.camel@linux.intel.com> <1470831659.3428.23.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 12:22 +0000, Alexey Brodkin wrote: > Hi Andy, > > On Wed, 2016-08-10 at 15:15 +0300, Andy Shevchenko wrote: > > > > 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. > > But given autocfg registers exist in HW why don't we rely on their > contents? And how exactly we can get that mem2mem support is absent / broken by some reason? All those quirks (bool is_*) kinda semi-hardware related. What we can do is to have two categories of properties: a) genuine hardware properties, and b) quirks. So, refactor the ->probe() function in a way that will still copy quirks and other non-hardware properties from platform data, if provided, to the driver internals. > > > > > > > > > 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. > > What do you mean saying "built-in device properties"? > Setting pdata structure? In our particular case we use device tree > for DW DMAC setup. Providing device properties instead of platform data. Again see above. -- Andy Shevchenko Intel Finland Oy