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: Tue, 13 Sep 2016 09:52:43 +0100 Message-ID: <0a0d5875-eb10-d98b-c26b-52fcb13b2be0@nvidia.com> References: <37d4645c-6318-78bd-79bb-844fb6764a1b@nvidia.com> <20160908173141.GA28381@Asurada-Nvidia> <20160912205017.GA12187@Asurada-Nvidia> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20160912205017.GA12187@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 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