Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Sep 1997 22:20:30 +0200 (MET DST)
From:      Luigi Rizzo <luigi@labinfo.iet.unipi.it>
To:        jacob@jblhome.ping.dk (Jacob Bohn Lorensen)
Cc:        multimedia@FreeBSD.ORG
Subject:   Re: Unsuccesful attempt at SB16PNP and no PNP bios; what am I doing wrong?
Message-ID:  <199709022020.WAA06643@labinfo.iet.unipi.it>
In-Reply-To: <87lo1flekf.fsf@pippin.jblhome.ping.dk> from "Jacob Bohn Lorensen" at Sep 2, 97 09:07:25 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> So, I went ahead with sb_dsp.c. in the function sb16pnp_attach, I
> inserted the following lines (marked with +)
> 
>     read_pnp_parms ( &d , 0 ) ;
> +   d.irq[0] = 7;
> +   d.drq[0] = 3; d.drq[1] = 5;
> +   d.port[0] = 0x220; d.port[1] = 0x330; d.port[2] = 0x388;
>     dev->id_iobase = d.port[0];
>     write_pnp_parms ( &d , 0 , 1);

correct. The only doubt is if irq7 might conflict with the parallel
port.

> [Information from pnpinfo attached at the end of the e-mail].
> 
> I have also tried other legal combinations (irq 5).
> 
> It seems that both isa_dmastatus() and isa_dmastop() have been checked
> into src-cur-3027, so I did not need to patch isa.c, only autoconf.c,
> files.i386 and of course, copying pnp.c and pnp.h.

correct, there is only one minor difference in isa_dmastatus, where my
code returns 0 if the channel is idle, whereas -current returns -2.
I'll fix this in the next snap (sometime later this week).

> Now, my questions are
> 
>   . Why is the card attached as pcm1 ?

because I followed the same approach used for PCI devices which are
clones of isa devices (e.g. ed, lnc and other network devices): Since
unit 0 is allocated for the non-pnp isa device, and PnP devices are probed
earlier, we cannot use unit 0 for the PnP device because we do not know
if there actually is a non-PnP device... Some hacks are possible
but I do not like very much any of those I could think of (of course if
you have a good solution speak out). Also, considering that most
apps use /dev/audio, /dev/dsp, /dev/mixer and these are just
symlinks, it is easy to update the symlinks to reflect your hardware.

>   . After ./MAKEDEV snd1, if I try to use /dev/audio1 (i.a. cat a
>     random file to /dev/audio1) etc., I get messages like
> 
>      default ioctl snd1 subdev 4 fn 0x402c7413 fail
>      default ioctl snd1 subdev 4 fn 0x402c7413 fail
>      got sbintr for unit 1, flags 0x00000461
>      default ioctl snd1 subdev 4 fn 0x402c7413 fail
>      default ioctl snd1 subdev 4 fn 0x402c7413 fail
>      got sbintr for unit 1, flags 0x00000461
>      default ioctl snd1 subdev 4 fn 0x402c7413 fail
>      default ioctl snd1 subdev 4 fn 0x402c7413 fail

yes I forgot some debugging messages enabled. I'll remove them in the
next snap. Still they tell you that you are actually getting interrupts
for the device, meaning that the card is working. If you use a real .au
file you should be able to hear it (some mixer calls are still
unimplemented for the SB16 so it might be that you cannot control the
volume, but the basic mechanisms seem to work on your card. The
problem is, I don't have the card yet so I cannot test it.

	Cheers
	Luigi
-----------------------------+--------------------------------------
Luigi Rizzo                  |  Dip. di Ingegneria dell'Informazione
email: luigi@iet.unipi.it    |  Universita' di Pisa
tel: +39-50-568533           |  via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522           |  http://www.iet.unipi.it/~luigi/
_____________________________|______________________________________



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709022020.WAA06643>