Date: Thu, 23 Jul 1998 09:36:27 -0700 From: john@ece.arizona.edu (John Galbraith) To: randal@comtest.com Cc: dufault@hda.com, mike@smith.net.au, FreeBSD-hardware@FreeBSD.ORG, john@ece.arizona.edu Subject: Re: new GPIB driver Message-ID: <199807231636.JAA10489@burdell.ece.arizona.edu> In-Reply-To: <199807230102.PAA23786@oldyeller.comtest.com> (randal@comtest.com)
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "Randal" == Randal S Masutani <randal@comtest.com> writes:
Randal> So what exaclty do you have implemented? What functions
Randal> do you have in ioctl()?
Besides the main I/O, I have ioctl's to do bus management stuff like
interface clear (IFC), triggering (GET), serial poll, and all that. I
also have in the pipeline an ioctl to set up the controller parameters
like
1) interrupt timeout
2) poll timeout
3) end of string (EOS) byte
4) termination stuff (EOI, EOS)
5) controller's GPIB address (right now it defaults to the minor
number - lame)
6) T1 delay
7) more?
There will probably be a gp_info structure that holds all this info,
and an ioctl that fills the structure with the current configuration,
and another to set it.
After reading last night's posts, I definitely want to move the I/O into
write() and read() with better usage of the minor numbers. That is a
much better way to go all around.
As far as the I/O goes, I plan on having three types:
programmed I/O with polling, programmed I/O with interrupts, and DMA
transfers with interrupts. Currently, the two programmed routines
work (both read and write) and I am working on the DMA routine. The
polling routine was mainly to get the driver working initially - I
doubt people will use it very often. The driver selects which one to
use based on if it was configured with an interrupt and DMA channel or
not.
I also have quite a bit of debugging stuff in there. A large portion
of the code gets preprocessed out if debugging is turned off. I found
these cards to be kind of difficult to program due to the huge
number of different registers and possibilities. There really are a
lot of features on these cards, and if you don't configure each of
them exactly like you want, things don't work. On the other hand, a
lot of the work of bus management is done in hardware, so the driver
is actually simplified once you get it configured correctly. All this
just led to a lot of debugging code in there.
John
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807231636.JAA10489>