From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756917AbcIMIww (ORCPT ); Tue, 13 Sep 2016 04:52:52 -0400 Received: from hqemgate16.nvidia.com ([216.228.121.65]:3530 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756270AbcIMIwu (ORCPT ); Tue, 13 Sep 2016 04:52:50 -0400 X-PGP-Universal: processed; by hqnvupgp08.nvidia.com on Tue, 13 Sep 2016 01:47:35 -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> <20160912205017.GA12187@Asurada-Nvidia> CC: , , , , , , , From: Jon Hunter Message-ID: <0a0d5875-eb10-d98b-c26b-52fcb13b2be0@nvidia.com> Date: Tue, 13 Sep 2016 09:52:43 +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: <20160912205017.GA12187@Asurada-Nvidia> X-Originating-IP: [10.21.132.115] X-ClientProxiedBy: UKMAIL102.nvidia.com (10.26.138.15) 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 12/09/16 21:50, Nicolin Chen wrote: > On Mon, Sep 12, 2016 at 03:34:08PM +0100, Jon Hunter wrote: > >>> 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 > >>> 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. > > I may also take a look to speed it up. Yet, putting that clock > aside, how about this patch then? I think we don't need to wait > for that clock patch in order to announce that we support this > now on a specific SoC but can just treat it as a new feature of > a DMA controller, which sounds quite plausible to me since the > ADMA module is now being disabled in all dts files of existing > SoCs -- There have to be some local changes in any way so as to > test it with the mainline code. I am fine with the changes. However, I am wondering if we should sort out this clock business first just in case someone tries to use this. Cheers Jon -- nvpublic