Date: Wed, 19 Aug 1998 01:39:55 +0100 From: Karl Pielorz <kpielorz@tdx.co.uk> To: Julian Elischer <julian@whistle.com> Cc: hackers@FreeBSD.ORG Subject: Re: High? Latency device-driver with no IRQ's? Message-ID: <35DA1EDB.5D0E324F@tdx.co.uk> References: <Pine.BSF.3.95.980818124754.9917C-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > re: 30us delay... > > I presume that the this is not a permanent series of 30uSec delays, but > once per transaction, and that after the transaction, you can return to > the user.. The 30usec delays only happen when you change the card's configuration from one mode to another, this is pretty rare... > > > > The interrupt fires after every word has been transfered (it uses a 16 > > bit i/o port)... I'd gather this isn't to hot a thing to do? (causing > > excessive irq's) - > you are corrct, but we need more info. > like: > > how often is there data to be read, Flat out the card can aquire 2 bytes every 10us... I don't intend to use this 'simple' mode to read it at that rate though :-) > how much is available at a time? 2 bytes... :-( > does it come in bursts? Nope... > how much buffering is there on the card? None... (apart from a simple 2 byte latch) > how long does it take to service the card if it has full buffers? No buffers :-( > > am I better off waiting around in the kernel rather > > than issuing a sleep() only to be woken up 10us later? > > Sleep will probably not have the granularity you want > (sleep is in 10mSec units) (usually) I didn't think it would have... > tell us more.. > you may be able to use "aquire_timer0()" > to give yourself a 20KHz polling clock.. The stuff I'm working on at the moment pulls unbuffered samples off the card. The sequence goes: User process calls read() Write to the 'start' register... (10us delay) Data is ready and DATA_VALID (another register) get's set. Read 2 bytes from the card. Back to userland... -or- you can have: User process calls read() Write to the 'start' register... (10us delay) IRQ Generated & DATA_VALID get's set. Read 2 bytes from the card. Back to userland... This is the simplest mode the driver will run in. The card does support DMA - but I'm only just starting out writing drivers etc. at the moment, so I'd planned to 'keep it simple' for the first version - Hence I'm looking for the best way to handle the above... Someone here has suggest I move all the hanging around to userland, and either get the user process to wait 10us between reads, or provide some sort of ioctl interface for polling whether the next sample is ready... At the end of the day I would like to keep it the way it is at the moment as you can then do: cat /dev/daqb0 And just read the samples as they come in... Thanks for your help, Regards, Karl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35DA1EDB.5D0E324F>