obtaining acpi details outside of drivers/acpi

DISCUSSION Alan Hourihane 3 participants 9 messages Sep 6, 2007 ACPI

lore

Share & tools

lore

Alan Hourihane

author

2007-09-06 10:49 UTC #0 lore raw

I'm looking at the currently exported function calls to other kernel modules to obtain ACPI data.

For example, if I want to access _DOD for graphics, the pathname would be something like...

\\_SB_.PCI0.GFX0._DOD

And I'm currently doing this...

	status = acpi_evaluate_object(NULL, PATHNAME, NULL, &buffer);

where PATHNAME is the path above.

But there's no guarantees that it's called PCI0, or even GFX0.

What's the best way to search the namespace and get this data ??

Alan.

Len Brown

reviewer

2007-09-06 11:39 UTC #1 lore raw

Hi Alan,

Yes, pathnames are arbitrary, don't use them.

Look in drivers/acpi/video.c for acpi_video_bus_check() As the video device has no HID, this routine is basically used to check all the drivers in the tree if they have _DOD and the other stuff a video device should have.

BTW. I'm curious what you are trying to do.
There is actually quite a bit of movement in this code right now.

cheers,
-Len

Quoted 25 lines · Alan Hourihane

I'm looking at the currently exported function calls to other kernel modules to obtain ACPI data.
For example, if I want to access _DOD for graphics, the pathname would be something like...
\\_SB_.PCI0.GFX0._DOD
And I'm currently doing this...
	status = acpi_evaluate_object(NULL, PATHNAME, NULL, &buffer);
where PATHNAME is the path above.
But there's no guarantees that it's called PCI0, or even GFX0.
What's the best way to search the namespace and get this data ??
Alan.
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Alan Hourihane

author

2007-09-06 11:47 UTC #2 lore raw

Quoted 8 lines · Len Brown

Hi Alan,
Yes, pathnames are arbitrary, don't use them.
Look in drivers/acpi/video.c for acpi_video_bus_check() As the video device has no HID, this routine is basically used to check all the drivers in the tree if they have _DOD and the other stuff a video device should have.

Mmm. It seems acpi_video_bus_check() is static and therefore not available outside of video.c

Quoted 2 lines

BTW. I'm curious what you are trying to do.
There is actually quite a bit of movement in this code right now.

Think about fbdev drivers (or some video driver).... Rather than bang on the hardware to try and do auto-detection of devices, it's much easier (and sometimes required) to just ask the system BIOS via ACPI to see what devices are available.

I want to parse _DOD myself to see what's available in kernel space.

What else can I use ?

Alan.

Len Brown

reviewer

2007-09-06 13:19 UTC #3 lore raw

Quoted 6 lines · Alan Hourihane

Mmm. It seems acpi_video_bus_check() is static and therefore not available outside of video.c
Quoted 2 lines
BTW. I'm curious what you are trying to do.
There is actually quite a bit of movement in this code right now.

Quoted 6 lines

Think about fbdev drivers (or some video driver).... Rather than bang on the hardware to try and do auto-detection of devices, it's much easier (and sometimes required) to just ask the system BIOS via ACPI to see what devices are available.
I want to parse _DOD myself to see what's available in kernel space.

It would be good to have this code in only one place
and export it from there to other parts of the kernel that need it. I'd like to be able to not have fbdev drivers depend on the acpi video driver, so perhaps we could have some generic interface where fbdev is the consumer and in this case acpi/video.c is the provider?

-Len

Alexey Starikovskiy

2007-09-06 13:27 UTC #4 lore raw

Quoted 12 lines · Len Brown

Quoted 10 lines · Alan Hourihane
Mmm. It seems acpi_video_bus_check() is static and therefore not available outside of video.c
Quoted 2 lines
BTW. I'm curious what you are trying to do.
There is actually quite a bit of movement in this code right now.
Think about fbdev drivers (or some video driver).... Rather than bang on the hardware to try and do auto-detection of devices, it's much easier (and sometimes required) to just ask the system BIOS via ACPI to see what devices are available.

Quoted 7 lines

Quoted 1 line
I want to parse _DOD myself to see what's available in kernel space.
It would be good to have this code in only one place
and export it from there to other parts of the kernel that need it. I'd like to be able to not have fbdev drivers depend on the acpi video driver, so perhaps we could have some generic interface where fbdev is the consumer and in this case acpi/video.c is the provider?

There is module autoloading code in acpi/scan.c which might be helpful. Just look for acpi_video_bus_match().

Regards,
Alex.

Quoted 7 lines

(quoted diff) +0 -2
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Alan Hourihane

author

2007-09-06 13:53 UTC #5 lore raw

In reply to Len Brown

Quoted 13 lines · Len Brown

