Re: PATCH/RFC: driver model/pmcore wakeup hooks (1/4)

Re: PATCH/RFC: driver model/pmcore wakeup hooks (1/4)

[Len Brown]

> - ACPI (this should probably replace the new /proc/acpi/wakeup)

Agreed.  That file is a temporary solution.
The right solution is for the devices to appear in the right
place in the device tree and to hang the wakeup capabilities
off of them there.

thanks,
-Len




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: PATCH/RFC: driver model/pmcore wakeup hooks (1/4)

[David Brownell]

On Friday 15 October 2004 11:03 pm, Len Brown wrote:
> > - ACPI (this should probably replace the new /proc/acpi/wakeup)
> 
> Agreed.  That file is a temporary solution.
> The right solution is for the devices to appear in the right
> place in the device tree and to hang the wakeup capabilities
> off of them there.

So what would that patch need before ACPI could convert to use it?

I didn't notice any obvious associations between the strings in
the acpi/wakeup file and anything in sysfs.  Which of USB1..USB4
was which of the three controllers shown by "lspci" (and which
one was "extra"!), as one head-scratcher.

For PCI, I'd kind of expect pci_enable_wake() to trigger the
additional ACPI-specific work to make sure the device can
actually wake that system.   Seems like dev->platform_data
might need to combine with some platform-specific API hook.

- Dave

Re: Re: PATCH/RFC: driver model/pmcore wakeup hooks (1/4)

[Hiroshi 2 Itoh]

David Brownell wrote:

>So what would that patch need before ACPI could convert to use it?

>I didn't notice any obvious associations between the strings in
>the acpi/wakeup file and anything in sysfs.  Which of USB1..USB4
>was which of the three controllers shown by "lspci" (and which
>one was "extra"!), as one head-scratcher.

>For PCI, I'd kind of expect pci_enable_wake() to trigger the
>additional ACPI-specific work to make sure the device can
>actually wake that system.   Seems like dev->platform_data
>might need to combine with some platform-specific API hook.

>- Dave

Does anoyone give me a link to the original RFC?
I cannot find the original mail as a newbie associated with this list.

Hiro.



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [ACPI] Re: PATCH/RFC: driver model/pmcore wakeup hooks (1/4)

[David Brownell]

On Monday 18 October 2004 9:55 pm, Hiroshi 2 Itoh wrote:
> >So what would that patch need before ACPI could convert to use it?
> 
> Does anoyone give me a link to the original RFC?
> I cannot find the original mail as a newbie associated with this list.

Messages 0-4 are:

http://marc.theaimsgroup.com/?l=linux-kernel&m=109692668310738&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=109692668228442&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=109692610403412&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=109692915107429&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=109692881326178&w=2

Click on the second one ... :)

- Dave

RE: PATCH/RFC: driver model/pmcore wakeup hooks (1/4)

[Li, Shaohua]

A final solution is device core adds an ACPI layer. That is we can link
ACPI device and physical device. This way, the PCI device can know which
ACPI is linked with it, so the PCI API can use specific ACPI method. 
You are right, we currently haven't a method to reach the goal. To match
a physical device and ACPI device, we need to know the ACPI device's
_ADR and bus.
I have a toy to link the PCI device and ACPI device, and some PCI
function can use _SxD method and _PSx method to get some information for
suspend/resume.

Thanks,
Shaohua
>-----Original Message-----
>From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
>owner@vger.kernel.org] On Behalf Of David Brownell
>Sent: Tuesday, October 19, 2004 11:41 AM
>To: Brown, Len
>Cc: Pavel Machek; linux-kernel@vger.kernel.org; ACPI Developers
>Subject: Re: PATCH/RFC: driver model/pmcore wakeup hooks (1/4)
>
>On Friday 15 October 2004 11:03 pm, Len Brown wrote:
>> > - ACPI (this should probably replace the new /proc/acpi/wakeup)
>>
>> Agreed.  That file is a temporary solution.
>> The right solution is for the devices to appear in the right
>> place in the device tree and to hang the wakeup capabilities
>> off of them there.
>
>So what would that patch need before ACPI could convert to use it?
>
>I didn't notice any obvious associations between the strings in
>the acpi/wakeup file and anything in sysfs.  Which of USB1..USB4
>was which of the three controllers shown by "lspci" (and which
>one was "extra"!), as one head-scratcher.
>
>For PCI, I'd kind of expect pci_enable_wake() to trigger the
>additional ACPI-specific work to make sure the device can
>actually wake that system.   Seems like dev->platform_data
>might need to combine with some platform-specific API hook.
>
>- Dave
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

Re: PATCH/RFC: driver model/pmcore wakeup hooks (1/4)

[Len Brown]

On Mon, 2004-10-18 at 23:41, David Brownell wrote:
> On Friday 15 October 2004 11:03 pm, Len Brown wrote:
> > > - ACPI (this should probably replace the new /proc/acpi/wakeup)
> >
> > Agreed.  That file is a temporary solution.
> > The right solution is for the devices to appear in the right
> > place in the device tree and to hang the wakeup capabilities
> > off of them there.
> 
> So what would that patch need before ACPI could convert to use it?
> 
> I didn't notice any obvious associations between the strings in
> the acpi/wakeup file and anything in sysfs.  Which of USB1..USB4
> was which of the three controllers shown by "lspci" (and which
> one was "extra"!), as one head-scratcher.

The strings "USB1" etc. are completely arbitrary, which is one
reason that /proc/acpi/wakeup is only marginally useful.

> For PCI, I'd kind of expect pci_enable_wake() to trigger the
> additional ACPI-specific work to make sure the device can
> actually wake that system.   Seems like dev->platform_data
> might need to combine with some platform-specific API hook.

In the ACPI DSDT...
Devices are explicitly identified as PCI busses by their PNP-id.
These PCI busses are enumerated by their _BBN or _CRS.
The devices under the PCI busses all contain an _ADR which encodes the
PCI device/function number.

Ie. ACPI tells us the PCI bus/dev/func for each PCI device in the DSDT,
and with this information it needs to be able to find devices in the
Linux device tree and associate some ACPI capabilities with it.

-Len




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl