From owner-freebsd-multimedia Mon Mar 11 16:44:34 2002 Delivered-To: freebsd-multimedia@freebsd.org Received: from mail.rudiment.dk (rudiment.egmont-kol.dk [130.225.237.12]) by hub.freebsd.org (Postfix) with ESMTP id D53B437B400 for ; Mon, 11 Mar 2002 16:44:30 -0800 (PST) Received: by mail.rudiment.dk (Postfix, from userid 101) id 33D0211F8B; Tue, 12 Mar 2002 01:47:24 +0100 (CET) Date: Tue, 12 Mar 2002 01:47:24 +0100 From: Valery Kotchiev To: freebsd-multimedia@freebsd.org Subject: Gpio register and the strange tsleep() behavior Message-ID: <20020312014724.A17222@rudiment.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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