Reading acpi memory from a driver attached to hostb

[Doug Ambrisko]

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:
| > > | 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
| 
| Did you try 
| doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in your 
| driver that is a child of hostb0?

That should basically work since almost everything is a child of acpi.
However, the depth could change so running through the device_get_parent
and then checking the name might be good.

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).

Doug A.