All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: Nicolin Chen
	<nicoleotsuka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org,
	ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org
Subject: Re: [PATCH v3 2/2] dmaengine: tegra210-adma: Add memcpy support
Date: Wed, 14 Sep 2016 19:08:55 +0530	[thread overview]
Message-ID: <20160914133855.GJ13920@localhost> (raw)
In-Reply-To: <0a0d5875-eb10-d98b-c26b-52fcb13b2be0-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

On Tue, Sep 13, 2016 at 09:52:43AM +0100, Jon Hunter wrote:
> 
> 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.

I think that is better, so am dropping this series.

-- 
~Vinod

WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vinod.koul@intel.com>
To: Jon Hunter <jonathanh@nvidia.com>
Cc: Nicolin Chen <nicoleotsuka@gmail.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
Subject: Re: [PATCH v3 2/2] dmaengine: tegra210-adma: Add memcpy support
Date: Wed, 14 Sep 2016 19:08:55 +0530	[thread overview]
Message-ID: <20160914133855.GJ13920@localhost> (raw)
In-Reply-To: <0a0d5875-eb10-d98b-c26b-52fcb13b2be0@nvidia.com>

On Tue, Sep 13, 2016 at 09:52:43AM +0100, Jon Hunter wrote:
> 
> 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.

I think that is better, so am dropping this series.

-- 
~Vinod

  parent reply	other threads:[~2016-09-14 13:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-06 18:42 [PATCH v3 0/2] Add memcpy support for tegra210-adma Nicolin Chen
     [not found] ` <cover.1473186743.git.nicoleotsuka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-09-06 18:42   ` [PATCH v3 1/2] dmaengine: tegra210-adma: Add pre-check for cyclic callback Nicolin Chen
2016-09-06 18:42     ` Nicolin Chen
2016-09-06 18:42   ` [PATCH v3 2/2] dmaengine: tegra210-adma: Add memcpy support Nicolin Chen
2016-09-06 18:42     ` Nicolin Chen
2016-09-08 14:08     ` Jon Hunter
2016-09-08 14:08       ` Jon Hunter
     [not found]       ` <bafb9b89-2b45-c419-62d4-b25a50f8d6be-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-09-08 14:19         ` Jon Hunter
2016-09-08 14:19           ` Jon Hunter
     [not found]           ` <37d4645c-6318-78bd-79bb-844fb6764a1b-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-09-08 17:31             ` Nicolin Chen
2016-09-08 17:31               ` Nicolin Chen
2016-09-12 14:34               ` Jon Hunter
2016-09-12 14:34                 ` Jon Hunter
2016-09-12 20:50                 ` Nicolin Chen
2016-09-13  8:52                   ` Jon Hunter
2016-09-13  8:52                     ` Jon Hunter
     [not found]                     ` <0a0d5875-eb10-d98b-c26b-52fcb13b2be0-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-09-14 13:38                       ` Vinod Koul [this message]
2016-09-14 13:38                         ` Vinod Koul

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160914133855.GJ13920@localhost \
    --to=vinod.koul-ral2jqcrhueavxtiumwx3w@public.gmane.org \
    --cc=dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=gnurou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=nicoleotsuka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.