On Mon, Oct 11, 2010 at 1:44 AM, Corentin Chary
<corentin.chary@xxxxxxxxx> wrote:
> On Mon, Oct 11, 2010 at 3:48 AM, <chris@xxxxxxxxxxxxxx> wrote:
>> From: Chris Bagwell <chris@xxxxxxxxxxxxxx>
>>
>> eeepc-laptop provides a sysfs interface to read and control what it
>> calls cpufv. When WMI is enabled, the ACPI interface changes slightly
>> and becames a write-only control with only 3 valid values.
>>
>> Write-only is OK because same DSDT's will ignore duplicate values
>> and even invalid values will be treated same as "0" value.
>>
>> Expose cpufv again to allow for user space utils that can extended battery
>> life noticably and come a little closer to parity with eeepc-laptop.
>>
>> This was tested with EEE PC 1005PE by monitoring powertop output while
>> writing values of "0", "1", and "2" and by reviewing the decompiled DSDT of
>> an 1201NL and comparing it to 1005PE's DSDT.
>>
>> Signed-off-by: Chris Bagwell <chris@xxxxxxxxxxxxxx>
>> ---
>> drivers/platform/x86/eeepc-wmi.c | 51 ++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 51 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
>> index 441b000..988b16c 100644
>> --- a/drivers/platform/x86/eeepc-wmi.c
>> +++ b/drivers/platform/x86/eeepc-wmi.c
>> @@ -57,6 +57,7 @@ MODULE_ALIAS("wmi:"EEEPC_WMI_MGMT_GUID);
>>
>> #define EEEPC_WMI_METHODID_DEVS 0x53564544
>> #define EEEPC_WMI_METHODID_DSTS 0x53544344
>> +#define EEEPC_WMI_METHODID_CFVS 0x53564643
>>
>> #define EEEPC_WMI_DEVID_BACKLIGHT 0x00050012
>>
>> @@ -307,6 +308,49 @@ static void eeepc_wmi_notify(u32 value, void *context)
>> kfree(obj);
>> }
>>
>> +static int store_cpufv(struct device *dev, struct device_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + int value;
>> + struct acpi_buffer input = { (acpi_size)sizeof(value), &value };
>> + acpi_status status;
>> +
>> + if (!count || sscanf(buf, "%i", &value) != 1)
>> + return -EINVAL;
>> + if (value < 0 || value > 2)
>> + return -EINVAL;
>> +
>> + status = wmi_evaluate_method(EEEPC_WMI_MGMT_GUID,
>> + 1, EEEPC_WMI_METHODID_CFVS, &input, NULL);
>> +
>> + if (ACPI_FAILURE(status))
>> + return -EIO;
>> + else
>> + return count;
>> +}
>> +
>> +static DEVICE_ATTR(cpufv, S_IRUGO | S_IWUSR, NULL, store_cpufv);
>> +
>> +static void eeepc_wmi_sysfs_exit(struct platform_device *device)
>> +{
>> + device_remove_file(&device->dev, &dev_attr_cpufv);
>> +}
>> +
>> +static int eeepc_wmi_sysfs_init(struct platform_device *device)
>> +{
>> + int retval = -ENOMEM;
>> +
>> + retval = device_create_file(&device->dev, &dev_attr_cpufv);
>> + if (retval)
>> + goto error_sysfs;
>> +
>> + return 0;
>> +
>> +error_sysfs:
>> + eeepc_wmi_sysfs_exit(platform_device);
>> + return retval;
>> +}
>> +
>> static int __devinit eeepc_wmi_platform_probe(struct platform_device *device)
>> {
>> struct eeepc_wmi *eeepc;
>> @@ -402,8 +446,14 @@ static int __init eeepc_wmi_init(void)
>> goto del_dev;
>> }
>>
>> + err = eeepc_wmi_sysfs_init(platform_device);
>> + if (err)
>> + goto del_sysfs;
>> +
>> return 0;
>>
>> +del_sysfs:
>> + eeepc_wmi_sysfs_exit(platform_device);
>> del_dev:
>> platform_device_del(platform_device);
>> put_dev:
>> @@ -418,6 +468,7 @@ static void __exit eeepc_wmi_exit(void)
>> {
>> struct eeepc_wmi *eeepc;
>>
>> + eeepc_wmi_sysfs_exit(platform_device);
>> eeepc = platform_get_drvdata(platform_device);
>> platform_driver_unregister(&platform_driver);
>> platform_device_unregister(platform_device);
>> --
>> 1.7.3.1
>>
>
> Seems ok, too bad they don't provide a way to guess the current
> configuration and the number of available settings. Especially when
> all they do is calling the old device.
>
Agree. But its probably not to bad in real life. I have some scripts
that monitor dbus and update cpufv based on switching between
batter/ac and powerup. With eeepc-laptop interface, it does read
previous state to prevent unneeded write but other then that it didn't
seem to useful to read it. Since acpi is doing same compare logic,
always writing at important transition seems simplest approach for
userland anyways.
Chris
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
