All of lore.kernel.org
 help / color / mirror / Atom feed
From: nsekhar@ti.com (Sekhar Nori)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/6] ARM: DTS: da850: Use the new DT bindings for the eDMA3
Date: Tue, 15 Dec 2015 20:50:35 +0530	[thread overview]
Message-ID: <56702FC3.5050705@ti.com> (raw)
In-Reply-To: <56701E2C.7060308@ti.com>

On Tuesday 15 December 2015 07:35 PM, Peter Ujfalusi wrote:
> On 12/15/2015 03:48 PM, Sekhar Nori wrote:

>>>> In future, if/when we gain QDMA support, the QDMA channels could be used
>>>> for memcopy.
>>>
>>> Well, in short there is no way to get the qDMA working in a different way
>>> either. qDMA channel is in essence using 'normal' eDMA channel. This means
>>> that we still need to reserve the eDMA channel to be used for memcpy, but
>>> instead of SW triggering it (as we do it right now), we would need to use the
>>> channel as qDMA and set things up accordingly. I don't really see the benefit
>>> for qDMA mode to be honest.
>>
>> I guess the only advantage is that they will not clash with peripheral
>> mode usage. But even then, some sort of reservation is needed. So I
>> guess QDMA is no better than the EDMA reserved channels?
> 
> It will clash with the peripheral mode use since it needs to take one of the
> eDMA channels. qDMA mode is basically differs from the mode we are using by
> how the channel is triggered. Currently we start the memcpy with SW trigger.

Alright, so I was missing this detail. Thanks for clarifying it on IRC.
The EDMA specification makes it look like 8 additional QDMA channels can
be used over 32 DMA channels, but in reality they are not additional
channels since TCC is only valid between 0-31.

So, I agree. QDMA does not buy us any parallel transfers.

Thanks,
Sekhar

WARNING: multiple messages have this Message-ID (diff)
From: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
To: Peter Ujfalusi <peter.ujfalusi-l0cyMroinI0@public.gmane.org>
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	khilman-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org
Subject: Re: [PATCH 2/6] ARM: DTS: da850: Use the new DT bindings for the eDMA3
Date: Tue, 15 Dec 2015 20:50:35 +0530	[thread overview]
Message-ID: <56702FC3.5050705@ti.com> (raw)
In-Reply-To: <56701E2C.7060308-l0cyMroinI0@public.gmane.org>

On Tuesday 15 December 2015 07:35 PM, Peter Ujfalusi wrote:
> On 12/15/2015 03:48 PM, Sekhar Nori wrote:

>>>> In future, if/when we gain QDMA support, the QDMA channels could be used
>>>> for memcopy.
>>>
>>> Well, in short there is no way to get the qDMA working in a different way
>>> either. qDMA channel is in essence using 'normal' eDMA channel. This means
>>> that we still need to reserve the eDMA channel to be used for memcpy, but
>>> instead of SW triggering it (as we do it right now), we would need to use the
>>> channel as qDMA and set things up accordingly. I don't really see the benefit
>>> for qDMA mode to be honest.
>>
>> I guess the only advantage is that they will not clash with peripheral
>> mode usage. But even then, some sort of reservation is needed. So I
>> guess QDMA is no better than the EDMA reserved channels?
> 
> It will clash with the peripheral mode use since it needs to take one of the
> eDMA channels. qDMA mode is basically differs from the mode we are using by
> how the channel is triggered. Currently we start the memcpy with SW trigger.

Alright, so I was missing this detail. Thanks for clarifying it on IRC.
The EDMA specification makes it look like 8 additional QDMA channels can
be used over 32 DMA channels, but in reality they are not additional
channels since TCC is only valid between 0-31.

So, I agree. QDMA does not buy us any parallel transfers.

Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Sekhar Nori <nsekhar@ti.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: <linux-arm-kernel@lists.infradead.org>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<khilman@deeprootsystems.com>
Subject: Re: [PATCH 2/6] ARM: DTS: da850: Use the new DT bindings for the eDMA3
Date: Tue, 15 Dec 2015 20:50:35 +0530	[thread overview]
Message-ID: <56702FC3.5050705@ti.com> (raw)
In-Reply-To: <56701E2C.7060308@ti.com>

