From: joelf@ti•com (Joel Fernandes)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 4/9] dma: edma: Find missed events and issue them
Date: Thu, 1 Aug 2013 15:48:57 -0500 [thread overview]
Message-ID: <51FAC9B9.3050903@ti.com> (raw)
In-Reply-To: <51FAC50A.2020507@ti.com>
Just some corrections here..
On 08/01/2013 03:28 PM, Joel Fernandes wrote:
>>> 2. If the interrupt handler for some reason doesn't complete or get
>>> service in time, we will end up DMA'ing incorrect data as events
>>> wouldn't stop coming in even if interrupt is not yet handled (in your
>>> example linked sets P1 or P2 would be old ones being repeated). Where as
>>> with my method, we are not doing any DMA once we finish the current
>>> MAX_NR_SG set even if events continue to come.
>>
>> Where is repetition and possibility of wrong data being transferred? We
>> have a linear list of PaRAM sets - not a loop. You would link the end to
>> PaRAM set chain to dummy PaRAM set which BTW will not cause missed
>> events. The more number of PaRAM sets you add to the chain, the more
>
> There would have to be a loop, how else would you ensure continuity and
> uninterrupted DMA?
>
> Consider if you have 2 sets of linked sets:
> L1 is the first set of Linked sets and L2 is the second.
>
> When L1 is done, EDMA continues with L2 (due to the link) while
> interrupt handler prepares L1. The continuity depends on L1 being linked
> to L2. Only the absolute last break up of the MAX_NR_SG linked set will
> be linked to Dummy.
>
> So consider MAX_NR_SG=10, and sg_len = 35
>
> L1 - L2 - L1 - L1 - Dummy
Should be,
L1 - L2 - L1 - L2 - Dummy
>
> The split would be in number of slots,
> 10 - 10 - 10 - 5 - Dummy
>
>> time CPU gets to intervene before DMA eventually stalls. This is a
>> tradeoff system designers can manage.
>
> Consider what happens in the case where MAX_SG_NR=1 or 2. In that case,
> there's a change we might not get enough time for the interrupt handler
> to setup next series of linked set.
>
> Some how this limitation has to be overcome by advising in comments than
> MAX_SG_NR should always be greater than a certain number to ensure
> proper operation.
s/than/that/
Thanks,
-Joel
next prev parent reply other threads:[~2013-08-01 20:48 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-29 13:29 [PATCH 0/9] dma: edma: Support scatter-lists of any length Joel Fernandes
2013-07-29 13:29 ` [PATCH 1/9] dma: edma: Setup parameters to DMA MAX_NR_SG at a time Joel Fernandes
2013-07-29 13:29 ` [PATCH 2/9] dma: edma: Write out and handle MAX_NR_SG at a given time Joel Fernandes
2013-07-29 13:29 ` [PATCH 3/9] ARM: edma: Add function to manually trigger an EDMA channel Joel Fernandes
2013-07-30 5:18 ` Sekhar Nori
2013-07-31 4:30 ` Joel Fernandes
2013-07-31 5:23 ` Sekhar Nori
2013-07-31 5:34 ` Fernandes, Joel
2013-07-29 13:29 ` [PATCH 4/9] dma: edma: Find missed events and issue them Joel Fernandes
2013-07-30 7:05 ` Sekhar Nori
2013-07-31 4:49 ` Joel Fernandes
2013-07-31 9:18 ` Sekhar Nori
2013-08-01 2:27 ` Joel Fernandes
2013-08-01 3:43 ` Joel Fernandes
2013-08-01 4:39 ` Joel Fernandes
2013-08-01 6:13 ` Sekhar Nori
2013-08-01 20:28 ` Joel Fernandes
2013-08-01 20:48 ` Joel Fernandes [this message]
2013-08-02 13:26 ` Sekhar Nori
2013-08-02 18:15 ` Joel Fernandes
2013-08-02 23:00 ` Joel Fernandes
2013-07-29 13:29 ` [PATCH 5/9] dma: edma: Leave linked to Null slot instead of DUMMY slot Joel Fernandes
2013-07-29 13:29 ` [PATCH 6/9] dma: edma: Detect null slot errors and handle them correctly Joel Fernandes
2013-07-29 13:29 ` [PATCH 7/9] ARM: edma: Don't clear EMR of channel in edma_stop Joel Fernandes
2013-07-30 8:29 ` Sekhar Nori
2013-07-31 5:05 ` Joel Fernandes
2013-07-31 9:35 ` Sekhar Nori
2013-08-01 1:59 ` Joel Fernandes
2013-07-29 13:29 ` [PATCH 8/9] dma: edma: Link to dummy slot only for last SG list split Joel Fernandes
2013-07-29 13:29 ` [PATCH 9/9] dma: edma: remove limits on number of slots Joel Fernandes
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=51FAC9B9.3050903@ti.com \
--to=joelf@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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