MIDI on ice1724 - preliminary findings and questions

[Pavel Hofman <pavel.hofman@insite.cz>]

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

Hi,

I am trying to fix the ancient MIDI problem with ice1724 cards. I 
applied Takashi's patch from 
http://mailman.alsa-project.org/pipermail/alsa-devel/2007-April/000641.html 
and made some minor changes (MPU401_INFO_INPUT | MPU401_INFO_OUTPUT to 
mpu401_uart info_flags, added a few debugs for testing).

I can test only MIDI input using my MIDI keyboard, I have no MIDI output 
device available. The input works fine now, the output most probably too 
since the method snd_vt1724_mpu401_write gets called when transmitting 
some data with amidi.

But here is the problem I do not understand:

When no MIDI input/output is used, the interrupt handler 
snd_vt1724_interrupt gets called with interrupt status 0x10 which 
correctly refers to the audio data interrupt (VT1724_IRQ_MTPCM).

However, when MIDI input or output is used (opened) even for a short 
time after the module is loaded, any subsequent audio playback generates 
interrupt status of 0x30 which refers to VT1724_IRQ_MTPCM AND 
VT1724_IRQ_MPU_TX. I have no idea why VT1724_IRQ_MPU_TX gets generated.

The first run of the snd_vt1724_interrupt loop tries to handle the MPU 
TX status, calling uart_interrupt_tx in mpu401_uart.c:

	if (test_bit(MPU401_MODE_BIT_OUTPUT, &mpu->mode) &&
	    test_bit(MPU401_MODE_BIT_OUTPUT_TRIGGER, &mpu->mode)) {
		spin_lock_irqsave(&mpu->output_lock, flags);
		snd_mpu401_uart_output_write(mpu);
		spin_unlock_irqrestore(&mpu->output_lock, flags);
	}

However, since the MPU output is not open at this time (no MIDI is being 
transmitted), the call to snd_mpu401_uart_output_write is skipped. Even 
though I think the interrupt status should get cleared by

outb(status, ICEREG1724(ice, IRQSTAT))

the loop repeats with the MPU TX interrupt status enabled until the 
timeout check breaks the while loop, returning to the interrupt handler 
the next moment again.

Apr 19 22:20:47 nahore kernel: [ 2402.938245] uart interrupt: status 0x30
Apr 19 22:20:47 nahore kernel: [ 2402.938260] uart interrupt: status 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.938267] uart interrupt: status 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.938274] uart interrupt: status 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.938281] uart interrupt: status 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.938288] uart interrupt: status 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.938295] uart interrupt: status 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.938302] uart interrupt: status 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.938309] uart interrupt: status 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.938316] uart interrupt: status 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.938323] uart interrupt: status 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.938326] ice1724: Too long irq 
loop, status = 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.961247] uart interrupt: status 0x30
Apr 19 22:20:47 nahore kernel: [ 2402.961278] uart interrupt: status 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.961285] uart interrupt: status 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.961292] uart interrupt: status 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.961299] uart interrupt: status 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.961306] uart interrupt: status 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.961313] uart interrupt: status 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.961320] uart interrupt: status 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.961327] uart interrupt: status 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.961334] uart interrupt: status 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.961341] uart interrupt: status 0x20
Apr 19 22:20:47 nahore kernel: [ 2402.961344] ice1724: Too long irq 
loop, status = 0x20

After the playback stops, the interrupts are gone too. It seems as if 
the playback interrupt initiates the MPU TX interrupt.

If we could avoid generating the MPU TX interrupt during regular 
playback, I believe the major problem would be resolved.

Even if I mask the interrupts (CCS01) and do not explicitly unmask them 
(according to proc ice1724 the CCS01 register stays at 0xa0), the 
interrupt gets generated.

I am enclosing the testing patch producing the above given results.

Thanks a lot for any suggestion or help.

Regards,

Pavel.

[-- Attachment #2: mpu401-test.diff.gz --]
[-- Type: application/x-gzip, Size: 2951 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel