Date: Mon, 21 Jul 1997 12:15:29 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: msmith@atrad.adelaide.edu.au, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: sound driver structure and configuration Message-ID: <199707210245.MAA20440@genesis.atrad.adelaide.edu.au> In-Reply-To: <199707170553.HAA15160@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 17, 97 07:53:40 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo stands accused of saying: > > > controller sndX > > > brings in all the files related to generic sound support for all > > > subsystem. This includes, in particular, the mixer, dma code, > > > timers, and some support routines. > > > > > > device pcmX at isa ? port? tty irq N drq D flags F vector pcmintr > > > device midiX at isa ? port? tty flags F > > > device synthX at isa ? port? tty flags F > > > > Thes should ideally be "at snd?", eg. like the 'disk' stuff, or just > > 'device xxx' like the SCSI devices. They're _not_ "at isa?" in the > > true sense of the word. > > right. But what are the implications of using "at xyz?" ? How do I test > for a specific bus, etc. ? I've just been working through this with the parallel-port stuff, as the ultimate goal there is to produce drivers that will work on any parallel port. The way to go for that (at the moment) is like the PCI code; you use a linker set to create an aggregated list of drivers, which you then scan with your bus code. This isn't really ideal for your case though, as whilst there's some common sound code, there's little or no correlation between the various component drivers, other than (perhaps) that they are aggregated together on a single card. > The identification info should suffice to determine exactly which > board you have (down to the revision level of the chip) so I think > there is really little need to "probe" the device; rather, one > should just run the appropriate configuration commands and deal > with exceptions the standard way. ISA device probing should essentially provide additional information supplementary to that divined by PnP. Once you have all the "what is where" information, you can start working out what to do with it. If using the PnP stuff is of interest to you, you could help me out with some suggestions for calling 16-bit protected-mode BIOS interfaces from 32-bit (eg. FreeBSD kernel) mode 8) I have reams of documentation on various bits and pieces (including the ECSD interface) which would be _very_ helpful in this endeavour. 8) > Luigi Rizzo | Dip. di Ingegneria dell'Informazione -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707210245.MAA20440>