From owner-freebsd-current@FreeBSD.ORG Wed Aug 3 07:56:15 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 4F421106564A; Wed, 3 Aug 2011 07:56:15 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-4.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 39B24152C40; Wed, 3 Aug 2011 07:55:18 +0000 (UTC) Message-ID: <4E38FEE5.4080300@FreeBSD.org> Date: Wed, 03 Aug 2011 00:55:17 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:5.0) Gecko/20110723 Thunderbird/5.0 MIME-Version: 1.0 To: John Baldwin References: <4E23EE49.5040801@FreeBSD.org> <201107191116.07116.jhb@freebsd.org> <4E33A990.7040006@FreeBSD.org> <201108021806.04759.jhb@freebsd.org> In-Reply-To: <201108021806.04759.jhb@freebsd.org> X-Enigmail-Version: 1.2pre OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: ichwd0: unable to reserve GCS registers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 07:56:15 -0000 On 08/02/2011 15:06, John Baldwin wrote: > On Saturday, July 30, 2011 2:49:52 am Andriy Gapon wrote: >> on 19/07/2011 18:16 John Baldwin said the following: >>> Hmm, can you get devinfo -r output from a working kernel with ichwd loaded? >>> You might be able to just build the kernel with 'nooptions NEW_PCIB'. >> >> I believe that I've got a similar problem with amdsbwd(4). >> It needs some resources (I/O ports) that belong to ACPI. >> The problem is that the driver attaches to isa bus which is under >> isab->pci->pcib and those particular resources are not assigned to the Host-PCI >> bridge. >> >> I think that you already made a suggestion that perhaps isa bus should directly >> attach to acpi bus when acpi is available. Not sure if there are any >> alternative approaches. > > Can you try this: Not so much. :) the first and last patches I can apply to HEAD by hand, but /sys/dev/acpica/acpi_pcib_acpi.c is only 387 lines long, so I'm not even sure where to start. Any chance you could diff against HEAD? Doug > --- //depot/projects/pci/sys/dev/acpica/acpi.c 2011-06-25 12:05:19.000000000 0000 > +++ //depot/projects/pci/sys/dev/acpica/acpi.c 2011-08-02 20:21:42.000000000 0000 > @@ -1238,7 +1238,6 @@ > struct resource_list_entry *rle; > struct resource_list *rl; > struct resource *res; > - struct rman *rm; > int isdefault = (start == 0UL && end == ~0UL); > > /* > @@ -1291,15 +1290,29 @@ > } else > res = BUS_ALLOC_RESOURCE(device_get_parent(bus), child, type, rid, > start, end, count, flags); > - if (res != NULL || start + count - 1 != end) > - return (res); > > /* > * If the first attempt failed and this is an allocation of a > * specific range, try to satisfy the request via a suballocation > - * from our system resource regions. Note that we only handle > - * memory and I/O port system resources. > + * from our system resource regions. > */ > + if (res == NULL && start + count - 1 == end) > + res = acpi_alloc_sysres(child, type, rid, start, end, count, flags); > + return (res); > +} > + > +/* > + * Attempt to allocate a specific resource range from the system > + * resource ranges. Note that we only handle memory and I/O port > + * system resources. > + */ > +struct resource * > +acpi_alloc_sysres(device_t child, int type, int *rid, u_long start, u_long end, > + u_long count, u_int flags) > +{ > + struct rman *rm; > + struct resource *res; > + > switch (type) { > case SYS_RES_IOPORT: > rm = &acpi_rman_io; > @@ -1311,6 +1324,7 @@ > return (NULL); > } > > + KASSERT(start + count - 1 == end, ("wildcard resource range")); > res = rman_reserve_resource(rm, start, end, count, flags & ~RF_ACTIVE, > child); > if (res == NULL) > --- //depot/projects/pci/sys/dev/acpica/acpi_pcib_acpi.c 2011-07-22 18:19:55.000000000 0000 > +++ //depot/projects/pci/sys/dev/acpica/acpi_pcib_acpi.c 2011-08-02 20:21:42.000000000 0000 > @@ -541,6 +541,7 @@ > { > #ifdef NEW_PCIB > struct acpi_hpcib_softc *sc; > + struct resource *res; > #endif > > #if defined(__i386__) || defined(__amd64__) > @@ -549,8 +550,11 @@ > > #ifdef NEW_PCIB > sc = device_get_softc(dev); > - return (pcib_host_res_alloc(&sc->ap_host_res, child, type, rid, start, end, > - count, flags)); > + res = pcib_host_res_alloc(&sc->ap_host_res, child, type, rid, start, end, > + count, flags); > + if (res == NULL && start + count - 1 == end) > + res = acpi_alloc_sysres(child, type, rid, start, end, count, flags); > + return (res); > #else > return (bus_generic_alloc_resource(dev, child, type, rid, start, end, > count, flags)); > --- //depot/projects/pci/sys/dev/acpica/acpivar.h 2011-06-22 16:25:39.000000000 0000 > +++ //depot/projects/pci/sys/dev/acpica/acpivar.h 2011-08-02 20:21:42.000000000 0000 > @@ -382,6 +382,8 @@ > struct resource *res, ACPI_RESOURCE *acpi_res); > ACPI_STATUS acpi_parse_resources(device_t dev, ACPI_HANDLE handle, > struct acpi_parse_resource_set *set, void *arg); > +struct resource *acpi_alloc_sysres(device_t child, int type, int *rid, > + u_long start, u_long end, u_long count, u_int flags); > > /* ACPI event handling */ > UINT32 acpi_event_power_button_sleep(void *context); > -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/