From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
Benjamin Berg <benjamin@sipsolutions.net>,
debian-powerpc <debian-powerpc@lists.debian.org>
Subject: Re: snd-aoa status update / automatic driver loading
Date: Sun, 21 May 2006 09:56:28 +1000 [thread overview]
Message-ID: <1148169389.13249.44.camel@localhost.localdomain> (raw)
In-Reply-To: <1148034127.15507.178.camel@johannes>
> Alternatively we could use the register just to detect if we lost
> interrupts, i.e. calculate how many frames we have per period and then
> see if the frame count increased approximately by that much (I've seen
> +- a few frames probably due to timing, with higher samplerates we'll
> probably see a bit more error) and if it increased by much more we could
> estimate how many interrupts we lost. What do you think?
What do you mean by lost interrupts ?
DBDMA sends edge interrupts. Thus, if it emits interrupts A, then B and
C, and for any reason, your kenrel is not able to service interrupts (is
doing something with IRQs disabled) from before B happens to after C
happens, you'll indeed get called only twice (A and C) and "B" will be
sort-of lost.
First thing about that is: what the heck is causing us to have such a
latency !!! that would be useful to figure out. A way to do that would
be maybe to "detect" when C happens that we missed B (see below how to
do that) and print something along with the regs->nip & lr (or even a
backtrace). That might give us an idea of there interrupts are
re-enabled after the long latency which could perhaps lead us to the
cause of the latency.
Now for detecting lost interrupts (and for being immune to them), the
technique is not to just assume IRQ -> 1 period completed, but instead,
when an irq happens, to go read the DBDMA descriptors in memory to see
which ones have actually been completed. Their status field should be
updated as their get comleted. Thus, you keep track of the "previous"
last completed descriptor and you walk from that to recycle them.
Since we can only update the framecounter on a per-period basis, the
driver would benefit from having lots of very small periods. I don't
know if we can provide "hints" to userland about that though. Using the
i2s frame counter means we need some kind of calibration... it might
still be counting if for the reason the DBDMA "misses" something or gets
stopped....
Ben.
next prev parent reply other threads:[~2006-05-20 23:57 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-17 10:09 snd-aoa status update / automatic driver loading Johannes Berg
2006-05-17 18:57 ` Tony Vroon
2006-05-19 10:22 ` Johannes Berg
2006-05-20 23:56 ` Benjamin Herrenschmidt [this message]
2006-05-22 6:42 ` Johannes Berg
2006-05-23 22:15 ` Benjamin Herrenschmidt
2006-05-24 9:42 ` Johannes Berg
2006-05-25 8:00 ` Benjamin Herrenschmidt
2006-05-25 9:42 ` Johannes Berg
2006-05-26 1:30 ` Benjamin Herrenschmidt
2006-05-17 19:53 ` Andreas Schwab
2006-05-18 10:14 ` Johannes Berg
2006-05-17 21:54 ` Wolfgang Pfeiffer
2006-05-17 22:19 ` Wolfgang Pfeiffer
2006-05-18 10:13 ` Johannes Berg
2006-05-18 18:17 ` Wolfgang Pfeiffer
2006-05-18 22:06 ` Andreas Schwab
2006-05-19 12:50 ` Johannes Berg
2006-05-19 14:40 ` Wolfgang Pfeiffer
2006-05-19 14:40 ` Johannes Berg
2006-05-17 22:30 ` Dean Hamstead
2006-05-18 0:28 ` Wolfgang Pfeiffer
2006-05-18 0:39 ` Dean Hamstead
2006-05-18 1:01 ` Wolfgang Pfeiffer
2006-05-18 1:08 ` Benjamin Herrenschmidt
2006-05-18 7:25 ` Eddy Petrişor
2006-05-18 10:23 ` Johannes Berg
2006-05-19 13:20 ` Paul Collins
2006-05-19 13:46 ` Johannes Berg
2006-05-19 14:40 ` Paul Collins
2006-05-19 14:49 ` Johannes Berg
2006-05-19 15:13 ` Paul Collins
2006-05-19 14:33 ` Andreas Schwab
2006-05-19 14:37 ` Johannes Berg
2006-05-23 15:41 ` Sjoerd Simons
2006-05-25 7:21 ` Eddy Petrişor
2006-05-25 7:21 ` Eddy Petrişor
2006-05-25 9:43 ` Johannes Berg
2006-05-25 17:44 ` Eddy Petrişor
2006-05-25 18:47 ` Johannes Berg
2006-05-18 8:56 ` Rene Rebe
2006-05-18 10:08 ` Johannes Berg
[not found] ` <200605180002.01669.borge@arivene.net>
[not found] ` <20060518004141.GC1552@kunpuu.plessy.org>
2006-05-20 14:57 ` Benjamin Berg
2006-05-20 23:59 ` Benjamin Herrenschmidt
2006-05-23 3:11 ` Hollis Blanchard
2006-05-23 12:27 ` Johannes Berg
2006-05-23 14:46 ` Hollis Blanchard
2006-05-23 15:25 ` Hollis Blanchard
2006-05-24 9:41 ` Johannes Berg
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=1148169389.13249.44.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=benjamin@sipsolutions.net \
--cc=debian-powerpc@lists.debian.org \
--cc=johannes@sipsolutions.net \
--cc=linuxppc-dev@ozlabs.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).