Re: problems about ACPI sysfs convert work

Re: problems about ACPI sysfs convert work

[Thomas Renninger]

On Mon, 2006-11-20 at 18:10 +0800, Zhang, Rui wrote:
> Hello, lists
> I’m doing the ACPI sysfs convert work now. And I have some problems when duplicating some procfs interfaces to sysfs.
> Under driver model (this will be available soon), files under /proc/acpi/xxx(driver)/yyy(device)/ will be duplicated under /sys/device/ as they are properties of individual devices.
> But I still have some trouble on dealing with the files under /prco/acpi, including “alarm”, “sleep”, “wakeup”, “debug_layer”, “debug_level”, “dsdt”, “fadt”, “event” and “info”.
> Following is a proposal as well as some problem and I’m not quite sure about the places all these attributes should be located at. I wish to get some advice from you, and any comment is welcome☺.
> 
> 1. Where should “alarm” be located? Another problem is whether we should put a duration into this file instead of a future time.
Don't know, never used...
> 2. “sleep” is already marked as deprecated because /sys/power/state has the same function. I won’t do the repeated work again.
Yep.
> 3. “wakeup” should not exist, but be an attribute of individual devices kobjects.
Maybe the devices can be linked
like /sys/.../wakeup/${links_to_wakeup_devices}
So that userspace does not need to search over the whole device tree to
find them?

