obtaining acpi details outside of drivers/acpi

obtaining acpi details outside of drivers/acpi

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

Re: obtaining acpi details outside of drivers/acpi

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

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

On Thursday 06 September 2007 06:16, Alan Hourihane wrote:
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: obtaining acpi details outside of drivers/acpi

[Alan Hourihane]

On Thu, 2007-09-06 at 07:43 -0400, Len Brown wrote:
> 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

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

Re: obtaining acpi details outside of drivers/acpi

[Len Brown]

On Thursday 06 September 2007 07:47, Alan Hourihane wrote:

> Mmm. It seems acpi_video_bus_check() is static and therefore not
> available outside of video.c
> 
> > 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?

-Len

Re: obtaining acpi details outside of drivers/acpi

[Alexey Starikovskiy]

Len Brown wrote:
> On Thursday 06 September 2007 07:47, Alan Hourihane wrote:
> 
>> Mmm. It seems acpi_video_bus_check() is static and therefore not
>> available outside of video.c
>>
>>> 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?
There is module autoloading code in acpi/scan.c which might be helpful.
Just look for acpi_video_bus_match().

Regards,
Alex.

> 
> -Len
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: obtaining acpi details outside of drivers/acpi

[Alan Hourihane]

On Thu, 2007-09-06 at 09:22 -0400, Len Brown wrote:
> On Thursday 06 September 2007 07:47, Alan Hourihane wrote:
> 
> > Mmm. It seems acpi_video_bus_check() is static and therefore not
> > available outside of video.c
> > 
> > > 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?

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.

Re: obtaining acpi details outside of drivers/acpi

[Alan Hourihane]

On Thu, 2007-09-06 at 14:53 +0100, Alan Hourihane wrote:
> On Thu, 2007-09-06 at 09:22 -0400, Len Brown wrote:
> > On Thursday 06 September 2007 07:47, Alan Hourihane wrote:
> > 
> > > Mmm. It seems acpi_video_bus_check() is static and therefore not
> > > available outside of video.c
> > > 
> > > > 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?
> 
> 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. 

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

Re: obtaining acpi details outside of drivers/acpi

[Alexey Starikovskiy]

Alan Hourihane wrote:
> On Thu, 2007-09-06 at 09:22 -0400, Len Brown wrote:
>> On Thursday 06 September 2007 07:47, Alan Hourihane wrote:
>>
>>> Mmm. It seems acpi_video_bus_check() is static and therefore not
>>> available outside of video.c
>>>
>>>> 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?
> 
> 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...
> 
> Alan.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: obtaining acpi details outside of drivers/acpi

[Alan Hourihane]

On Thu, 2007-09-06 at 18:17 +0400, Alexey Starikovskiy wrote:
> Alan Hourihane wrote:
> > On Thu, 2007-09-06 at 09:22 -0400, Len Brown wrote:
> >> On Thursday 06 September 2007 07:47, Alan Hourihane wrote:
> >>
> >>> Mmm. It seems acpi_video_bus_check() is static and therefore not
> >>> available outside of video.c
> >>>
> >>>> 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?
> > 
> > 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.