Quoted 11 lines · Alan Hourihane
Mmm. It seems acpi_video_bus_check() is static and therefore not available outside of video.c
Quoted 2 lines
BTW. I'm curious what you are trying to do.
There is actually quite a bit of movement in this code right now.
Think about fbdev drivers (or some video driver).... Rather than bang on the hardware to try and do auto-detection of devices, it's much easier (and sometimes required) to just ask the system BIOS via ACPI to see what devices are available.

Quoted 7 lines

Quoted 1 line
I want to parse _DOD myself to see what's available in kernel space.
It would be good to have this code in only one place
and export it from there to other parts of the kernel that need it. I'd like to be able to not have fbdev drivers depend on the acpi video driver, so perhaps we could have some generic interface where fbdev is the consumer and in this case acpi/video.c is the provider?

That sounds good. I'm open to suggestions on interface.

But is there anything better available now to scan the namespace in current released kernels for _DOD ?

Alan.

Alan Hourihane

author

2007-09-06 13:57 UTC #6 lore raw

Quoted 16 lines · Alan Hourihane

Quoted 15 lines · Len Brown
Quoted 12 lines · Alan Hourihane
Mmm. It seems acpi_video_bus_check() is static and therefore not available outside of video.c
Quoted 2 lines
BTW. I'm curious what you are trying to do.
There is actually quite a bit of movement in this code right now.
Think about fbdev drivers (or some video driver).... Rather than bang on the hardware to try and do auto-detection of devices, it's much easier (and sometimes required) to just ask the system BIOS via ACPI to see what devices are available.
I want to parse _DOD myself to see what's available in kernel space.

Quoted 7 lines

Quoted 5 lines
It would be good to have this code in only one place
and export it from there to other parts of the kernel that need it. I'd like to be able to not have fbdev drivers depend on the acpi video driver, so perhaps we could have some generic interface where fbdev is the consumer and in this case acpi/video.c is the provider?
That sounds good. I'm open to suggestions on interface.

I'm willing to help define this though, so I don't expect anyone to just throw something over the wall.

Quoted 2 lines

But is there anything better available now to scan the namespace in current released kernels for _DOD ?

Oh, and if not, not to worry. I'll stick with the fixed namespace check for now, until we can define the interface above.

Thanks Len!

Alan.

Alexey Starikovskiy

2007-09-06 14:17 UTC #7 lore raw

In reply to Alan Hourihane

Quoted 20 lines · Alan Hourihane

Quoted 12 lines · Len Brown
Quoted 10 lines · Alan Hourihane
Mmm. It seems acpi_video_bus_check() is static and therefore not available outside of video.c
Quoted 2 lines
BTW. I'm curious what you are trying to do.
There is actually quite a bit of movement in this code right now.
Think about fbdev drivers (or some video driver).... Rather than bang on the hardware to try and do auto-detection of devices, it's much easier (and sometimes required) to just ask the system BIOS via ACPI to see what devices are available.
Quoted 6 lines
Quoted 1 line
I want to parse _DOD myself to see what's available in kernel space.
It would be good to have this code in only one place
and export it from there to other parts of the kernel that need it. I'd like to be able to not have fbdev drivers depend on the acpi video driver, so perhaps we could have some generic interface where fbdev is the consumer and in this case acpi/video.c is the provider?

Quoted 4 lines

That sounds good. I'm open to suggestions on interface.
But is there anything better available now to scan the namespace in current released kernels for _DOD ?

2.6.23-rc5 has it...

Quoted 8 lines

Alan.
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Alan Hourihane

author

2007-09-06 14:33 UTC #8 lore raw

Quoted 21 lines · Alexey Starikovskiy

Quoted 20 lines · Alan Hourihane
Quoted 18 lines · Len Brown
Quoted 11 lines · Alan Hourihane
Mmm. It seems acpi_video_bus_check() is static and therefore not available outside of video.c
Quoted 2 lines
BTW. I'm curious what you are trying to do.
There is actually quite a bit of movement in this code right now.
Think about fbdev drivers (or some video driver).... Rather than bang on the hardware to try and do auto-detection of devices, it's much easier (and sometimes required) to just ask the system BIOS via ACPI to see what devices are available.
I want to parse _DOD myself to see what's available in kernel space.
It would be good to have this code in only one place
and export it from there to other parts of the kernel that need it. I'd like to be able to not have fbdev drivers depend on the acpi video driver, so perhaps we could have some generic interface where fbdev is the consumer and in this case acpi/video.c is the provider?

Quoted 5 lines

Quoted 4 lines
That sounds good. I'm open to suggestions on interface.
But is there anything better available now to scan the namespace in current released kernels for _DOD ?
2.6.23-rc5 has it...

Thanks Alexey,

I'll take a look.

Alan.