Suggestion for improving the handling of GPE enabling.

Suggestion for improving the handling of GPE enabling.

[Nigel Cunningham]

Hi all.

Thinking about this GPE enabling issue some more, I'm wondering if the
best solution would be to switch the enabling/disabling to be a handler
registered with the driver model. In this way, the action taken could be
better tied to what's actually happening (I'm assuming Pavel's
pm_message_t changes are applied). Something like:

PMSG_FREEZE: Disable GPEs.
PMSG_SUSPEND: Enable wake GPEs.
PMSG_ON: Disable wake GPEs, enable normal GPEs.

Regards,

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Suggestion for improving the handling of GPE enabling.

[Li Shaohua]

On Wed, 2005-03-09 at 06:23, Nigel Cunningham wrote:
> Hi all.
> 
> Thinking about this GPE enabling issue some more, I'm wondering if the
> best solution would be to switch the enabling/disabling to be a
> handler
> registered with the driver model. In this way, the action taken could
> be
> better tied to what's actually happening (I'm assuming Pavel's
> pm_message_t changes are applied). Something like:
> 
> PMSG_FREEZE: Disable GPEs.
> PMSG_SUSPEND: Enable wake GPEs.
> PMSG_ON: Disable wake GPEs, enable normal GPEs.
I have the same feeling. A real solution should be to merge ACPI device
into the global device tree, so every ACPI driver will have a
.suspend/.resume method. In the .suspend/.resume method, we can do
anything we want. This has been in the wish list for a long time.
Some issues are:
1. what kind of device should ACPI device be? system device or platform
device?
2. What's purpose of the current ACPI namespace in sysfs? Could ACPI
device be regarded as a normal device?
3. Some ACPI devices have physical partners. Who will do the
suspend/resume?
4. ACPI devices are in many different physical buses. If we just define
an ACPI bus, we possibly can't show the bus hierarchy.


Thanks,
Shaohua



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Suggestion for improving the handling of GPE enabling.

[Pavel Machek]

Hi!

> > better tied to what's actually happening (I'm assuming Pavel's
> > pm_message_t changes are applied). Something like:
> > 
> > PMSG_FREEZE: Disable GPEs.
> > PMSG_SUSPEND: Enable wake GPEs.
> > PMSG_ON: Disable wake GPEs, enable normal GPEs.
> I have the same feeling. A real solution should be to merge ACPI device
> into the global device tree, so every ACPI driver will have a
> .suspend/.resume method. In the .suspend/.resume method, we can do
> anything we want. This has been in the wish list for a long time.
> Some issues are:
> 1. what kind of device should ACPI device be? system device or platform
> device?

I'd say platform device, but pick one ;-).

> 2. What's purpose of the current ACPI namespace in sysfs? Could ACPI
> device be regarded as a normal device?

I did not notice we have ACPI namespace in sysfs... ... aha, I see. I
guess it is okay for debugging and low-level tricks aka sonypi?

> 3. Some ACPI devices have physical partners. Who will do the
> suspend/resume?

I'd let the physical partners do it; it should work without ACPI, too.

> 4. ACPI devices are in many different physical buses. If we just define
> an ACPI bus, we possibly can't show the bus hierarchy.

Maybe ACPI device should be "under" real hardware one?

								Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Suggestion for improving the handling of GPE enabling.

[Len Brown]

On Wed, 2005-03-09 at 17:21, Pavel Machek wrote:

> > 4. ACPI devices are in many different physical buses. If we just define
> > an ACPI bus, we possibly can't show the bus hierarchy.
> 
> Maybe ACPI device should be "under" real hardware one?

I suspect that the current sysfs device tree hierarchy is largely
fiction and that Linux would be better served by taking advantage of the
hierarchy embodied in the DSDT.

The "ACPI devices" such as power, sleep, lid as well as the battery are
represented at the root level in the DSDT.

-Len




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Suggestion for improving the handling of GPE enabling.

[Pavel Machek]

