From: zhangfei.gao@linaro.org (zhangfei)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/2] dmaengine: Add hisilicon k3 DMA engine driver
Date: Tue, 20 Aug 2013 17:23:39 +0800 [thread overview]
Message-ID: <5213359B.4070208@linaro.org> (raw)
In-Reply-To: <20130820082749.GG5810@intel.com>
On 13-08-20 04:27 PM, Vinod Koul wrote:
> On Tue, Aug 20, 2013 at 03:55:05PM +0800, zhangfei gao wrote:
>> There are many example keep define simple.
> and there are others examples which have done the otherway. I would prefer that
> way please!
>
Personally, I prefer simple is better, it is only used in the file.
But is it fine to change.
>
>>>>> why do we need the else part here?
>>>> Since asynchronous mode is supported.
>>>> Desc is submitted to list but may not get physical channel to run.
>>> But when you pause you pause the running channel. You dont pause a descriptor.
>>> So whatever you are trying to imply doesnt make sense to me.
>>
>> Here delete node from chan_pending, which will be quired from tasklet.
>>
>> The physical channel is free matched.
>> dma_issue_pending will put node to d->k3_dma_issue_pending if no phy allocated.
>> Tasklet do two jobs
>> 1, check running channel for new request form desc_issued.
>> 2, check any new chan_pending and alloc phy if available.
>>
>> If no phy, the node will be put in chan_pending.
>> If pause does not remove from chan_pending, it may be got from tasklet
>> to start a new transaction.
>> So it's safe to remove from chan_pending when pause, and add back when resume.
> But when you add, where do you start from, from the start of the descriptor or
> the previosu position.
>
> The point is pause-resume you dont need to do all that. Channel is paused so
> just pause it by stopping exuection, not more. Then you resume by asking
> controller to start from where it left off.
Since it is async mode, it does not know the physical channel is really
started or not.
When desc is submitted, it can be
a). get phy and run, pause can stop and resume where it stops.
b). Dot not start at all since no phy available (16 phys vs 27 request
line), if pause do nothing it will stay in chan_pending, if tasklet
happens again, it will be fetched and started, while upper layer thought
it is already paused.
Do we need consider case b?
next prev parent reply other threads:[~2013-08-20 9:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-28 12:39 [PATCH v2 0/2] dmaengine: add k3dma Zhangfei Gao
2013-06-28 12:39 ` [PATCH v2 1/2] dmaengine: add interface of dma_get_slave_channel Zhangfei Gao
2013-06-28 14:32 ` Arnd Bergmann
2013-08-13 11:04 ` Vinod Koul
2013-06-28 12:39 ` [PATCH v2 2/2] dmaengine: Add hisilicon k3 DMA engine driver Zhangfei Gao
2013-08-13 11:20 ` Vinod Koul
2013-08-15 5:54 ` zhangfei gao
2013-08-19 5:35 ` Vinod Koul
2013-08-20 7:55 ` zhangfei gao
2013-08-20 8:27 ` Vinod Koul
2013-08-20 9:23 ` zhangfei [this message]
2013-08-20 8:50 ` Vinod Koul
2013-08-20 13:36 ` zhangfei gao
2013-08-21 4:58 ` Vinod Koul
2013-08-21 8:02 ` zhangfei gao
2013-08-25 9:14 ` Vinod Koul
2013-08-22 1:39 ` zhangfei gao
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=5213359B.4070208@linaro.org \
--to=zhangfei.gao@linaro.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).