From owner-freebsd-hackers Sat Nov 8 21:20:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA15082 for hackers-outgoing; Sat, 8 Nov 1997 21:20:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from trojanhorse.ml.org (mdean.vip.best.com [206.86.94.101]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA15066 for ; Sat, 8 Nov 1997 21:20:34 -0800 (PST) (envelope-from jamil@trojanhorse.ml.org) Received: from localhost (jamil@localhost) by trojanhorse.ml.org (8.8.7/8.8.5) with SMTP id VAA01098; Sat, 8 Nov 1997 21:20:16 -0800 (PST) Date: Sat, 8 Nov 1997 21:20:15 -0800 (PST) From: "Jamil J. Weatherbee" To: dufault@hda.com cc: hackers@freebsd.org Subject: LabPC+ Driver Specifics Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am currently in the process of writing a driver for an analog input board and am using your labpc driver as an example (I have a labpc also). I am kind of curious about your buffer management. It appears that you are using the onboard fifo for buffering and depending on the user to make bio buffers available for writing out the fifo once they open the device. If they don't make buffers available frequently enough through read() then you have a problem. Here are some questions I have, because I think your driver is good example and I don't feel a need to make any unnecessary mistakes in design that conversing with you could save me. One thing is the AD_MICRO_PERIOD_SET, does that change the frequency for the entire board or just one channel. Is that general enough? In my case I have 128 channels so It is going to get pretty complex managing 128 channels at 128 different frequencies (with one clock). Secondly, I don't have a fifo, however I have interrupts driven through a 8253 chain. I assume than the best thing is for me to pick a decent fifo size and manage it like the labpc hardware manages its fifo. Would that be like 512*(128/8) = 8kb? The particular board is not capable of more than 30000 samples/s. I was thinking of implementing an AD_START and AD_STOP ioctls(), or am I missing something? I noticed , it looks like your chaining together buffers passed to your strategy routine. Can you breifly explain what is going on there with tqe.next (b_actf), I realize this is part of the queue management MACROS, but I don't think you are actually using those. I just want a qualitative description since I am pretty unclear on the hardware level stuff of the labpc. If your ad channels just start spewing when you open, then why don't you implement readselect, why just leave it to seltrue? If your trying to read all 8 channels this just might be useful to determine which order.