>Number:         32651
>Category:       kern
>Synopsis:       Drivers that busy-wait MIDI output if they don't have to
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jan 27 16:15:00 +0000 2006
>Originator:     Chapman Flack
>Release:        2.0 (checked sources in HEAD though)
>Organization:
>Environment:
NetBSD lundestad.anastigmatix.net 2.0 NetBSD 2.0 (lundestad) #112: Sat Jan 21 01:50:59 EST 2006  xxx@xxx:/usr/src/sys/arch/i386/compile/lundestad i386

>Description:
Several of the low-level drivers for MIDI UARTs operate the UARTs
in non-interrupt mode for transmit, so they busy-wait to transmit
a byte. The MI midi(4) layer supports this operation, for the
benefit of the simplest MIDI UARTs that really don't HAVE a tx
interrupt, but it requires undesirable compromises between MIDI
throughput and overall system responsiveness. For ordinary
sequenced music the effect can be small because the messages are
short and far between, but downloading patches or bulk dumps can
have a noticeable impact.

The code for several of the low-level drivers (look, for example,
at pci/eap.c around line 1876) suggests that the UARTs really do
have tx interrupts but the driver authors were not sure enough of
the interrupt-mode interface of the MI midi(4) layer to use them.
This should be fixed wherever possible. I am not an expert (and
like it that way :) on the various hw chips involved, but I'll
be happy to help decipher midi(4)'s interrupt mode for anyone
who does know a particular chip well enough to enable its tx
interrupt.

>How-To-Repeat:
transmit long blasts of MIDI data over UART drivers that don't use
the interrupt
-or-
browse the sources for those drivers whose comments seem to
indicate the hardware has a tx interrupt capability that isn't
being enabled.
>Fix:
The interface to midi(4) in interrupt mode is essentially simple:

getinfo() should include MIDI_PROP_OUT_INTR in props.

output() should return 0 if the byte has been accepted and an
interrupt will definitely be generated when ready for the next
byte, or EINPROGRESS if the byte has been accepted but no interrupt
will be generated and midi(4) must not wait for an interrupt to send
the next byte.
Any other error return means the byte has not been accepted and
no interrupt will be generated.

open() should save its 'ointr' and 'arg' arguments; the tx interrupt
handler for the hw should call back ointr, passing arg.