On Čt 10-03-05 00:10:47, Len Brown wrote:
> On Wed, 2005-03-09 at 17:21, Pavel Machek wrote:
> 
> > > 4. ACPI devices are in many different physical buses. If we just define
> > > an ACPI bus, we possibly can't show the bus hierarchy.
> > 
> > Maybe ACPI device should be "under" real hardware one?
> 
> I suspect that the current sysfs device tree hierarchy is largely
> fiction and that Linux would be better served by taking advantage of the
> hierarchy embodied in the DSDT.

Funny, I'd say that DSDT hierarchy is fiction and ... :-).

> The "ACPI devices" such as power, sleep, lid as well as the battery are
> represented at the root level in the DSDT.

It probably does not matter where power/sleep/lid are represented, but
things like ide-disk below ide-controller below pci bus make sense to
me (and we need that hierarchy for suspend/resume anyway). For devices
like lid... yeh, there's not much hierarchy there, just select some
place.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

Re: Suggestion for improving the handling of GPE enabling.

[Matthew Garrett]

On Thu, 2005-03-10 at 00:10 -0500, Len Brown wrote:
> On Wed, 2005-03-09 at 17:21, Pavel Machek wrote:
> 
> > > 4. ACPI devices are in many different physical buses. If we just define
> > > an ACPI bus, we possibly can't show the bus hierarchy.
> > 
> > Maybe ACPI device should be "under" real hardware one?
> 
> I suspect that the current sysfs device tree hierarchy is largely
> fiction and that Linux would be better served by taking advantage of the
> hierarchy embodied in the DSDT.
> 
> The "ACPI devices" such as power, sleep, lid as well as the battery are
> represented at the root level in the DSDT.

Are the ACPI HID names exposed to userspace yet? At the moment userspace
tools need to try loading every ACPI module. If the HIDs were exported
via sysfs and the ACPI drivers exported the devices they could bind to,
we could use hotplug to autoload the correct drivers.

-- 
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Re: Suggestion for improving the handling of GPE enabling.

[Karol Kozimor]

Thus wrote Matthew Garrett:
> > I suspect that the current sysfs device tree hierarchy is largely
> > fiction and that Linux would be better served by taking advantage of the
> > hierarchy embodied in the DSDT.
> > 
> > The "ACPI devices" such as power, sleep, lid as well as the battery are
> > represented at the root level in the DSDT.
> 
> Are the ACPI HID names exposed to userspace yet? At the moment userspace
> tools need to try loading every ACPI module. If the HIDs were exported
> via sysfs and the ACPI drivers exported the devices they could bind to,
> we could use hotplug to autoload the correct drivers.

I fully support that. Ugh, so many things to do, so little time...
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/A@public.gmane.org


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

RE: Suggestion for improving the handling of GPE enabling.

[Li, Shaohua]

>> > > an ACPI bus, we possibly can't show the bus hierarchy.
>> >
>> > Maybe ACPI device should be "under" real hardware one?
>>
>> I suspect that the current sysfs device tree hierarchy is largely
>> fiction and that Linux would be better served by taking advantage of
the
>> hierarchy embodied in the DSDT.
>>
>> The "ACPI devices" such as power, sleep, lid as well as the battery
are
>> represented at the root level in the DSDT.
>
>Are the ACPI HID names exposed to userspace yet? At the moment
userspace
>tools need to try loading every ACPI module. If the HIDs were exported
>via sysfs and the ACPI drivers exported the devices they could bind to,
>we could use hotplug to autoload the correct drivers.
Sure, after we add ACPI bus support, the ACPI module should be loaded
dynamically. 
This makes me think another issue. You know PNPACPI also could export
the HIDs to user space. We plan to add the hotplug in PNPACPI. So the
question is who (PNP layer or ACPI) should export the HID?

Thanks,
Shaohua


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

RE: Suggestion for improving the handling of GPE enabling.

[Li, Shaohua]

