From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Hunter Subject: Re: [PATCH v3 2/2] dmaengine: tegra210-adma: Add memcpy support Date: Mon, 12 Sep 2016 15:34:08 +0100 Message-ID: References: <37d4645c-6318-78bd-79bb-844fb6764a1b@nvidia.com> <20160908173141.GA28381@Asurada-Nvidia> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160908173141.GA28381@Asurada-Nvidia> Sender: linux-kernel-owner@vger.kernel.org To: Nicolin Chen Cc: vinod.koul@intel.com, linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org, dmaengine@vger.kernel.org, gnurou@gmail.com, thierry.reding@gmail.com, swarren@wwwdotorg.org, ldewangan@nvidia.com List-Id: linux-tegra@vger.kernel.org On 08/09/16 18:31, Nicolin Chen wrote: > On Thu, Sep 08, 2016 at 03:19:57PM +0100, Jon Hunter wrote: > >> I tried this again on my audio testing branch for tegra210 and it worked ... >> >> [ 36.427210] dmatest: Started 1 threads using dma1chan0 >> [ 37.036948] dmatest: dma1chan0-copy0: summary 1024 tests, 0 failures 2410 iops 19419 KB/s (0) >> >> Do you have other patches in your branch? If so it would be good to >> understand the dependency. May be we are missing a clock somewhere? > > Sorry. I forgot to mention that the TEGRA210_CLK_APE_SLCG_OVR > clock is required for the tests. So I cherry-picked 2 patches > from your audio branch to the linux-next: > clk: tegra210: Add SLCG override gate clocks > ARM64: tegra: DT: Add SLCG clock for AUD > > Besides these two, there'e merely some straightforward changes > to enable the ADMA in the defconfig and DT. > > And it seems that you've submitted that patch once but it got > hold because it wasn't so useful at that time? Yes it was not being used at the time. It is on my list of things to do and we need to revisit it. There was some discussion on the best way to handle these clocks from a client perspective. I am not sure we came to a conclusion on this. I need to find some time to look at this. Jon -- nvpublic From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759189AbcILOeX (ORCPT ); Mon, 12 Sep 2016 10:34:23 -0400 Received: from hqemgate15.nvidia.com ([216.228.121.64]:5664 "EHLO hqemgate15.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758050AbcILOeV (ORCPT ); Mon, 12 Sep 2016 10:34:21 -0400 X-PGP-Universal: processed; by hqnvupgp08.nvidia.com on Mon, 12 Sep 2016 07:29:08 -0700 Subject: Re: [PATCH v3 2/2] dmaengine: tegra210-adma: Add memcpy support To: Nicolin Chen References: <37d4645c-6318-78bd-79bb-844fb6764a1b@nvidia.com> <20160908173141.GA28381@Asurada-Nvidia> CC: , , , , , , , From: Jon Hunter Message-ID: Date: Mon, 12 Sep 2016 15:34:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160908173141.GA28381@Asurada-Nvidia> X-Originating-IP: [10.21.132.115] X-ClientProxiedBy: DRUKMAIL101.nvidia.com (10.25.59.19) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/09/16 18:31, Nicolin Chen wrote: > On Thu, Sep 08, 2016 at 03:19:57PM +0100, Jon Hunter wrote: > >> I tried this again on my audio testing branch for tegra210 and it worked ... >> >> [ 36.427210] dmatest: Started 1 threads using dma1chan0 >> [ 37.036948] dmatest: dma1chan0-copy0: summary 1024 tests, 0 failures 2410 iops 19419 KB/s (0) >> >> Do you have other patches in your branch? If so it would be good to >> understand the dependency. May be we are missing a clock somewhere? > > Sorry. I forgot to mention that the TEGRA210_CLK_APE_SLCG_OVR > clock is required for the tests. So I cherry-picked 2 patches > from your audio branch to the linux-next: > clk: tegra210: Add SLCG override gate clocks > ARM64: tegra: DT: Add SLCG clock for AUD > > Besides these two, there'e merely some straightforward changes > to enable the ADMA in the defconfig and DT. > > And it seems that you've submitted that patch once but it got > hold because it wasn't so useful at that time? Yes it was not being used at the time. It is on my list of things to do and we need to revisit it. There was some discussion on the best way to handle these clocks from a client perspective. I am not sure we came to a conclusion on this. I need to find some time to look at this. Jon -- nvpublic