NetBSD Problem Report #32651

From www@netbsd.org  Fri Jan 27 16:12:40 2006
Return-Path: <www@netbsd.org>
Received: by narn.netbsd.org (Postfix, from userid 31301)
	id D9B6563B879; Fri, 27 Jan 2006 16:12:40 +0000 (UTC)
Message-Id: <20060127161240.D9B6563B879@narn.netbsd.org>
Date: Fri, 27 Jan 2006 16:12:40 +0000 (UTC)
From: nbgnats@anastigmatix.net
Reply-To: nbgnats@anastigmatix.net
To: gnats-bugs@netbsd.org
Subject: Drivers that busy-wait MIDI output if they don't have to
X-Send-Pr-Version: www-1.0

>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
>Last-Modified:  Sun Jun 18 09:25:01 +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.

>Audit-Trail:
From: Chapman Flack <chap@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: PR/32651 CVS commit: [chap-midi] src/sys/dev/pci
Date: Sun, 18 Jun 2006 09:22:24 +0000 (UTC)

 Module Name:	src
 Committed By:	chap
 Date:		Sun Jun 18 09:22:24 UTC 2006

 Modified Files:
 	src/sys/dev/pci [chap-midi]: eap.c eapreg.h

 Log Message:
 Updates PR kern/32651

 The eap driver now makes use of the MIDI UART tx interrupt available on
 the Ensoniq chips.  A test with nominally 20 seconds of continuous transmit
 data went from 26 s real / 25 s system to 22 s real / 0.16 s system.
 Implementation is quite simple, and anyone who knows any of the other
 MIDI UART chips well enough to get a tx interrupt out of it would do a
 world of good by updating their drivers similarly.

 Anyway, scratch one off the kern/32651 todo list.

 Also added a documentation reference to the ES1373 datasheet, and added
 more 1371- and 1373-specific #defines in eapreg.h.  Enough there now that
 anyone who wanted to play with the S/PDIF capability on the 1373 could
 begin to do that.


 To generate a diff of this commit:
 cvs rdiff -r1.81 -r1.81.14.1 src/sys/dev/pci/eap.c
 cvs rdiff -r1.11 -r1.11.14.1 src/sys/dev/pci/eapreg.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

Home	PR Database Search