[alsa-devel] [PATCH RFC] ALSA: rme32: fix interrupt ack for me

[Takashi Iwai]

On Sun, 24 Mar 2019 12:19:49 +0100,
René Rebe wrote:
> 
> Hey,
> 
> On 02 Mar 2019, at 18:19, René Rebe <rene at exactcode.de> wrote:
> 
> > Hi Takashi,
> > 
> > On 18 Jul 2018, at 12:56, Takashi Iwai <tiwai at suse.de> wrote:
> > 
> >>> to have another digital audio i/o card for our studio / office, I got a pair of RME32 the other week from ebay. (mostly as reference to implement ADAT for the RAD1 Sgi/Octane ALSA driver, …)
> >>> 
> >>> Unfortunately they do not work with Linux. They are recognised and all the usual devices and /proc/… entries show up, however, the hardware pointer does not move during playback or capture no matter what clock source I choose.
> >>> I tried attaching coax s/pdif as well as an 8-channel Behringer Ultragain ADAT source w/ clock.
> >> 
> >> Does the /proc/asound/card*/rme32 entry show the right setup?
> >> RME32 seems to have only few registers, and it behaves differently for
> >> read and write.  Maybe you should try to watch the register 0x20000.
> >> The hwptr is the LSB 33 bits.
> > 
> > thank you again for your reply, and I finally took a deep breath to "shortly"
> > take a closer look at this again. So with current linux-kernel :HEAD nothing
> > has changed, and I get one IRQ when the playback starts.
> > 
> > As I do not have the spec I did a quick hack and commented out the IRQ
> > acknowledge around rme32.c line 829:
> > 
> > -                writel(0, rme32->iobase + RME32_IO_CONFIRM_ACTION_IRQ);
> > 
> > surprisingly this “works” in that I have more than the first frame coming out of
> > the optical fibre, aka quite constant running pcm stream.
> > 
> > "Quite constant” because I think I sometimes (rarely) here some samples
> > getting lost, probably because the IRQ keeps firing as it was not acknowledged.
> > However, I’m surprised this works 99%ish anyway.
> > 
> > Of course the questions is now to actually properly fix this, as acknowledging
> > this IRQ somehow makes the card stop entirely, I guess, somehow? At least
> > that is how it looks like. Maybe you have an idea? Maybe some ALSA stream
> > helper refactoring broke something a decade ago?
> > 
> > I should probably also mention that this works with aplay, while with sox’s
> > “play” this hack is somehow producing constant under-run’s:
> > 
> > In:85.6% 00:03:18.02 [00:00:33.35] Out:8.73M [!=====|=====!] Hd:0.0 Clip:0    play WARN alsa: under-run
> > play WARN alsa: under-run
> > play WARN alsa: under-run
> > 
> > which might be an indication of some stream pointer helper glue not being wired up correctly anymore (I tested some seriously old version the last time, like 2.6.29’ish, so this might be broken since over a decade or so already)?
> > 
> > Thanks again for any tips, as otherwise I might spend many more hours trying to understand the FPGA and ALSA API.
> 
> So as the card sort of works in Windows,
> 
> 	https://www.youtube.com/watch?v=dxMH3MMyKZ4
> 
> I spent some more time finding a workaround.
> 
> 	https://www.youtube.com/watch?v=78-JxDzbHX8
> 
> Writing something else then 0 to the interrupt acknowledge register keeps the stream running.
> Writing 0xffffffff	causes the stream to corrupt.
> So I thought maybe this FPGA bitstream copies this value into the command register,
> and writing that register copy at least playback work for me now. Capture does still not work, but that is probably a story to be continued  another month:
> 
> --- linux-4.20/sound/pci/rme32.c.vanilla	2019-03-03 15:09:34.485653177 +0000
> +++ linux-4.20/sound/pci/rme32.c	2019-03-03 15:09:51.077653422 +0000
> @@ -863,7 +863,7 @@
>  		if (rme32->playback_substream) {
>  			snd_pcm_period_elapsed(rme32->playback_substream);
>  		}
> -		writel(0, rme32->iobase + RME32_IO_CONFIRM_ACTION_IRQ);
> +		writel(rme32->wcreg, rme32->iobase + RME32_IO_CONFIRM_ACTION_IRQ);
>  	}
>  
>  	return IRQ_HANDLED;
> 
> In case this stupid Mail.app causes white space damages:
> https://svn.exactcode.de/t2/trunk/package/base/linux/rme32-hothack.patch
> 
> PS: as per the above 3h video I read the disassembly and confirmed the value is
> written into the RME32_IO_CONFIRM_ACTION_IRQ MMMIO location.

OK, that sounds reasonable.  Actually writing 0 for ACK is somewhat
weird, I guess the driver code took the behavior from rme96.c.

Possibly the behavior depends on boards, but as long as you can see it
working with the change, it's fine to apply the change now, of course.

Would you submit a proper patch, or rather let me do that in my side?


thanks,

Takashi