On Tuesday 15 December 2015 07:35 PM, Peter Ujfalusi wrote:
> On 12/15/2015 03:48 PM, Sekhar Nori wrote:

>>>> In future, if/when we gain QDMA support, the QDMA channels could be used
>>>> for memcopy.
>>>
>>> Well, in short there is no way to get the qDMA working in a different way
>>> either. qDMA channel is in essence using 'normal' eDMA channel. This means
>>> that we still need to reserve the eDMA channel to be used for memcpy, but
>>> instead of SW triggering it (as we do it right now), we would need to use the
>>> channel as qDMA and set things up accordingly. I don't really see the benefit
>>> for qDMA mode to be honest.
>>
>> I guess the only advantage is that they will not clash with peripheral
>> mode usage. But even then, some sort of reservation is needed. So I
>> guess QDMA is no better than the EDMA reserved channels?
> 
> It will clash with the peripheral mode use since it needs to take one of the
> eDMA channels. qDMA mode is basically differs from the mode we are using by
> how the channel is triggered. Currently we start the memcpy with SW trigger.

Alright, so I was missing this detail. Thanks for clarifying it on IRC.
The EDMA specification makes it look like 8 additional QDMA channels can
be used over 32 DMA channels, but in reality they are not additional
channels since TCC is only valid between 0-31.

So, I agree. QDMA does not buy us any parallel transfers.

Thanks,
Sekhar

  reply	other threads:[~2015-12-15 15:20 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-04 13:53 [PATCH 0/6] ARM: DTS: da850: eDMA new bindings and MMC/SPI DMA support Peter Ujfalusi
2015-12-04 13:53 ` Peter Ujfalusi
2015-12-04 13:53 ` Peter Ujfalusi
2015-12-04 13:53 ` [PATCH 1/6] ARM: DTS: da850: fix edma0 reg space Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-04 13:53 ` [PATCH 2/6] ARM: DTS: da850: Use the new DT bindings for the eDMA3 Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-15  9:38   ` Sekhar Nori
2015-12-15  9:38     ` Sekhar Nori
2015-12-15  9:38     ` Sekhar Nori
2015-12-15 11:44     ` Peter Ujfalusi
2015-12-15 11:44       ` Peter Ujfalusi
2015-12-15 11:44       ` Peter Ujfalusi
2015-12-15 13:48       ` Sekhar Nori
2015-12-15 13:48         ` Sekhar Nori
2015-12-15 13:48         ` Sekhar Nori
2015-12-15 14:05         ` Peter Ujfalusi
2015-12-15 14:05           ` Peter Ujfalusi
2015-12-15 14:05           ` Peter Ujfalusi
2015-12-15 15:20           ` Sekhar Nori [this message]
2015-12-15 15:20             ` Sekhar Nori
2015-12-15 15:20             ` Sekhar Nori
2015-12-04 13:53 ` [PATCH 3/6] ARM: DTS: da850: Enable eDMA1 Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-04 13:53 ` [PATCH 4/6] ARM: DTS: da850: Enable DMA use for MMC0 Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-04 13:53 ` [PATCH 5/6] ARM: DTS: da850: Add node for mmc1 Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-04 13:53 ` [PATCH 6/6] ARM: DTS: da850: Enable DMA for SPI1 Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-04 13:53   ` Peter Ujfalusi
2015-12-09  7:19 ` [PATCH 0/6] ARM: DTS: da850: eDMA new bindings and MMC/SPI DMA support Peter Ujfalusi
2015-12-09  7:19   ` Peter Ujfalusi
2015-12-09  7:19   ` Peter Ujfalusi
2015-12-09  7:52   ` Sekhar Nori
2015-12-09  7:52     ` Sekhar Nori
2015-12-09  7:52     ` Sekhar Nori
2015-12-10 12:20 ` Sushaanth Srirangapathi
2015-12-10 12:20   ` Sushaanth Srirangapathi
2015-12-10 12:20   ` Sushaanth Srirangapathi

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=56702FC3.5050705@ti.com \
    --to=nsekhar@ti.com \
    --cc=linux-arm-kernel@lists.infradead.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.