From: Joel Fernandes <joelf-l0cyMroinI0@public.gmane.org>
To: joelf-l0cyMroinI0@public.gmane.org
Cc: Mark Brown <broonie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>,
Grant Likely
<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>,
Sricharan R <r.sricharan-l0cyMroinI0@public.gmane.org>,
Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>,
Chris Ball <cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org>,
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
Rajendra Nayak <rnayak-l0cyMroinI0@public.gmane.org>,
Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
Jason Kridner <jkridner-hcmAuCOw+vXj4SYmN/TMmA@public.gmane.org>,
Linux OMAP List
<linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux ARM Kernel List
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
Linux DaVinci Kernel List
<davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org>,
Balaji TK <balajitk-l0cyMroinI0@public.gmane.org>,
Linux MMC List
<linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Santosh Shilimkar <santosh.shilim>
Subject: Re: [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-l0cyMroinI0@public.gmane.org>
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
WARNING: multiple messages have this Message-ID (diff)
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
WARNING: multiple messages have this Message-ID (diff)
From: Joel Fernandes <joelf@ti.com>
To: <joelf@ti.com>
Cc: Sekhar Nori <nsekhar@ti.com>, Tony Lindgren <tony@atomide.com>,
Santosh Shilimkar <santosh.shilimkar@ti.com>,
Sricharan R <r.sricharan@ti.com>, Rajendra Nayak <rnayak@ti.com>,
Lokesh Vutla <lokeshvutla@ti.com>,
Matt Porter <matt@ohporter.com>,
Grant Likely <grant.likely@secretlab.ca>,
Rob Herring <rob.herring@calxeda.com>,
Vinod Koul <vinod.koul@intel.com>, Dan Williams <djbw@fb.com>,
Mark Brown <broonie@linaro.org>,
Benoit Cousson <benoit.cousson@linaro.org>,
Russell King <linux@arm.linux.org.uk>,
Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net>,
Balaji TK <balajitk@ti.com>,
Gururaja Hebbar <gururaja.hebbar@ti.com>,
Chris Ball <cjb@laptop.org>,
Jason Kridner <jkridner@beagleboard.org>,
Linux OMAP List <linux-omap@vger.kernel.org>,
Linux ARM Kernel List <linux-arm-kernel@lists.infradead.org>,
Linux DaVinci Kernel List
<davinci-linux-open-source@linux.davincidsp.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux MMC List <linux-mmc@vger.kernel.org>
Subject: Re: [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: 85+ 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 ` Joel Fernandes
2013-07-29 13:29 ` Joel Fernandes
[not found] ` <1375104595-16018-1-git-send-email-joelf-l0cyMroinI0@public.gmane.org>
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 ` Joel Fernandes
2013-07-29 13:29 ` 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 ` Joel Fernandes
2013-07-29 13:29 ` Joel Fernandes
2013-07-29 13:29 ` [PATCH 3/9] ARM: edma: Add function to manually trigger an EDMA channel Joel Fernandes
2013-07-29 13:29 ` Joel Fernandes
2013-07-29 13:29 ` Joel Fernandes
[not found] ` <1375104595-16018-4-git-send-email-joelf-l0cyMroinI0@public.gmane.org>
2013-07-30 5:18 ` Sekhar Nori
2013-07-30 5:18 ` Sekhar Nori
2013-07-30 5:18 ` Sekhar Nori
[not found] ` <51F74CAD.3040604-l0cyMroinI0@public.gmane.org>
2013-07-31 4:30 ` Joel Fernandes
2013-07-31 4:30 ` Joel Fernandes
2013-07-31 4:30 ` Joel Fernandes
[not found] ` <51F892D2.4090805-l0cyMroinI0@public.gmane.org>
2013-07-31 5:23 ` Sekhar Nori
2013-07-31 5:23 ` Sekhar Nori
2013-07-31 5:23 ` Sekhar Nori
[not found] ` <51F89F5E.2050605-l0cyMroinI0@public.gmane.org>
2013-07-31 5:34 ` Fernandes, Joel
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-29 13:29 ` Joel Fernandes
[not found] ` <1375104595-16018-5-git-send-email-joelf-l0cyMroinI0@public.gmane.org>
2013-07-30 7:05 ` Sekhar Nori
2013-07-30 7:05 ` Sekhar Nori
2013-07-30 7:05 ` Sekhar Nori
[not found] ` <51F7659E.3040302-l0cyMroinI0@public.gmane.org>
2013-07-31 4:49 ` Joel Fernandes
2013-07-31 4:49 ` Joel Fernandes
2013-07-31 4:49 ` Joel Fernandes
[not found] ` <51F89763.1010102-l0cyMroinI0@public.gmane.org>
2013-07-31 9:18 ` Sekhar Nori
2013-07-31 9:18 ` Sekhar Nori
2013-07-31 9:18 ` Sekhar Nori
[not found] ` <51F8D667.2040406-l0cyMroinI0@public.gmane.org>
2013-08-01 2:27 ` Joel Fernandes
2013-08-01 2:27 ` Joel Fernandes
2013-08-01 2:27 ` Joel Fernandes
[not found] ` <51F9C793.2000001-l0cyMroinI0@public.gmane.org>
2013-08-01 3:43 ` Joel Fernandes
2013-08-01 3:43 ` Joel Fernandes
2013-08-01 3:43 ` Joel Fernandes
2013-08-01 4:39 ` Joel Fernandes
2013-08-01 4:39 ` Joel Fernandes
2013-08-01 4:39 ` Joel Fernandes
2013-08-01 6:13 ` Sekhar Nori
2013-08-01 6:13 ` Sekhar Nori
2013-08-01 6:13 ` Sekhar Nori
[not found] ` <51F9FC87.3020706-l0cyMroinI0@public.gmane.org>
2013-08-01 20:28 ` Joel Fernandes
2013-08-01 20:28 ` Joel Fernandes
2013-08-01 20:28 ` Joel Fernandes
[not found] ` <51FAC50A.2020507-l0cyMroinI0@public.gmane.org>
2013-08-01 20:48 ` Joel Fernandes [this message]
2013-08-01 20:48 ` Joel Fernandes
2013-08-01 20:48 ` Joel Fernandes
2013-08-02 13:26 ` Sekhar Nori
2013-08-02 13:26 ` Sekhar Nori
2013-08-02 13:26 ` Sekhar Nori
[not found] ` <51FBB371.6030901-l0cyMroinI0@public.gmane.org>
2013-08-02 18:15 ` Joel Fernandes
2013-08-02 18:15 ` Joel Fernandes
2013-08-02 18:15 ` Joel Fernandes
[not found] ` <51FBF749.4010303-l0cyMroinI0@public.gmane.org>
2013-08-02 23:00 ` Joel Fernandes
2013-08-02 23:00 ` 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 ` Joel Fernandes
2013-07-29 13:29 ` 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 ` 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-29 13:29 ` Joel Fernandes
2013-07-29 13:29 ` Joel Fernandes
[not found] ` <1375104595-16018-8-git-send-email-joelf-l0cyMroinI0@public.gmane.org>
2013-07-30 8:29 ` Sekhar Nori
2013-07-30 8:29 ` Sekhar Nori
2013-07-30 8:29 ` Sekhar Nori
[not found] ` <51F77982.7030601-l0cyMroinI0@public.gmane.org>
2013-07-31 5:05 ` Joel Fernandes
2013-07-31 5:05 ` Joel Fernandes
2013-07-31 5:05 ` Joel Fernandes
[not found] ` <51F89B0B.4080803-l0cyMroinI0@public.gmane.org>
2013-07-31 9:35 ` Sekhar Nori
2013-07-31 9:35 ` Sekhar Nori
2013-07-31 9:35 ` Sekhar Nori
[not found] ` <51F8DA5C.9060503-l0cyMroinI0@public.gmane.org>
2013-08-01 1:59 ` Joel Fernandes
2013-08-01 1:59 ` Joel Fernandes
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 ` Joel Fernandes
2013-07-29 13:29 ` [PATCH 9/9] dma: edma: remove limits on number of slots Joel Fernandes
2013-07-29 13:29 ` 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-l0cymroini0@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=balajitk-l0cyMroinI0@public.gmane.org \
--cc=broonie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org \
--cc=davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org \
--cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
--cc=jkridner-hcmAuCOw+vXj4SYmN/TMmA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
--cc=linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lokeshvutla-l0cyMroinI0@public.gmane.org \
--cc=r.sricharan-l0cyMroinI0@public.gmane.org \
--cc=rnayak-l0cyMroinI0@public.gmane.org \
--cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
--cc=tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org \
--cc=vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.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.