linux-mips-fnet
[Top] [All Lists]

Re: SCSI driver + wbflush question..

To: linux-mips@fnet.fr
Subject: Re: SCSI driver + wbflush question..
From: Richard van den Berg <R.vandenBerg@inter.NL.net>
Date: Mon, 17 May 1999 00:53:47 +0200 (MET DST)
In-reply-to: <Pine.LNX.3.96.990516194450.30817E-100000@skynet.csn.ul.ie>
Hello Dave,

On Sun, 16 May 1999, Dave Airlie wrote:

>       Today I got the drive-ID strings from the SCSI card, they are
> complete but the SCSI type is still unknown ...
> 
> So I have a few questions, in NCR53C9X.c, wbflush is #defined to something
> for the IOASIC decstations... What does this wbflush mean?, If I replace
> it with a #include <asm/wbflush.h> I don't get my drive strings any more,
> so for a start what exactly is wbflush for (i.e. when should it be called)
> and for non-IOASIC decs what should I be doing?

Hope Haralds following posting explains it.

Regards,
Richard


>From harald.koerfgen@netcologne.de Mon May 17 00:49:16 1999
Date: Fri, 16 Oct 1998 12:44:42 +0200 (MEST)
From: Harald Koerfgen <harald.koerfgen@netcologne.de>
Reply-To: linux-mips@fnet.fr
To: linux-mips@fnet.fr
Subject: R3000 and wbflush (was: DZ-11 interrupts)
Resent-Date: Fri, 16 Oct 1998 12:49:18 +0200 (MET DST)
Resent-From: linux-mips@fnet.fr

Hi Tom, fellow DECstation hackers

On 15-Oct-98 Thomas Riemer wrote:
> Ok - after playing with the dz serial device -
> 
> I'm getting effectively nowhere -
> I have enabled the UART scan
> I have enabled the transmit.
> 
> I can force one character across - but as far
> as I can tell the interrupt that is supposed to be generated
> when the dz11 is ready to process another character never happens.
> 
> I'm guessing that somehow we are not catching it.  
> 
> What's the best way to approach this?  How do I find out what's
> going on under the hood?

Your problem might be another one. The R3000 Family processors (including the 
R2000)
have a four word writeback buffer which usually is transparent to memory 
accesses,
but may have side effects when dealing with hardware registers.

Example: Let's assume data and status to be two hardware registers and writing
something to data has an influence on the content of the status register. A code
snippet like:

        data = whatever;
        if (status == OK)
                do_something();

might fail because it cannot be guaranteed that the write access to data happens
before the read access from status.

The solution to this problem is to wait until the writeback buffer is empty 
i.e.,
all write accesses are done. Unfortunately the mechanism for this is hardware
implementation specific and the DECstation engineers chose four different ways 
to do
this. You might want to look at arch/mips/dec/wbflush.c.

To make a long story short, the above code snippet should look like:

#include <asm/dec/wbflush.h>

        data = whatever;
        wbflush();
        if (status == OK)
                do_something();


If you have to write to several hardware registers in a certain sequence, you 
have
to wait for the writeback buffer to be empty too. For example:

        reg_1 = a_value;
        wbflush();
        reg_2 = another_value;

when the access to reg_1 should be done before the access to reg_2.

Hope this helps.
---
Regards,
Harald


<Prev in Thread] Current Thread [Next in Thread>