Path: utzoo!utgpu!watmath!clyde!att!rutgers!tut.cis.ohio-state.edu!bloom-beacon!apple!voder!pyramid!hplabs!hpda!hpcupt1!hpisoa1!suzyz
From: suzyz@hpisoa1.HP.COM (Susan Dedo)
Newsgroups: comp.sys.hp
Subject: Re: GPIO (AFI) Interface Problem with HP9000s825 R2.0
Message-ID: <3800009@hpisoa1.HP.COM>
Date: 1 Dec 88 02:21:24 GMT
References: <104@bnr-vpa.UUCP>
Organization: Hewlett Packard, Cupertino
Lines: 69


> 1) The gpio will adequately read [...].  HP had
>    promised that the aquisition rate would be maintained continuously,
>    for a read to memory, limited only by the size of physical memory
>    available.

Hmmm.  Sounds like your local SE needs to be contacted.  If you are an 
SE, call the Series 800 on-line support group.



> 2) Software interrupts do not interrupt a read or write on the gpio.
>    As a single transaction can last many seconds (5M @ 100K/sec =
>    50 seconds), the ability to interrupt in the middle is important.

What is meant by "software interrupt", Control-C?  Sigalarm?
I/O is not always interruptable.  At some point during the I/O, the 
driver sleeps at a non-interruptable priority.  This is a must.  
Imagine I/O in the simpilist of terms:

    io_routine ()
      {
	lock memory for I/O
	start the I/O
	sleep
	unlock the memory
      }

First the memory is locked, then the I/O is started.  Next we sleep
waiting for the hardware to complete.  Suppose a signal, say ^C, is 
received.  When a process receives a signal it has some choices of
how to handle that signal, depending upon its state (running, runable,
sleeping, zombie).  The process can either:

  1. immediately jump out of io_routine() and return back to who ever called
     io_routine().  In such a case, the locked memory would never be unlocked.
     This is a bad thing to happen.

  2. return to the instruction immediately following the call to sleep().
     In this case, "unlock the memory".  So now the memory is unlocked and
     could be allocated to someone else.  Problem: the hardware is still 
     writing to what it believes is the locked memory allocated for its I/O.
     This is a very bad thing to happen.

Our solution: do not allow this instance of "sleep" to be interrupted.

The only way to inform the hardware that it should prematurely stop,
is to have the I/O transaction timeout.  Then the driver has the ability 
to stop the hardware.  I would suggest that your transactions be broken 
down into smaller chunks, but it appears doing so will cause data loss.



> 3) Hardware interrupts do not seem to be supported.  Neither the EIR
>    (external int. request) line not the two status lines (ST0, ST1),
>    seem to be able to interrupt the gpio.
> 

Where are you reading this information, a manpage?  (What manpage?)
The reason I ask is that the 27114A can not interrupt via the ST0 or 
ST1 lines.  The card can only interrupt, once the card is enabled to 
recognize interrupts, by the peripheral pulling on the ATTN line.  

How is the card enabled to interrupt (What commands are you using)?


 ----------------------------------------------------------------

 Susan Dedo