Re: snd-aoa status update / automatic driver loading

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 3021 bytes --]

On Sun, 2006-05-21 at 09:56 +1000, Benjamin Herrenschmidt wrote:

> What do you mean by lost interrupts ?

Well, when our interrupt handler isn't run for each expected interrupt.

> 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.

Right. But I have a hard time believing that we had such a high latency,
I expect an interrupt about every 10ms under normal alsa programming.

> 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.

Yeah ok, we might be able to figure out what's causing this, but on an
otherwise idle system I assumed actual hardware problems, but it also
never happened on my machine, only on my brother's (same as your pbook).

> 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.

Right, that's how snd-powermac does it. It has the nasty side-effect of
polluting the cache a lot though, since dbdma commands are 16 bytes
long. Am I wrong?

> Since we can only update the framecounter on a per-period basis, 

Alsa calls this thing the 'pointer' :) The frame counter we currently
use is the frame counter register of the i2s bus controller, and I don't
see why we shouldn't do that instead of reading back all the dbdma
command status fields.

> 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. 

Yes, we can set the minimum period count or maximum period length. Not a
hint though, it then makes it required.

> 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....

Since the i2s bus is not shut down it also counts when we are not
transferring data. We currently calibrate on the first interrupt. That's
fine, since having multiple periods means that we don't need to be
absolutely precise here. If we miss one, that's fine, we can make it up
the next time by saying that 2 have elapsed.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]