Subject: Re: audio fail
To: Jared D. McNeill <jmcneill@invisible.ca>
From: Iain Hibbert <plunky@rya-online.net>
List: tech-kern
Date: 09/24/2006 16:42:55
On Sun, 24 Sep 2006, Jared D. McNeill wrote:

> On 24-Sep-06, at 8:39 AM, Iain Hibbert wrote:
>
> > Would this be the correct way to handle this?
>
> This seems reasonable to me. Now, it doesn't help 95% of audio drivers (who
> use trigger_input/output instead of start_input/output), but it's a start :)

Hmm thats true.. I hadnt really considered that this was much of a problem
for other audio devices though I think its one reason I didnt use the
trigger_* routines, I guess once DMA is setup it mostly keeps going..

Maybe adding a status argument to the interrupt routines would work
better? That would require an API edit but it seems possible and allows
the hardware to signal errors. The interrupt routine then stores that
value and calls a halt & wakeup on error. Something like this:

  * Do a wakeup if necessary.
  */
 void
-audio_pint(void *v)
+audio_pint(void *v, int error)
 {
 	stream_fetcher_t null_fetcher;
 	struct audio_softc *sc;
@@ -2506,12 +2520,17 @@
 	uint8_t *inp;
 	int cc, used;
 	int blksize;
-	int error;

 	sc = v;
 	if (!sc->sc_open)
 		return;		/* ignore interrupt if not open */

+	if (error) {
+		sc->sc_perr = error;
+		audio_clear(sc);
+		return;
+	}
+
 	hw = sc->hw_if;
 	cb = &sc->sc_pr;
 	blksize = cb->blksize;

I could look into it?  Though, it occurs to me that this, along with the
method I posted earlier, does not work with mmap (btsco denies mmap
anyway) and I'm not sure how you could indicate an error then in any case
- maybe its up to the user of a mmapped device to work it out from the
pointers.

iain