Date: Mon, 11 Mar 2002 16:33:36 +0100 From: Valery Kotchiev <AGGREGATOR.remove@this.NOSPAM.DK> To: questions@freebsd.org Subject: Gpio register and the strange tsleep() behavior Message-ID: <20020311163336.A14912@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-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020311163336.A14912>