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

Groups > linux.kernel > #1475514 > unrolled thread

[PATCH v2 0/2] Add memcpy support for tegra210-adma

Back to article view | Back to linux.kernel

Contents

  [PATCH v2 0/2] Add memcpy support for tegra210-adma Nicolin Chen <nicoleotsuka@gmail.com> - 2016-09-03 02:40 +0200
    [PATCH v2 1/2] dmaengine: tegra210-adma: Add pre-check for cyclic callback Nicolin Chen <nicoleotsuka@gmail.com> - 2016-09-03 02:40 +0200
    Re: [PATCH v2 0/2] Add memcpy support for tegra210-adma Jon Hunter <jonathanh@nvidia.com> - 2016-09-06 13:40 +0200
      Re: [PATCH v2 0/2] Add memcpy support for tegra210-adma Dmitry Osipenko <digetx@gmail.com> - 2016-09-06 14:10 +0200
        Re: [PATCH v2 0/2] Add memcpy support for tegra210-adma Jon Hunter <jonathanh@nvidia.com> - 2016-09-06 15:10 +0200
          Re: [PATCH v2 0/2] Add memcpy support for tegra210-adma Jon Hunter <jonathanh@nvidia.com> - 2016-09-06 15:50 +0200
            Re: [PATCH v2 0/2] Add memcpy support for tegra210-adma Dmitry Osipenko <digetx@gmail.com> - 2016-09-06 16:30 +0200

#1475514 — [PATCH v2 0/2] Add memcpy support for tegra210-adma

This series of patches add memcpy support for tegra210 ADMA engine.

Changlog
v1->v2 (Suggested by Vinod)
 * PATCH-1: Split the cyclic pre-check to a separate patch
 * PATCH-2: Add ADMA_CH_CTRL_MODE to unify the marcos
 * PATCH-2: Set operation mode depending on cyclic
 * PATCH-2: Add TODO comment at period_len
 * PATCH-2: Revise the commit log

Nicolin Chen (2):
  dmaengine: tegra210-adma: Add pre-check for cyclic callback
  dmaengine: tegra210-adma: Add memcpy support

 drivers/dma/tegra210-adma.c | 98 +++++++++++++++++++++++++++++++++++++++------
 1 file changed, 86 insertions(+), 12 deletions(-)

-- 
2.1.4

[toc] | [next] | [standalone]

#1475515 — [PATCH v2 1/2] dmaengine: tegra210-adma: Add pre-check for cyclic callback

ADMA driver will support more than cyclic type of transaction.
So this patch limits the cyclic callback for the cyclic type
only in order to support other types.

Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
---
 drivers/dma/tegra210-adma.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
