Reading acpi memory from a driver attached to hostb

[John Baldwin]

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?

-- 
John Baldwin