Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1481360 > unrolled thread

Re: [PATCH v3 2/2] dmaengine: tegra210-adma: Add memcpy support

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v3 2/2] dmaengine: tegra210-adma: Add memcpy support Jon Hunter <jonathanh@nvidia.com> - 2016-09-12 16:40 +0200
    Re: [PATCH v3 2/2] dmaengine: tegra210-adma: Add memcpy support Nicolin Chen <nicoleotsuka@gmail.com> - 2016-09-12 23:00 +0200
      Re: [PATCH v3 2/2] dmaengine: tegra210-adma: Add memcpy support Jon Hunter <jonathanh@nvidia.com> - 2016-09-13 11:00 +0200
        Re: [PATCH v3 2/2] dmaengine: tegra210-adma: Add memcpy support Vinod Koul <vinod.koul@intel.com> - 2016-09-14 15:40 +0200

#1481360 — Re: [PATCH v3 2/2] dmaengine: tegra210-adma: Add memcpy support

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

[toc] | [next] | [standalone]

#1481963

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.

Thanks
Nic

[toc] | [prev] | [next] | [standalone]

#1482272

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

[toc] | [prev] | [next] | [standalone]

#1483306

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web