Re: Reading acpi memory from a driver attached to hostb
On Thu, 23-Jul-2009 at 16:06:11 -0400, John Baldwin wrote:
On Thursday 23 July 2009 1:53:51 pm Andre Albsmeier wrote:
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...
Yes, I saw the bounces. Hopefully you see the list version of this.
Yes, I've been lucky this time.
| 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
You don't actually need to do that. pci0 will pass the request up to acpi0
That's what I hoped as well.
eventually. You just need to ask pci0 to allocate it for you and it will see
you are not a direct child and take the 'passthrough' case here:
struct resource *
pci_alloc_resource(device_t dev, device_t child, int type, int *rid,
u_long start, u_long end, u_long count, u_int flags)
{
...
if (device_get_parent(child) != dev)
return (BUS_ALLOC_RESOURCE(device_get_parent(dev), child,
type, rid, start, end, count, flags));
...
}
Rather than trying to allocate the whole chunk of the ACPI resource, I would
just do a specific allocation like so:
rid = 0;
res = BUS_ALLOC_RESOURCE(device_get_parent(device_get_parent(dev)),
dev, SYS_RES_MEMORY, rid, the real start address, the real
end address, the length, RF_ACTIVE);
OK, I have modified my driver exactly this way, but still no success.
It seems my code didn't make it to the list (the attachment
was stripped) so I include it inline now. Testing is quite
simple, every feedback is welcome:
1. check if devinfo -r spits out some free I/O memory addresses
ranges under acpi0 with at minimum 4 bytes length.
2. select one of them and assign its start address to rstart in
eccmon_probe() at the line which reads now
u_long rstart = 0xfed14000;
(this is the address I use for testing)
3. compile, kldload and dmesg. I always get the message
bus_alloc_resource() returned NULL.
Thanks,
-Andre
eccmon.c start -
#include sys/param.h
#include sys/systm.h
#include sys/module.h
#include sys/kernel.h
#include machine/bus.h
#include sys/bus.h
#include sys/rman.h
#include machine/pci_cfgreg.h
#include dev/pci/pcivar.h
#include dev/pci/pcireg.h
struct eccmon_softc {
device_t dev;
int res_set;/* flag if bus_set_resource() was used
successfully */
struct resource* res;
int rid;
};
/**/
/* eccmon_probe() */
/**/
static int eccmon_probe( const device_t const dev )
{
u_long rstart = 0xfed14000;
int ret;
struct resource* res;
int rid = 0;
device_printf( dev, probe: started for %x:%x\n, pci_get_vendor( dev ) ,
pci_get_device( dev ) );
/*
* try to bus_alloc_resource the resource and give it back
*/
if( (res = BUS_ALLOC_RESOURCE( device_get_parent(device_get_parent(dev)),
dev, SYS_RES_MEMORY, rid, rstart, rstart+4, 4, RF_ACTIVE )) == NULL ) {
device_printf( dev, bus_alloc_resource() returned NULL\n );
return ENXIO;
}
if( (ret = BUS_RELEASE_RESOURCE( device_get_parent(device_get_parent(dev)),
dev, SYS_RES_MEMORY, rid, res )) != 0 )
device_printf( dev, bus_release_resource() returned %d\n, ret );
return ENXIO;
}
/***/
/* eccmon_attach() */
/***/
static int eccmon_attach( const device_t const dev )
{
device_printf( dev, attach: started for %x:%x\n, pci_get_vendor( dev ) ,
pci_get_device( dev ) );
return ENXIO;
}
/***/
/* eccmon_detach() */
/***/
static int eccmon_detach( const device_t const dev )
{
device_printf( dev, detach: started for %x:%x\n, pci_get_vendor( dev ) ,
pci_get_device( dev ) );
return 0;
}
/*/
/* eccmon_identify() */
/*/
static void eccmon_identify( driver_t *driver, device_t p )
{
device_printf( p, identify: start: %x %x\n, pci_get_vendor( p ),
pci_get_device( p ) );
device_printf( p, identify on: %s %d\n, device_get_name( p ),
device_get_unit(p) );
if( device_find_child( p, eccmon, -1 ) == NULL
strcmp( device_get_name( p ), hostb ) == 0
device_get_unit( p ) == 0 ) {
device_t child = device_add_child( p, eccmon, -1 );
device_printf( p, identify added child: %p\n, child );
}
}
/***/
/* driver(9) stuff */
/***/
static device_method_t eccmon_methods[] = {
DEVMETHOD( device_identify, eccmon_identify ),
DEVMETHOD( device_probe, eccmon_probe ),
DEVMETHOD(
Re: Reading acpi memory from a driver attached to hostb
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
Re: Reading acpi memory from a driver attached to hostb
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
Re: Reading acpi memory from a driver attached to hostb
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
Re: Reading acpi memory from a driver attached to hostb
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
Re: Reading acpi memory from a driver attached to hostb
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:
Re: Reading acpi memory from a driver attached to hostb
On Thursday 23 July 2009 1:53:51 pm Andre Albsmeier wrote:
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...
Yes, I saw the bounces. Hopefully you see the list version of this.
| 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
You don't actually need to do that. pci0 will pass the request up to acpi0
eventually. You just need to ask pci0 to allocate it for you and it will see
you are not a direct child and take the 'passthrough' case here:
struct resource *
pci_alloc_resource(device_t dev, device_t child, int type, int *rid,
u_long start, u_long end, u_long count, u_int flags)
{
...
if (device_get_parent(child) != dev)
return (BUS_ALLOC_RESOURCE(device_get_parent(dev), child,
type, rid, start, end, count, flags));
...
}
Rather than trying to allocate the whole chunk of the ACPI resource, I would
just do a specific allocation like so:
rid = 0;
res = BUS_ALLOC_RESOURCE(device_get_parent(device_get_parent(dev)),
dev, SYS_RES_MEMORY, rid, the real start address, the real
end address, the length, RF_ACTIVE);
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Reading acpi memory from a driver attached to hostb
on 18/07/2009 17:06 Julian Elischer said the following: Andre Albsmeier wrote: 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 ); try both with different devclass and other args. Just to expand on Julian's words. You can create eccmon and e.g. eccmon_acpi such that they are different drivers (on different buses) in newbus sense, but logically they can share data or otherwise cooperate. /sys/dev/cpufreq/ichss.c prior to rev. 177041 used to be like that. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Reading acpi memory from a driver attached to hostb
On Mon, 20-Jul-2009 at 14:05:34 +0300, Andriy Gapon wrote: on 18/07/2009 17:06 Julian Elischer said the following: Andre Albsmeier wrote: 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 ); try both with different devclass and other args. Just to expand on Julian's words. You can create eccmon and e.g. eccmon_acpi such that they are different drivers (on different buses) in newbus sense, but logically they can share data or otherwise cooperate. Very interesting code, I still haven't understood all of it but we will see... This could be the solution -- however, if somebody knows a more simple way, please let me know. Thanks, -Andre /sys/dev/cpufreq/ichss.c prior to rev. 177041 used to be like that. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- Amateurs like Linux, but professionals prefer FreeBSD. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Reading acpi memory from a driver attached to hostb
On Saturday 18 July 2009 9:39:38 am Andre Albsmeier wrote:
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..
I think you want to probably patch hostb0 to let bus_set_resource() work and
then use that. You could also just explicitly by-pass hostb0 and allocate a
resource from its parent as a quick hack. The PCI bus should pass the requst
up to acpi0. That is, do:
BUS_ALLOC_RESOURCE(device_get_parent(device_get_parent(dev)), dev, ...);
instead of
bus_alloc_resource(dev, ...);
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Reading acpi memory from a driver attached to hostb
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.
Thanks,
-Andre
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Reading acpi memory from a driver attached to hostb
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 ?
--
Rui Paulo
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Reading acpi memory from a driver attached to hostb
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..
Thanks again,
-Andre
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Reading acpi memory from a driver attached to hostb
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 );
try both with different devclass and other args.
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.
Thanks,
-Andre
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Reading acpi memory from a driver attached to hostb
Andre Albsmeier wrote: [CC'ing this to Rui Paulo since he tried to help me a while ago] I have written a driver that is a child of hostb (similar to agp) for RELENG_7. However, on some chipsets (e.g. i975) it has to read some memory locations (not pci configuration space) which were registered by acpi as system resources. Since my driver is a child of hostb0, I have no idea of how to access this memory area. Here is a devinfo -r to make things clear: nexus0 acpi0 Interrupt request lines: 9 I/O ports: 0x10-0x1f 0x22-0x3f ... 0x800-0x87f I/O memory addresses: 0xc-0xd 0xe-0xf 0xf000-0xf3ff 0xfec0-0xfec00fff 0xfed13000-0xfed19fff --- the memory needed 0xfed1c000-0xfed1 0xfed2-0xfed3 0xfff0-0x cpu0 coretemp0 acpi_throttle0 ACPI I/O ports: 0x810-0x813 cpufreq0 cpu1 coretemp1 pcib0 pci0 I/O ports: 0x170-0x177 0x376 hostb0 I/O memory addresses: 0xe400-0xe7ff MYDRIVER0 --- my driver agp0 pcib1 pci7 vgapci0 Interrupt request lines: 16 I had the same problem under RELENG_6 six month ago which could be solved by a bus_set_resource() but since the driver now attaches to hostb, this is not possible anymore. 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? Thanks a lot for all ideas, -Andre You can probably make two drivers in one which cooperate to allow access to both sets of resources. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