index 09b46f7..5b5d298 100644
--- a/drivers/dma/tegra210-adma.c
+++ b/drivers/dma/tegra210-adma.c
@@ -111,6 +111,7 @@ struct tegra_adma_desc {
 	size_t				buf_len;
 	size_t				period_len;
 	size_t				num_periods;
+	bool				cyclic;
 };
 
 /*
@@ -408,7 +409,8 @@ static irqreturn_t tegra_adma_isr(int irq, void *dev_id)
 		return IRQ_NONE;
 	}
 
-	vchan_cyclic_callback(&tdc->desc->vd);
+	if (tdc->desc->cyclic)
+		vchan_cyclic_callback(&tdc->desc->vd);
 
 	spin_unlock_irqrestore(&tdc->vc.lock, flags);
 
@@ -557,6 +559,7 @@ static struct dma_async_tx_descriptor *tegra_adma_prep_dma_cyclic(
 	if (!desc)
 		return NULL;
 
+	desc->cyclic = true;
 	desc->buf_len = buf_len;
 	desc->period_len = period_len;
 	desc->num_periods = buf_len / period_len;
-- 
2.1.4

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

#1477291

On 03/09/16 01:32, Nicolin Chen wrote:
> This series of patches add memcpy support for tegra210 ADMA engine.

Thanks. Any reason you choose this DMA and not the APB DMA? The APB DMA
is more of a generic DMA and so for memcpy it would seem to be a good
choice and it is available on all Tegras not just Tegra210.

Furthermore, from a power standpoint the ADMA is in the audio power
domain and so using it for memcpy would mean the audio power domain is
turned on. It may not be a big deal for some, but given the APB is in
the CORE domain (always on when not in low-power) it seems like a better
choice for power as well.

Cheers
Jon

-- 
nvpublic

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

#1477303

On 06.09.2016 14:33, Jon Hunter wrote:
> 
> On 03/09/16 01:32, Nicolin Chen wrote:
>> This series of patches add memcpy support for tegra210 ADMA engine.
> 
> Thanks. Any reason you choose this DMA and not the APB DMA? The APB DMA
> is more of a generic DMA and so for memcpy it would seem to be a good
> choice and it is available on all Tegras not just Tegra210.
> 

Just a small clarification:

If I'm not mistaken, APB DMA is mem-to-device, while AHB DMA is mem-to-mem. So,
you probably meant AHB and not the APB.

> Furthermore, from a power standpoint the ADMA is in the audio power
> domain and so using it for memcpy would mean the audio power domain is
> turned on. It may not be a big deal for some, but given the APB is in
> the CORE domain (always on when not in low-power) it seems like a better
> choice for power as well.
> 

-- 
Dmitry

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

#1477354

On 06/09/16 13:03, Dmitry Osipenko wrote:
> On 06.09.2016 14:33, Jon Hunter wrote:
>>
>> On 03/09/16 01:32, Nicolin Chen wrote:
>>> This series of patches add memcpy support for tegra210 ADMA engine.
>>
>> Thanks. Any reason you choose this DMA and not the APB DMA? The APB DMA
>> is more of a generic DMA and so for memcpy it would seem to be a good
>> choice and it is available on all Tegras not just Tegra210.
>>
> 
> Just a small clarification:
> 
> If I'm not mistaken, APB DMA is mem-to-device, while AHB DMA is mem-to-mem. So,
> you probably meant AHB and not the APB.

Description from the Tegra TRM:

"The APB DMA Controller is placed between the AHB Bus and the APB Bus
and is a master on both buses.

The APB DMA Controller is used for block data transfers from a source
location to the destination location. The source may be
DRAM or IRAM, and the destination location could be devices placed on
APB Bus; or vice versa."

Cheers
Jon

-- 
nvpublic

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

#1477400

On 06/09/16 14:04, Jon Hunter wrote:
> 
> On 06/09/16 13:03, Dmitry Osipenko wrote:
>> On 06.09.2016 14:33, Jon Hunter wrote:
>>>
>>> On 03/09/16 01:32, Nicolin Chen wrote:
>>>> This series of patches add memcpy support for tegra210 ADMA engine.
>>>
>>> Thanks. Any reason you choose this DMA and not the APB DMA? The APB DMA
>>> is more of a generic DMA and so for memcpy it would seem to be a good
>>> choice and it is available on all Tegras not just Tegra210.
>>>
>>
>> Just a small clarification:
>>
>> If I'm not mistaken, APB DMA is mem-to-device, while AHB DMA is mem-to-mem. So,
>> you probably meant AHB and not the APB.
> 
> Description from the Tegra TRM:
> 
> "The APB DMA Controller is placed between the AHB Bus and the APB Bus
> and is a master on both buses.
> 
> The APB DMA Controller is used for block data transfers from a source
> location to the destination location. The source may be
> DRAM or IRAM, and the destination location could be devices placed on
> APB Bus; or vice versa."

Sorry this appears to be a completely worthless response :-(

I had made the assumption that if the DMA can transfer from APB-to-AHB
and AHB-to-APB, it could also do AHB to AHB. However, now I look closely
at the registers I see that it cannot and therefore, cannot support
memcpy at all! Ok, so ignore my comment here, as it appears only the
ADMA can support memcpy. Weird.

Jon

-- 
nvpublic

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

#1477460

On 06.09.2016 16:46, Jon Hunter wrote:
> 
> On 06/09/16 14:04, Jon Hunter wrote:
>>
>> On 06/09/16 13:03, Dmitry Osipenko wrote:
>>> On 06.09.2016 14:33, Jon Hunter wrote:
>>>>
>>>> On 03/09/16 01:32, Nicolin Chen wrote:
>>>>> This series of patches add memcpy support for tegra210 ADMA engine.
>>>>
>>>> Thanks. Any reason you choose this DMA and not the APB DMA? The APB DMA
>>>> is more of a generic DMA and so for memcpy it would seem to be a good
>>>> choice and it is available on all Tegras not just Tegra210.
>>>>
>>>
>>> Just a small clarification:
>>>
>>> If I'm not mistaken, APB DMA is mem-to-device, while AHB DMA is mem-to-mem. So,
>>> you probably meant AHB and not the APB.
>>
>> Description from the Tegra TRM:
>>
>> "The APB DMA Controller is placed between the AHB Bus and the APB Bus
>> and is a master on both buses.
>>
>> The APB DMA Controller is used for block data transfers from a source
>> location to the destination location. The source may be
>> DRAM or IRAM, and the destination location could be devices placed on
>> APB Bus; or vice versa."
> 
> Sorry this appears to be a completely worthless response :-(
> 
> I had made the assumption that if the DMA can transfer from APB-to-AHB
> and AHB-to-APB, it could also do AHB to AHB. However, now I look closely
> at the registers I see that it cannot and therefore, cannot support
> memcpy at all! Ok, so ignore my comment here, as it appears only the
> ADMA can support memcpy. Weird.
> 

On older Tegra's there is AHB DMA controller for mem-to-mem transfers. The K1
manual states that it's been deprecated, however there is an interrupt dedicated
to it (probably wrong TRM?). X1 TRM also states the deprecation, doesn't have
the interrupt mention that K1 has and has ADMA.

-- 
Dmitry

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web