Date: Thu, 23 Jul 2009 19:53:51 +0200 From: Andre Albsmeier <Andre.Albsmeier@siemens.com> To: Doug Ambrisko <ambrisko@ambrisko.com> Cc: freebsd-hackers@freebsd.org, Andre Albsmeier <Andre.Albsmeier@siemens.com> Subject: Re: Reading acpi memory from a driver attached to hostb Message-ID: <20090723175351.GA70584@curry.mchp.siemens.de> In-Reply-To: <200907231425.n6NEPeRH026492@ambrisko.com> References: <200907230835.50814.jhb@freebsd.org> <200907231425.n6NEPeRH026492@ambrisko.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] John, apparently you sent me an email (thanks a lot) which I never received (we have to blame our company's spam filters which I do not control). I'll comment on it here in my reply to Doug... On Thu, 23-Jul-2009 at 07:25:40 -0700, Doug Ambrisko wrote: > John Baldwin writes: > | On Thursday 23 July 2009 2:08:35 am Andre Albsmeier wrote: > | > On Wed, 22-Jul-2009 at 09:48:56 -0700, Doug Ambrisko wrote: > | > > Andre Albsmeier writes: > | > > | > stripping some elder stuff > | > > | > | > > | 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 > | > | Did you try > | doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in your > | driver that is a child of hostb0? I tried this, well, something similar: I had to do 4 times device_get_parent() to end up at acpi0: mydriver -> hostb0 -> pci0 -> pcib0 -> acpi0 > > That should basically work since almost everything is a child of acpi. Thats what I hoped indeed. It would be a lot simpler than working with two drivers which have to communicate with each other. > However, the depth could change so running through the device_get_parent > and then checking the name might be good. I thought the same so I decided to lookup the acpi devclass and then acpi0 from there. To be sure, I compared the resulting pointers of acpi0 with the one found after the four device_get_parent(). They were the same. > > BTW, there is an example in sys/compat/linsysfs/linsysfs.c > in which I run the entire bus tree via linsysfs_run_bus which is > recursive and started from linsysfs_init. > > As John and I say, you don't need to "attach" to acpi just allocate > what you need, access it, then release it. If you need to hold on > it then it becomes more involved. Since you never attach then you > don't need to dettach just release the resources you grabbed ( > ie. bus_release_resource what you bus_alloc_resource). Well, then I still must be doing something wrong. I have attached my driver skeleton which does the following: 1. device_identify() which does a device_add_child() if needed 2. device_probe() which just tries to bus_alloc_resource() a SYS_RES_MEMORY resource from acpi0. If it works (which never does :-(), call bus_release_resource(). device_probe() always returns ENXIO so the whole driver never attaches. Especially in device_probe() I do: 1. Search for acpi0. 2. List the resources of acpi0. I compared the list to my "devinfo -r" output and they are the same. 3. Take the first SYS_RES_MEMORY resource from the list in 2. and try to bus_alloc_resource() it. This never succeds. Maybe you find the bug in there, I run out of ideas. It's not much of code, most of it are device_printfs for debugging... I have also attached the Makefile in case someone wants to kldload it on his machine. I would be very interested if it worked there. Thanks to you and John, of course. -Andre [-- Attachment #2 --] KMOD = eccmon SRCS = eccmon.c device_if.h bus_if.h pci_if.h NO_MAN = 1 CFLAGS+=-DDEVEL .include <bsd.kmod.mk>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090723175351.GA70584>