Messages in this thread | | | From | (Bob_Tracy) | Subject | Re: PAS-16 problems with 2.3.50+ (was Re: Linux Jobs: Update) | Date | Sun, 12 Mar 2000 17:09:27 -0600 (CST) |
| |
clubneon wrote: > Yeah, I'm not understanding the lack of being able to compile in settings > for my PAS16 also. Even if they were compiled in, they could still be > overroad on the command line (correct?). > > I've always thought of the lilo "append" command as a hack to get things > working that were odd. I always prided myself on having a machine that > didn't need any appends.
Put me in that camp as well, but here's the lay of the land as best I understand it.
There has been a long sustained push to modularize the sound drivers. You may legitimately ask "why?" since PCMCIA/cardbus sound cards are rare beasts indeed. Mostly, it happened because the distribution maintainers couldn't possibly put a distribution together that would support a given user's sound configuration without a modular sound driver collection. Ok... So I was thus convinced that modular sound drivers have their place.
As for why we can no longer compile in the driver settings for our static configurations, that's another matter. The sound drivers have been a mess for a long time. Originally, the drivers as provided by Hannu were intended to be useable on a wide variety of UN*X platforms. Naturally, that meant the drivers weren't optimal for *any* of the supported platforms. In the Linux case, if you were going to write a sound driver from the ground up, I would assume you would try to write it so that autoprobing would work: this path is fraught with peril. On the other hand, a necessary step if you're going in that direction is to provide the same kind of mechanism that exists for other Linux drivers where autoprobing isn't reliable or just flat doesn't work, i.e., the "append" clause in "lilo.conf".
As best I can figure out the PAS-16 situation as of 2.3.50, here's an "append" line that works for me:
append = "opl3=0x388 pas2=0x388,11,5,-1,0,-1,-1,-1"
where the "pas2" arguments are "<io>,<irq>,<dma>,<dma2>,<sbio>,<sbirq>,<sbdma>,<sbdma2>"
As far as I know, dma2 should always be "-1". sbio should be 0 if you don't wish to enable SoundBlaster emulation, 1 otherwise. Normally, you *don't* want to enable SoundBlaster emulation. Note that all the values after <dma> are the defaults if you build the PAS-16 driver as a module. Here's a gotcha: there *are* no defaults if you build the driver as part of the kernel, i.e., you should (and usually *must*) supply ALL parameters, else, you can pretty well count on an "oops" at boot time during driver initialization.
As usual, read the source for the gory details... At boot time, the adlib driver will complain that you need to supply an I/O address. If you supply the proper address (normally 0x388), the sound drivers will politely inform you that only one opl3 is supported. In other words, you can't eliminate all the boot time "error" messages, but they aren't really errors in any sense that matters as far as getting a functional PAS-16 card.
-- Bob Tracy | "C++ is to C as Lung Cancer is to Lung." rct@wlk.com | --Anonymous Coward on slashdot.org
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |