From owner-freebsd-hackers@FreeBSD.ORG Thu Jul 23 06:08:40 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 1381C106564A for ; Thu, 23 Jul 2009 06:08:40 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by mx1.freebsd.org (Postfix) with ESMTP id 87F4F8FC08 for ; Thu, 23 Jul 2009 06:08:39 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n6N68Z5i013781; Thu, 23 Jul 2009 08:08:35 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail2.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n6N68Zo6010100; Thu, 23 Jul 2009 08:08:35 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.3/8.14.3) id n6N68ZLj010124; Date: Thu, 23 Jul 2009 08:08:35 +0200 From: Andre Albsmeier To: Doug Ambrisko Message-ID: <20090723060835.GB62628@curry.mchp.siemens.de> References: <20090718133938.GA7802@curry.mchp.siemens.de> <200907221648.n6MGmu58035040@ambrisko.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907221648.n6MGmu58035040@ambrisko.com> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-hackers@freebsd.org, Andre Albsmeier 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: Thu, 23 Jul 2009 06:08:40 -0000 On Wed, 22-Jul-2009 at 09:48:56 -0700, Doug Ambrisko wrote: > Andre Albsmeier writes: > | 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.. > > FWIW, you might look at ipmi(4) especially in some early states since > it can probe and attach in many ways (isa, acpi, pci etc.) and had to > figure out the best way to attach. Also it had various front ends. > If I recall correctly, I did a find for a driver (ie. acpi) then > select the first instance. Once you get that handle then you can > request device resources from it, get the info you need then release > that stuff. However, you won't get the module auto-loading part > that you would get if you created a module that depended on both. > That might get you enough of a hint. Also there are some generic > stuff to read various memory bits like SMBIOS areas etc. This is > used in ipmi(4) as well since the attachment can be defined in SMBIOS. > If you have a specific question, about why the driver did something > I should recall that. The ipmi(4) driver is in fairly clean. There > is some improvements I still need to do on probe/attachment that > causes a bogus ipmi1 at times. Thanks a lot for this interesting information. I see, things are more complicated than I thought. There is no easy way having a quick glance at "foreign" memory during probing. Now I have to figure out how to get the order of probing/attaching done. One thing I could do is: 1. attach mydriver_ACPI to acpi0 2. probe mydriver under hostb0, check if we need access to sysresources from acpi0 (depends on the chipset found). If no, goto 5. 3. ask mydriver_ACPI about stuff I want to know (HOW?) 4. tell mydriver to detach from acpi0 (HOW?) 5. attach mydriver to hostb0 and do my work What I would like more is something like: 1. probe mydriver under hostb0, check if we need access to sysresources from acpi0 (depends on the chipset found). If no, goto 3. 2. ask mydriver_ACPI to attach to acpi0, give me the info I want, detach mydriver_ACPI (HOW?) 3. attach mydriver to hostb0 and do my work Thanks, -Andre