From owner-freebsd-arch@FreeBSD.ORG Mon Jan 26 22:16:26 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4720216A4D1 for ; Mon, 26 Jan 2004 22:16:26 -0800 (PST) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 8675243D68 for ; Mon, 26 Jan 2004 22:15:46 -0800 (PST) (envelope-from nate@root.org) Received: (qmail 31971 invoked by uid 1000); 27 Jan 2004 06:15:09 -0000 Date: Mon, 26 Jan 2004 22:15:09 -0800 (PST) From: Nate Lawson To: "M. Warner Losh" In-Reply-To: <20040126.202628.39465078.imp@bsdimp.com> Message-ID: <20040126221305.P31969@root.org> References: <20040126165523.W30461@root.org> <20040126.181720.15264443.imp@bsdimp.com> <20040126.202628.39465078.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: newbus ioport usage X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 06:16:26 -0000 On Mon, 26 Jan 2004, M. Warner Losh wrote: > In message: <20040126191657.B31071@root.org> > Nate Lawson writes: > : On Mon, 26 Jan 2004, M. Warner Losh wrote: > : > In message: <20040126165523.W30461@root.org> > : > Nate Lawson writes: > : > : Ok, I'm doing the set/alloc and it works. However, one weird thing. If I > : > : allocate all ports at boot time, it succeeds. My driver goes through > : > : multiple release/allocate cycles and it all works as expected. However if > : > : I boot and attach to only one of the registers, subsequent attempts to > : > : attach the second one fail. The resources are 2 IO ports, 0x101c and > : > : 0x101d. Both are 1 byte. > : > > : > Deos devinfo -r show any cause for the problem? Maybe you aren't > : > releasing them properly? Also, why not allocate them as a block of 2? > : > : Ok, I've found what's going on. Apparently my acpi_sysresource0 > : pseudo-device is claiming all resources in its _CRS method. If I don't > : boot with 0x101c and 0x101d attached, it attaches to 0x1010-0x109d. But > : if I boot attaching them, it reserves less of the range. > : > : acpi_cpu0 > : I/O ports: > : 0x101c > : 0x101d > : > : acpi_sysresource0 > : I/O ports: > : 0x10-0x1f > : 0x24-0x25 > : 0x28-0x29 > : 0x2c-0x2d > : 0x2e-0x2f > : 0x30-0x31 > : 0x34-0x35 > : 0x38-0x39 > : 0x3c-0x3d > : 0x50-0x53 > : 0x72-0x77 > : 0x90-0x9f > : 0xa4-0xa5 > : 0xa8-0xa9 > : 0xac-0xad > : 0xb0-0xb5 > : 0xb8-0xb9 > : 0xbc-0xbd > : 0x101e-0x109d > : 0x1180-0x11bf > : 0x15e0-0x15ef > : 0x1600-0x167f > : > : I'm not sure of a way around this. All ASL I've seen keeps these > : registers contiguous so I could whack out a block of 8 of them, although > : that doesn't seem correct. Perhaps acpi_cpu should be able to override > : the acpi_sysresource0 allocations, maybe by asking it for the resource if > : bus_resource_alloc returns NULL. Thoughts? > > Have acpi bus own the resources that acpi_sysresource0 uses. bus_set_resource(device_get_parent(dev), ...) ? > Allow children to get at parts of that as they see fit. Sounds good, but no idea how to implement this. Would I have to implement new parts to acpi_alloc_resource()? -Nate