From owner-freebsd-hackers@FreeBSD.ORG Tue May 6 16:28:37 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D323EE3 for ; Tue, 6 May 2014 16:28:37 +0000 (UTC) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.23]) by mx1.freebsd.org (Postfix) with ESMTP id F162365A for ; Tue, 6 May 2014 16:28:36 +0000 (UTC) Received: (qmail 45247 invoked by uid 1000); 6 May 2014 16:21:54 -0000 Date: 6 May 2014 16:21:54 -0000 Message-ID: <20140506162154.45246.qmail@mailgate.gta.com> From: lab@gta.com (Larry Baird) To: jhb@freebsd.org (John Baldwin) Subject: Re: apu1c led driver In-Reply-To: <201405051403.20390.jhb@freebsd.org> User-Agent: tin/2.2.0-20131224 ("Lochindaal") (UNIX) (FreeBSD/9.2-RELEASE-p5 (i386)) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 16:28:37 -0000 >> Generally rather than specifying the physical addresses as constants in >> the device driver, the address space and/or IO port resources are >> managed by the driver for the bus the device sits on. For something >> like LEDs and GPIOs that aren't self-identifying devices on a bus and >> aren't described by ACPI or other system-provided metadata, the 'hints' >> mechanism gives you a way to provide the resource metadata >> in /boot/loader.conf. >> >> The device.hints(5) manpage has some helpful info. Typically you need >> to provide an 'at' hint to say which bus the device is on. I'm not sure >> what's right for your LED/GPIO device; I've only ever used at=isa. For >> your device, it looks like you also need maddr/msize hints, then >> bus_alloc_resource_any() with an rid of 0 and a type of MEMORY should >> get you a bus_space handle for hardware access. > > ISA devices can hardcode ports this way, but this is written as a PCI driver, > so it isn't going to work. Larry, you can try changing your driver to be > an ISA driver by changing the second arg to DRIVER_MODULE() from 'pci' to > 'isa'. Is there a way you can probe something or check a BIOS string to > detect this driver? If so, you should auto-create a device from an identify > routine (then you don't need any hints). Your probe routine should fail for > ISA devices with a PNP ID so you don't attach to random things like serial > ports, etc. Switching to using an identify routine simplifies things a lot. Thank you for the hint. Larry -- ------------------------------------------------------------------------ Larry Baird Global Technology Associates, Inc. 1992-2012 | http://www.gta.com Celebrating Twenty Years of Software Innovation | Orlando, FL Email: lab@gta.com | TEL 407-380-0220