On Sat, Nov 06, 1999 at 03:11:47PM +0100, WITEK Wnuk wrote:

> > but I am not totally convinced. Given the time I already spend on this bus,
> > you should grant me some reserve ;-)
> i don't even know what PAL is.. :) (some king of programable logic?? or?)

Yes. The Hades does not use a standard chipset to drive the PCI-bus.

> So if you put eap in the same slot as eso before, with same irq, there are
> only few things that can be broken. Or is Hades hardware more random than
> i think?

I am not sure ;-) With my previous board, my adaptec only started to function
after a warming up of about 5 Mins... Now my current board seems to be much
better.

> Some register access works. Is it right to assume that all register access
> is ok? Do you have any examples, that it is opposite? Driver maps only one
> pci I/O register space.

No, I can not point one way or the other with 100% certainty. Let us assume
it will work correctly. Given the fact that both volume and sample rate can
be controlled, this seems to be OK.

> So it may be bus-mastering that is broken. How do you think? (Did you
> encounter similar problems?)

Might. But since the ess-solo works correctly and this too is a bus-mastering
card, bus-mastering seems OK. I am not sure if there is a difference in the
way both cards drive the bus.

> Other possibility is that card isn't reseted properly. There is no soft
> reset code in eap driver (only codec is reseted). Does Hades have some
> problems with PCI reset?

Not with the hardware reset that I know of. But remember that there is no
such thing as a builtin PCI-bios in the Hades. We are more or less doing
our own job in initializing cards and handing out addresses (see
pci/pci_machdep.c). So you might have a point here...

> > > Is card detected at all?
> > 
> > Yes it is.
> >   eap0 at pci0 dev 2 function 0: vendor 0x1274 product 0x5000 (rev. 0x01)
> >   eap0: interrupting at irq 1
> > 
> > I have the driver running in debug mode. At the end, the relevant
> btw, did you try compiling audio.c with debug? if not, try. it may give
> some more interesting information
> > snippets from the dmesg output can be found.
> 
> Did you press ^C while playing boing.au? Was it long file?
> Did I understood you correctly: 'beep' starts once you open/close file and
> never stops?

I compiled audio.c with debug. But since 'cat notexistent_file > /dev/audio'
starts the 'beep' I doubt the output is of interest. Following is the result
of the open/close:
  audio_open: flags=0x402 sc=0x25d000 hdl=0x254600
  audio: Setting record params sr=8000, enc=1, chan=1, prec=8
  audio: Setting play params sr=8000, enc=1, chan=1, prec=8
  eap_set_params: old ICSC = 0x00000002
  eap_set_params: set ICSC = 0x00ae0402
  audio_calc_blksize: record blksize=384
  audio_calc_blksize: play blksize=800
  audio: After setting record params sr=8000, enc=1, chan=1, prec=8
  audio: After setting play params sr=8000, enc=1, chan=1, prec=8
  audio_initbufs: mode=0x5
  audio_init_ringbuffer: blksize=384
  audio_init_ringbuffer: blksize=800
  audio_open: done sc_mode = 0x5
  audio_close: sc=0x25d000
  eap: eap_halt_output
  eap: eap_halt_input
  audio_close: done

> The beep is rather high frequency (like sample rate divided by two or
> four), isn't it? It may mean that DMA engine isn't working properly. It

Yes. This is it exactly!

> But, if so, why is DMA started?

Now, that is a good question. That is why maybe the initialisation might
be the problem. This looks a feasible problem area.

> There is no eap_intr in dmesg output.

That is right. I seem to remember that when a print statement is added to the
top of eap_intr, you will see it show up after eap_halt_input.

> > I saw your driver for the ac97 (es1371 right?), and I happend to see your
> > mail address ;-))
> Not exactly. I wrote only FM801 driver (which uses AC'97). AC'97 support
> that *I* wrote never left my home (it was incomplete).

Ah, OK. I usually skim through the source changes. Memory error ;-)

> Ok. If you can control frequency with 'audioctl -w play.rate=xxx' too,
> then you already have some primitive audio support :))
> 
> Now, seriously. Can you control frequency?

Definitely: yes!

> i still hope it is bug in driver, and can be fixed easily,

Me too. Though I don't know enough about the card&driver to know where to
start...

Leo.