Hi Len,
>On Wed, 2005-03-09 at 17:21, Pavel Machek wrote:
>
>> > 4. ACPI devices are in many different physical buses. If we just
define
>> > an ACPI bus, we possibly can't show the bus hierarchy.
>>
>> Maybe ACPI device should be "under" real hardware one?
>
>I suspect that the current sysfs device tree hierarchy is largely
>fiction and that Linux would be better served by taking advantage of
the
>hierarchy embodied in the DSDT.
>
>The "ACPI devices" such as power, sleep, lid as well as the battery are
>represented at the root level in the DSDT.
Do you mean the ACPI bus should only include the devices at the root
level of DSDT? I agree we should not include all devices defined in DSDT
on ACPI bus, since apparently many devices aren't in ACPI bus. But there
is a dilemma. We add ACPI bus to device tree, then we can use device
core routines such as '.probe, .match'. To me, this should replace
current ACPI device/driver register mechanism and use standard. But if
only part of devices defined in DSDT is in ACPI bus, some devices can't
use the mechanism. What's up? Maintain two mechanisms?

Thanks,
Shaohua


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

RE: Suggestion for improving the handling of GPE enabling.

[Brown, Len]

>Hi Len,
>>On Wed, 2005-03-09 at 17:21, Pavel Machek wrote:
>>
>>> > 4. ACPI devices are in many different physical buses. If 
>we just define
>>> > an ACPI bus, we possibly can't show the bus hierarchy.
>>>
>>> Maybe ACPI device should be "under" real hardware one?
>>
>>I suspect that the current sysfs device tree hierarchy is largely
>>fiction and that Linux would be better served by taking 
>advantage of the
>>hierarchy embodied in the DSDT.
>>
>>The "ACPI devices" such as power, sleep, lid as well as the 
>battery are
>>represented at the root level in the DSDT.

>Do you mean the ACPI bus should only include the devices at 
>the root level of DSDT? I agree we should not include all 
>devices defined in DSDT on ACPI bus, since apparently many 
>devices aren't in ACPI bus. But there is a dilemma. We add 
>ACPI bus to device tree, then we can use device core routines 
>such as '.probe, .match'. To me, this should replace current 
>ACPI device/driver register mechanism and use standard. But if 
>only part of devices defined in DSDT is in ACPI bus, some 
>devices can't use the mechanism. What's up? Maintain two mechanisms?

I belive that on an ACPI-enabled sytem, the "root bus" and the "ACPI
bus" are synonymous.  The other busses hang off the root bus.

/sys/devices on an ACPI-enabled system should be constructed
with the aid of the ACPI sub-system, because the topology
information is embodied in the DSDT.  It should include
all devices enumerated in the DSDT/SSDT, whose drivers should
use the "core" driver methods -- just like any other driver.

I do not agree with suggestions that the linux device
tree is God's truth and that it should have symbolic links into
/sys/firmware/acpi.  I believe that /sys/devices should get it right in
the first place, should include all the devices, and /sys/firmware/acpi
should be deleted.

thanks,
-Len


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click

RE: Suggestion for improving the handling of GPE enabling.

[Li, Shaohua]

>I belive that on an ACPI-enabled sytem, the "root bus" and the "ACPI
bus"
>are synonymous.  The other busses hang off the root bus.
>
>/sys/devices on an ACPI-enabled system should be constructed
>with the aid of the ACPI sub-system, because the topology
>information is embodied in the DSDT.  It should include
>all devices enumerated in the DSDT/SSDT, whose drivers should
>use the "core" driver methods -- just like any other driver.
>
>I do not agree with suggestions that the linux device
>tree is God's truth and that it should have symbolic links into
>/sys/firmware/acpi.  I believe that /sys/devices should get it right in
the
>first place, should include all the devices, and /sys/firmware/acpi
should
>be deleted.
Maintain a bus tree just like the ACPI DSDT? This possibly isn't easy.
Linux device core model seems hasn't a mechanism to show the
relationship of two buses. 

Thanks,
Shaohua


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&op=click