From alsa-devel-owner@alsa.jcu.cz  Wed Mar 10 10:02:47 1999
Received: from entry.jcu.cz (IDENT:perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id KAA30358;
	Wed, 10 Mar 1999 10:01:59 +0100
Date: Wed, 10 Mar 1999 10:01:59 +0100 (CET)
From: Jaroslav Kysela <perex@jcu.cz>
To: Bob McElrath <mcelrath@draal.physics.wisc.edu>
cc: alsa-devel@alsa.jcu.cz
Subject: Re: AudioPCI ALSA driver on ALPHA
In-Reply-To: <Pine.LNX.4.04.9903092105230.1086-100000@draal.physics.wisc.edu>
Message-ID: <Pine.LNX.3.96.990310093754.5846B-100000@entry.jcu.cz>
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 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.

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

> 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.

For example:

#define mb_outl(val, reg) do { outl(val, reg); mb(); } while (0)

and replace all outl() in es1370.c with mb_outl()

The mb() function means a memory barrier and writing to slow (bus) devices
is queued on some alphas. The mb() call flushes this queue.

							Jaroslav

-----
Jaroslav Kysela <perex@jcu.cz>
Academic Computer Centre, University of South Bohemia
Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic


