From alsa-devel-owner@alsa.jcu.cz  Wed Mar 10 20:16:34 1999
Received: from draal.physics.wisc.edu (IDENT:mcelrath@draal.physics.wisc.edu [128.104.223.134])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id UAA14246
	for <alsa-devel@alsa.jcu.cz>; Wed, 10 Mar 1999 20:16:01 +0100
Received: from localhost (mcelrath@localhost)
	by draal.physics.wisc.edu (8.8.7/8.8.7) with ESMTP id NAA05978;
	Wed, 10 Mar 1999 13:15:45 -0600
Date: Wed, 10 Mar 1999 13:15:45 -0600 (CST)
From: Bob McElrath <mcelrath@draal.physics.wisc.edu>
To: Jaroslav Kysela <perex@jcu.cz>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: AudioPCI ALSA driver on ALPHA
In-Reply-To: <Pine.LNX.3.96.990310093754.5846B-100000@entry.jcu.cz>
Message-ID: <Pine.LNX.4.04.9903101239530.1086-100000@draal.physics.wisc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Wed, 10 Mar 1999, Jaroslav Kysela wrote:

> On Tue, 9 Mar 1999, Bob McElrath wrote:
> 
> > 
> > I'm trying to get the Audiopci (SB 128/ es1370) chipset to work on my alpha.
> > Currently, both the OSS/Free and ALSA drivers crash hard and hang the
> > machine.  I've done a little digging and found that the AudioPCI has some
> > "quirks" (read - doesn't conform to PCI spec) that may be the cause of the
> > hang.  Specifically:
> > 
> > > both the 1370 and 1371 are incapable of handling burst transactions as a
> > > target on the PCI bus.  The way they terminate the burst violates the
> > > PCI specification, and thus they hang the bus.  On Alpha, any quadword
> > > access to one of these chips is guaranteed to hang the system. Multiple
> > > accesses without an intervening mb may hang the system (this depends
> > > very much on other intervening accesses)
> > 
> > Have you ever heard of this before?  Did you have to do anything in your
> > code to compensate for this?  And why does the thing work on Intel?
> 
> Yes, I heard about this problem, but I don't know any fix or a
> workaround for it.
> 
> I cannot also debug this problem. I have the access to Personal Workstation
> 500a (miata) with the RedHat 5.1 distribution (with some updates), gcc
> 2.8.1. I HAVEN'T ANY PROBLEMS with the ES1370 soundcard (SB PCI 64) and
> the ALSA on this machine!!! I tried all features and I cannot hang this
> machine and all things work perfectly. Of course, I'm using latest ALSA
> from CVS.

Errr...bummer.  I'll try the CVS version and your mb suggestion below.  
Note that all port access to configure the card seems to work, it's the data
transfer that's broken.

On the Miata you have, is the IRQ of the [SB PCI 64] 15 or less?  I've been
told this card only implements 4 bits of the IRQ address.  On my motherboard
< 16 is assigned to the ISA bridge and this it's impossible to give it an
IRQ < 16.  <i think> Page 9 of the ES1370 docs, "Interrupt Line Addres 3CH"
show bits 3:0 for the interrupt (4 bits).

I'm thinking of having the driver ask the kernel for the (interrupt & 0xf)
instead of the actual interrupt reported by the PCI chipset, if it's free.

Can you suggest a way to get the card to issue an interrupt WITHOUT having
to do a data transfer, to check this?

> The problem seems for me VERY specific for the given PCI chipset in an
> alpha.

I'll investigate this motherboard's PCI chipset.

> > I don't know what the guy is talking about when he says "quadword access"
> > since this would be a 64-bit transfer and it's a 32-bit card.  I assume that
> > the DMA chip must be feeding data to it in a bad fashion, but I'm at a loss
> > as to how to proceed if this is the case.
> 
> I also don't know what "quadword access" means. You can try to add
> recommended mb() calls after all out() calls in es1370.c.

I'll try that.  I got some more info:

> A quadword access by the processor gets translated into a burst of two
> 32-bit transfers on the PCI bus.  A burst consists of a starting address
> followed by multiple data transfers.  What is supposed to happen is that
> both the initiator and target increment the address (so it doesn't have
> to be sent for each data transfer).  What the Ensoniq chips do is transfer
> the first data item, then attempt to terminate the transfer, but in a way
> that violates the PCI specification.

I don't understand how the data transfer is taking place.  There seems to be
no code <that I can find> that actually *does* the data transfer, and thus I
*think* the PCI chipset is taking care of it.

It appears to me that the es1370 card initiates the transfer, after being
fed the address of the memory region?  <right?>

As the docs are exceedingly sparse, can you help me by explaining:

What is XCTL1/SERR and how are they used (bits 30 and 1 respectively of port
00H).

What is CCB_INTRM (bit 10 of port 00H) sounds like it might be useful as I
think the hang is due to CCB/PCIB transfer, but I don't know what "voice
interrupts" are.

If this guy is correct in that the ES1370 incorrectly terminates the
transfer, and hangs the bus, is there anything that you can think of that
might fix it?  Any way to modify how the card transferrs data?

thanks again,
-- Bob

P.S. I'm not on the alsa-devel list, so if anyone else replies to this,
please CC me.

Bob McElrath (rsmcelrath@students.wisc.edu) Univ. of Wisconsin at Madison



