Date: Tue, 12 Mar 2002 01:47:24 +0100 From: Valery Kotchiev <AGGREGATOR.remove@this.NOSPAM.DK> To: freebsd-multimedia@freebsd.org Subject: Gpio register and the strange tsleep() behavior Message-ID: <20020312014724.A17222@rudiment.dk>
next in thread | raw e-mail | index | archive | help
Hi
I am trying to write a driver for my tv-tuner's (bktr) remote control.
Because the hardware is unable to raise an interrupt when the remote has
detected a keypress the driver has to poll the GPIO port for a flipped
"data waiting" bit.
The problem is that as soon as I reschedule the polling process using
tsleep() the data-ready bit is not getting activated.
If I replace the tsleep() calls with busy wating DELAY() calls which
don't yield the CPU, then everything starts working correctly (If one of
course disregards the system freeze while kernel is running in a tight
loop).
I've disassembled windows drivers and looked at the Linux infrared
driver project (www.lirc.org) and they are both handling the hardware in
exactly the same way as my driver does it.
So the preliminary diagnose is that something is resetting bktr's GPIO
register when my process shedules out.
I can not imagine the bktr driver doing that because no userspace
programs were using the tv-tuner while I was testing.. and it would be
silly for the bktr driver to continuiously reset its hardware registers
for a good measure.
So should I submerge deeper into the bktr source.. or are there some
other BSD kernel subsystems which reset the hardware which does not
belong to them?
thanks in advance
Valery Kotchiev
--
_________________________________________________________________________
Valery Kotchiev Computer Science / Chemistry student
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020312014724.A17222>