From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 20 21:35:59 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18839106566B; Mon, 20 Jul 2009 21:35:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C9BEF8FC0A; Mon, 20 Jul 2009 21:35:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 618CA46B5C; Mon, 20 Jul 2009 17:35:58 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id C00398A09E; Mon, 20 Jul 2009 17:35:57 -0400 (EDT) From: John Baldwin To: Andre Albsmeier Date: Mon, 20 Jul 2009 10:46:58 -0400 User-Agent: KMail/1.9.7 References: <20090717190450.GA4697@curry.mchp.siemens.de> <20090718133938.GA7802@curry.mchp.siemens.de> In-Reply-To: <20090718133938.GA7802@curry.mchp.siemens.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907201046.58558.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 20 Jul 2009 17:35:57 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.0 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_06_12,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org, Rui Paulo , Julian Elischer Subject: Re: Reading acpi memory from a driver attached to hostb X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 21:35:59 -0000 On Saturday 18 July 2009 9:39:38 am Andre Albsmeier wrote: > On Sat, 18-Jul-2009 at 10:25:06 +0100, Rui Paulo wrote: > > On 18 Jul 2009, at 09:10, Andre Albsmeier wrote: > > > > > On Fri, 17-Jul-2009 at 12:53:53 -0700, Julian Elischer wrote: > > >> Andre Albsmeier wrote: > > >>> [CC'ing this to Rui Paulo since he tried to help me a while ago] > > >>> > > >>> Since my driver is a child of hostb0, I have no idea of how to > > >>> access > > >>> acpi0's memory area. Here is a devinfo -r to make things clear: > > >>> > > >> ... > > >>> > > >>> Earlier, I was given the hint to attach as a child of acpi (see the > > >>> old mail attached below) but in this case I didn't have access to > > >>> the > > >>> hostb registers which I need as well. > > >>> > > >>> The only thing I see is: Attach two drivers -- one as child of acpi > > >>> and another as child of hostb and let them communicate somehow (no > > >>> idea how to do this). > > >>> > > >>> I have also done crazy things like searching for acpi0 and trying > > >>> to bus_alloc_resource() the memory I am interested in but this also > > >>> failed. > > >>> > > >>> Or is it possible to free(!) somehow the address space from acpi0 > > >>> and pass it to hostb0 so I can bus_alloc_resource() it? > > >>> > > >> > > >> You can probably make two drivers in one which cooperate to > > >> allow access to both sets of resources. > > > > > > Hmm, that's what I meant by: Attach two drivers -- one as child of > > > acpi > > > and another as child of hostb... > > > > > > And that's similar to Rui Paulo's suggestion a while ago: > > > > > >> You'll probably need to create a fake ACPI child driver to access it. > > >> > > >> Create your identify routine with something like: > > >> > > >> static void mydriver_identify(driver_t *driver, device_t parent) > > >> { > > >> if (device_find_child(parent, "mydriver", -1) == NULL && > > >> mydriver_match(parent)) > > >> device_add_child(parent, "mydriver", -1); > > >> } > > >> > > >> mydriver_match() should check if you were given the acpi0 device. > > > > > > But in order to attach to acpi0, I need to say > > > > > > DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, > > > NULL ); > > > > > > instead of > > > > > > DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, > > > NULL ); > > > > > > This way I could attach to acpi but not to hostb anymore.... > > > > > > I have searched the net for solutions, I have read newbus-draft.txt > > > and newbus-intro.txt and Warner Losh's newbus-led.c (thanks to all > > > of these my driver is working on other mainboards where it doesn't > > > have to access foreign memory) but didn't find anything. > > > > I'm out of ideas. > > John, do you know if this is a newbus limitation or if it can be > > worked around ? > > I assume it is possible somehow, I am just too stupid (it is the first > driver I wrote). John, for easy reference, here is my initial message: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029127.html > > Please remember all, that I need the access to the acpi0 memory location > only for a few reads during probing/attaching, not later. > > I have also read somewhere that, when resources are allocated, the > system "walks up" the device tree until it finds the resource. Since > my driver is below hostb0 and hostb0 is below acpi0 I thought it > should work but it doesn't.. I think you want to probably patch hostb0 to let bus_set_resource() work and then use that. You could also just explicitly by-pass hostb0 and allocate a resource from its parent as a quick hack. The PCI bus should pass the requst up to acpi0. That is, do: BUS_ALLOC_RESOURCE(device_get_parent(device_get_parent(dev)), dev, ...); instead of bus_alloc_resource(dev, ...); -- John Baldwin