> 4. “debug_layer” and “debug_level” are not decided yet. I think making them into two directories and locating them under /sys/bus/acpi is one choice.
> 5. Is “dsdt” and “fadt” still needed in sysfs? This is not necessary because the acpidump tools are quite handy.
> If “Yes”, are other tables also needed, e.g. multiple SSDTs and dynamically loaded op-regions? This is much more difficult, as they can’t be distinguished sometimes.
> And where should these tables locate?
IMO they can vanish (at least temporarily).
If really needed (AFAIK explicitly loaded tables via "Load(addr,)"
statement that are not listed in RSDT/XSDT can't be found by acpidump),
a /sys/../tables/* can still be implemented at later time? We are also
not able to grab them atm...
> If the answer is “No”, that’s good news for me. ☺.
> 6. “info” shows the ACPICA version. Is it ok to register “info” as an attribute of ACPI bus kobject?

   Thomas


-
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: problems about ACPI sysfs convert work

[Matthew Garrett]

(I seem to be missing the original mail here...)

On Mon, Nov 20, 2006 at 12:18:13PM +0100, Thomas Renninger wrote:
> > Hello, lists
> > I’m doing the ACPI sysfs convert work now. And I have some problems when duplicating some procfs interfaces to sysfs.
> > Under driver model (this will be available soon), files under /proc/acpi/xxx(driver)/yyy(device)/ will be duplicated under /sys/device/ as they are properties of individual devices.
> > But I still have some trouble on dealing with the files under /prco/acpi, including “alarm”, “sleep”, “wakeup”, “debug_layer”, “debug_level”, “dsdt”, “fadt”, “event” and “info”.
> > Following is a proposal as well as some problem and I’m not quite sure about the places all these attributes should be located at. I wish to get some advice from you, and any comment is welcome☺.
> > 
> > 1. Where should “alarm” be located? Another problem is whether we should put a duration into this file instead of a future time.
> Don't know, never used...

This should presumably just be handled by the clock driver rather than 
the ACPI subsystem. There's only a tiny amount of acpi-related code in 
the driver, and that's information that we could just export to the 
clock instead.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
-
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: problems about ACPI sysfs convert work

[Zhang Rui]

On Tue, 2006-11-21 at 16:34 +0000, Matthew Garrett wrote:
> (I seem to be missing the original mail here...)
> 
> On Mon, Nov 20, 2006 at 12:18:13PM +0100, Thomas Renninger wrote:
> > > Hello, lists
> > > I’m doing the ACPI sysfs convert work now. And I have some problems when duplicating some procfs interfaces to sysfs.
> > > Under driver model (this will be available soon), files under /proc/acpi/xxx(driver)/yyy(device)/ will be duplicated under /sys/device/ as they are properties of individual devices.
> > > But I still have some trouble on dealing with the files under /prco/acpi, including “alarm”, “sleep”, “wakeup”, “debug_layer”, “debug_level”, “dsdt”, “fadt”, “event” and “info”.
> > > Following is a proposal as well as some problem and I’m not quite sure about the places all these attributes should be located at. I wish to get some advice from you, and any comment is welcome☺.
> > > 
> > > 1. Where should “alarm” be located? Another problem is whether we should put a duration into this file instead of a future time.
> > Don't know, never used...
> 
> This should presumably just be handled by the clock driver rather than 
> the ACPI subsystem. There's only a tiny amount of acpi-related code in 
> the driver, and that's information that we could just export to the 
> clock instead.
> 
I prefer to locate "alarm" under /sys/power, together with "wakeup".
Yes, you are right that it does have a lot to do with the clock driver.
But I think this patch series should impact other parts little. You
know, the main purpose of this patch series is just to duplicate the
procfs function in sysfs. So only the functions for sysfs interface will
be added in the first step. :)
-
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: problems about ACPI sysfs convert work

[Len Brown]

On Wednesday 22 November 2006 03:13, Zhang Rui wrote:
> On Tue, 2006-11-21 at 16:34 +0000, Matthew Garrett wrote:

> > (I seem to be missing the original mail here...)

FYI, the original message was filtered from the list b/c it was HTML, but Thomas' reply quoted the whole thing.

Re: problems about ACPI sysfs convert work

[Len Brown]

On Tuesday 21 November 2006 11:34, Matthew Garrett wrote:

> > > I’m doing the ACPI sysfs convert work now. And I have some problems when duplicating some procfs interfaces to sysfs.
> > > Under driver model (this will be available soon), files under /proc/acpi/xxx(driver)/yyy(device)/ will be duplicated under /sys/device/ as they are properties of individual devices.
> > > But I still have some trouble on dealing with the files under /prco/acpi, including “alarm”, “sleep”, “wakeup”, “debug_layer”, “debug_level”, “dsdt”, “fadt”, “event” and “info”.
> > > Following is a proposal as well as some problem and I’m not quite sure about the places all these attributes should be located at. I wish to get some advice from you, and any comment is welcome☺.
> > > 
> > > 1. Where should “alarm” be located? Another problem is whether we should put a duration into this file instead of a future time.
> > Don't know, never used...
> 
> This should presumably just be handled by the clock driver rather than 
> the ACPI subsystem. There's only a tiny amount of acpi-related code in 
> the driver, and that's information that we could just export to the 
> clock instead.

Matthew, exactly what code in "the clock driver" to you refer to that
should be involved here?

Re: duration vs. absolute time.
Currently use use absolute time, and that capability needs to stay.

I requested also a sleep duration capability.
I'd like to use it to make the suspend/resume stress test suite a little better,
but others might like it for "real" use as well.
Either a different sysfs file, or a special syntax like preceeding the time
with a '+' to make it a duration?

thanks,
-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: problems about ACPI sysfs convert work

[Matthew Garrett]

On Wed, Nov 22, 2006 at 05:12:35PM -0500, Len Brown wrote:
> Matthew, exactly what code in "the clock driver" to you refer to that
> should be involved here?

http://lkml.org/lkml/2006/7/15/85 - looking closer, it may not have been 
merged yet. But it hooks the ACPI clock information into the general RTC 
framework, so sounds like the right sort of answer.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: problems about ACPI sysfs convert work

[Shaohua Li]

On Mon, 2006-11-20 at 12:18 +0100, Thomas Renninger wrote:
> On Mon, 2006-11-20 at 18:10 +0800, Zhang, Rui wrote:
> > Hello, lists
> > I’m doing the ACPI sysfs convert work now. And I have some problems when duplicating some procfs interfaces to sysfs.
> > Under driver model (this will be available soon), files under /proc/acpi/xxx(driver)/yyy(device)/ will be duplicated under /sys/device/ as they are properties of individual devices.
> > But I still have some trouble on dealing with the files under /prco/acpi, including “alarm”, “sleep”, “wakeup”, “debug_layer”, “debug_level”, “dsdt”, “fadt”, “event” and “info”.
> > Following is a proposal as well as some problem and I’m not quite sure about the places all these attributes should be located at. I wish to get some advice from you, and any comment is welcome☺.
> > 
> > 1. Where should “alarm” be located? Another problem is whether we should put a duration into this file instead of a future time.
> Don't know, never used...
> > 2. “sleep” is already marked as deprecated because /sys/power/state has the same function. I won’t do the repeated work again.
> Yep.
> > 3. “wakeup” should not exist, but be an attribute of individual devices kobjects.
> Maybe the devices can be linked
> like /sys/.../wakeup/${links_to_wakeup_devices}
> So that userspace does not need to search over the whole device tree to
> find them?
Sounds like a good idea. But this should be done in driver core. Other
devices like pci might support wakeup too. device declaims to support
wakeup, and driver core create a link to /sys/.../wakeup/xxx. I'd
suggest don't do this in acpi part.

Thanks,
Shaohua
-
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: problems about ACPI sysfs convert work

[Zhang Rui]

On Wed, 2006-11-22 at 09:28 +0800, Shaohua Li wrote:
> On Mon, 2006-11-20 at 12:18 +0100, Thomas Renninger wrote:
> > On Mon, 2006-11-20 at 18:10 +0800, Zhang, Rui wrote:
> > > Hello, lists
> > > I’m doing the ACPI sysfs convert work now. And I have some problems when duplicating some procfs interfaces to sysfs.
> > > Under driver model (this will be available soon), files under /proc/acpi/xxx(driver)/yyy(device)/ will be duplicated under /sys/device/ as they are properties of individual devices.
> > > But I still have some trouble on dealing with the files under /prco/acpi, including “alarm”, “sleep”, “wakeup”, “debug_layer”, “debug_level”, “dsdt”, “fadt”, “event” and “info”.
> > > Following is a proposal as well as some problem and I’m not quite sure about the places all these attributes should be located at. I wish to get some advice from you, and any comment is welcome☺.
> > > 
> > > 1. Where should “alarm” be located? Another problem is whether we should put a duration into this file instead of a future time.
> > Don't know, never used...
> > > 2. “sleep” is already marked as deprecated because /sys/power/state has the same function. I won’t do the repeated work again.
> > Yep.
> > > 3. “wakeup” should not exist, but be an attribute of individual devices kobjects.
> > Maybe the devices can be linked
> > like /sys/.../wakeup/${links_to_wakeup_devices}
> > So that userspace does not need to search over the whole device tree to
> > find them?
Sounds great. I'll have a try.
> Sounds like a good idea. But this should be done in driver core. Other
> devices like pci might support wakeup too. device declaims to support
> wakeup, and driver core create a link to /sys/.../wakeup/xxx. I'd
> suggest don't do this in acpi part.
> 
Yes. That makes sense. But I don't want too many files to be involved,
especially at the beginning. :). This should be done in another patch in
the future if everything goes well.

Thanks,
Ray
-
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: problems about ACPI sysfs convert work

[Thomas Renninger]

On Wed, 2006-11-22 at 15:53 +0800, Zhang Rui wrote:
> On Wed, 2006-11-22 at 09:28 +0800, Shaohua Li wrote:
> > On Mon, 2006-11-20 at 12:18 +0100, Thomas Renninger wrote:
> > > On Mon, 2006-11-20 at 18:10 +0800, Zhang, Rui wrote:
> > > > Hello, lists
> > > > I’m doing the ACPI sysfs convert work now. And I have some problems when duplicating some procfs interfaces to sysfs.
> > > > Under driver model (this will be available soon), files under /proc/acpi/xxx(driver)/yyy(device)/ will be duplicated under /sys/device/ as they are properties of individual devices.
> > > > But I still have some trouble on dealing with the files under /prco/acpi, including “alarm”, “sleep”, “wakeup”, “debug_layer”, “debug_level”, “dsdt”, “fadt”, “event” and “info”.
> > > > Following is a proposal as well as some problem and I’m not quite sure about the places all these attributes should be located at. I wish to get some advice from you, and any comment is welcome☺.
> > > > 
> > > > 1. Where should “alarm” be located? Another problem is whether we should put a duration into this file instead of a future time.
> > > Don't know, never used...
> > > > 2. “sleep” is already marked as deprecated because /sys/power/state has the same function. I won’t do the repeated work again.
> > > Yep.
> > > > 3. “wakeup” should not exist, but be an attribute of individual devices kobjects.
> > > Maybe the devices can be linked
> > > like /sys/.../wakeup/${links_to_wakeup_devices}
> > > So that userspace does not need to search over the whole device tree to
> > > find them?
> Sounds great. I'll have a try.
> > Sounds like a good idea. But this should be done in driver core. Other
> > devices like pci might support wakeup too. device declaims to support
> > wakeup, and driver core create a link to /sys/.../wakeup/xxx. I'd
> > suggest don't do this in acpi part.
> > 
> Yes. That makes sense. But I don't want too many files to be involved,
> especially at the beginning. :). This should be done in another patch in
> the future if everything goes well.

Yep, enabling the core ACPI sysfs stuff first sounds like a good idea?
(I am especially looking for ACPI module autoloading..., probing blindly
all ACPI modules on all x86 machines is really ugly atm...) Getting
every detail duplicated or not from /proc/acpi can later be integrated
as needed. Small on top patches later are easier to review and less
error prone, once the basic stuff runs fine?

  Thomas

-
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: problems about ACPI sysfs convert work

[Len Brown]

> > 5. Is “dsdt” and “fadt” still needed in sysfs? This is not necessary because the acpidump tools are quite handy.
> > If “Yes”, are other tables also needed, e.g. multiple SSDTs and dynamically loaded op-regions? This is much more difficult, as they can’t be distinguished sometimes.
> > And where should these tables locate?

> IMO they can vanish (at least temporarily).
> If really needed (AFAIK explicitly loaded tables via "Load(addr,)"
> statement that are not listed in RSDT/XSDT can't be found by acpidump),
> a /sys/../tables/* can still be implemented at later time? We are also
> not able to grab them atm...

FYI, The latest code on the ACPICA branch spits out the physical address
for dynamic tables in dmesg and the latest acpidump can read it by
specifying a physical address as a parameter.

My view is that if we export any tables in sysfs, we should export them all,
including dynamically loaded tables.  The current /proc/acpi/fadt,dsdt
is inconsistent.

I agree, that we can do this later.

-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