Reading acpi memory from a driver attached to hostb

[John Baldwin]

On Thursday 23 July 2009 10:25:40 am 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:
> | > > | 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.

In this case hostbX's grandparent is always pciX (usually pci0) and the PCI 
bus driver just passes through requests that come from grandchildren w/o 
trying to match the rid to a BAR.

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

This is true.  However, to attach to acpi you generally need some device_t 
device to attach to.  You could create a fictitious device via an identify 
routine, but I think that would be a far bigger hack than just doing the 
device_get_parent() bit in your hostbX driver's probe routine.

-- 
John Baldwin