Re: /proc/acpi/ removal plan

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday, 22 of September 2008, Zhang Rui wrote:
> On Fri, 2008-09-19 at 16:07 -0600, Rafael J. Wysocki wrote:
> > On Friday, 19 of September 2008, Zhang, Rui wrote:
> > > >From: Len Brown [mailto:lenb@xxxxxxxxxxxxxxx]
> > > >Sent: Friday, September 19, 2008 12:33 AM
> > > >To: dmitry.torokhov@xxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx; rjw@xxxxxxx; Zhang,
> > > >Rui
> > > >Subject: Re: /proc/acpi/ removal plan
> > > >
> > > >> processor throttling state I/F
> > > >> As processor T-state is used for thermal control only,
> > > >> processor t-state is mapped to a cooling_device's cooling_state
> > > >> in the generic thermal driver, combined with the processor's p-state.
> > > >
> > > >> # ls -l /sys/class/thermal/cooling_device0/
> > > >
> > > >When I scribble into cur_state
> > > >I do not see anything reflected in
> > > >/proc/acpi/processor/*/throttling
> > > >
> > > >Also, max_state is 10, when surely my processor
> > > >has only 8 T-states.
> > > >
> > > the cooling state of processor is a combination of p-state and t-state.
> > > because reducing the frequency is preferred when system is overheat.
> > > e.g cooling state 0 mean processor can be run in the maximum frequency, and it's in the T0 state. And cooling state 9 means processor is in the minimum frequency, T7 state.
> > >
> > > >If user-space can not provoke processor T-states via this I/F,
> > > >then those using the old /proc I/F will flag it as a regression
> > > >when it goes away.  (even if few should ever need it)
> > > >
> > > >> wakeup control,
> > > >> /sys/devices/.../wakeup should be in the todo list. :)
> > > >
> > > >I thought that Rafael said the wakeup file
> > > >in the device tree was working now -- at least
> > > >for PCI devices, no?
> > > >
> > > Rafael's patch did bind the "wakeup" file together with the ACPI device.
> > > It calls the acpi_enable_wakeup_device_power of the ACPI device, but it
> > > doesn't touch the wakeup GPE at all. So, I don't think it actually works...
> > 
> > Have you noticed that the GPEs are actually set up right before
> > entering the sleep state?  acpi_enable_wakeup_device() does that, so in fact
> > yes, it does work.
> > 
> acpi_enable_wakeup_device will enable all the valid wakeup GPEs, that's
> why dev->wakeup.state.enabled is set when writing to /proc/acpi/wakeup.
> And I don't think this flag is set in acpi_pm_device_sleep_wake,
> or do I miss something?

Actually, yes, you do. :-)

Please read the last paragraph of the changelog of
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=eb9d0fe40e313c0a74115ef456a2e43a6c8da72f

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

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux