Message ID | 20090323163459.GB5463@gamma.logic.tuwien.ac.at (mailing list archive) |
---|---|
State | RFC, archived |
Headers | show |
-- Len Brown, Intel Open Source Technology Center On Mon, 23 Mar 2009, Norbert Preining wrote: > Hi Sony Vaio Z list, > > after some discussion Matthew has provided a nice patch that makes the > Fn-F5 and Fn-F6 keys working, and also S1 and S2. > > I have adapted the speed-stamina patch from Matthias. > > The following patches are only interesting for people running 2.6.29-rc > kernels (afais) > > So attached are two patches: > - sony-laptop-matthew-version5.patch > latest version from Matthew with some keys creating events > > - sony-laptop.c-speed-stamina-latest.patch > patch to add speed-stamina switch based on the 0.7 module of Matthias > > Thanks a lot to Matthew and Matthias for working on that. I assume that Matthew's rfkill patch later sent to me via Mattia replaces what was in this message. What about the speed/stamina stuff -- is anybody testing it? 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
On Fri, Mar 27, 2009 at 09:34:23PM -0400, Len Brown wrote: > I assume that Matthew's rfkill patch later sent to me via Mattia replaces > what was in this message. Yes. > What about the speed/stamina stuff -- is anybody testing it? The speed/stamina stuff isn't Sony specific. I'm working on an external module to handle that.
On Sa, 28 Mär 2009, Matthew Garrett wrote: > > What about the speed/stamina stuff -- is anybody testing it? > > The speed/stamina stuff isn't Sony specific. I'm working on an external > module to handle that. I am testing that, but we are far from having a working thingy, currently on the sony z11 the nvidia (the second, the speed card) is not working without acpi/dsdt tricks (but Matthias might correct me). Matthew, if you have something to test I am, as usual open for any tests, but I am aways 2 weeks. In these 2 weeks I hope I get back my z11, it broke the SECOND time in 6 months, harddisc bad sector errors. I am wondering if SATA link management, laptop tools, etc etc could interfere with that. Just a warning for all the Sony guys with Z11, make decent backups, waiting for ddrescue is a pain. 2 times in 6 month sudden death of hard disk. Best wishes Norbert ------------------------------------------------------------------------------- Dr. Norbert Preining <preining@logic.at> Vienna University of Technology Debian Developer <preining@debian.org> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------------- The main reception foyer was almost empty but Ford nevertheless weaved his way through it. --- Ford making his way out of Milliways whilst under the --- influence of enough alchol to make a rhino sing. --- Douglas Adams, The Hitchhikers Guide to the Galaxy -- 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
On Saturday 28 March 2009 02:38:32 Matthew Garrett wrote: > On Fri, Mar 27, 2009 at 09:34:23PM -0400, Len Brown wrote: > > I assume that Matthew's rfkill patch later sent to me via Mattia replaces > > what was in this message. > > Yes. > > > What about the speed/stamina stuff -- is anybody testing it? The current code only powers down the Nvidia graphics adapter, it seems to work well for a number of people. However, its not really useful. For example, it doesn't allow to use the Nvidia card as the primary display adapter. Apparently it takes more then just calling the DSDT methods to enable the power supply, the card likely needs some PCI treatment as well so that its fully functional after switching it on. > The speed/stamina stuff isn't Sony specific. I'm working on an external > module to handle that. Looking at the somewhat twisted way the Sony DSDT code handles power management for the graphics adapters, I have my doubts that there will be a generic way. Of course a framework like for the rf kill switch could be useful, but the vendor and model specific code would end up in sony-laptop anyway. regards, matthias -- 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
On Sat, Mar 28, 2009 at 09:33:15AM +0100, Norbert Preining wrote: > I am testing that, but we are far from having a working thingy, > currently on the sony z11 the nvidia (the second, the speed card) is not > working without acpi/dsdt tricks (but Matthias might correct me). The short version is that you're not going to get support for the external chip until nouveau is able to cold boot it.
>> > What about the speed/stamina stuff -- is anybody testing it? >> The speed/stamina stuff isn't Sony specific. I'm working on an external >> module to handle that. > > Looking at the somewhat twisted way the Sony DSDT code handles power > management for the graphics adapters, I have my doubts that there will be a > generic way. Of course a framework like for the rf kill switch could be > useful, but the vendor and model specific code would end up in sony-laptop > anyway. Hi Matthias and Matthew, I am right in thinking that reading the DSDT tables for hybrid graphics laptops is sufficient to infer their workings? I've been compiling a list of hybrid graphics laptops and been asking people to provide their DSDT tables in this bug report: https://bugs.launchpad.net/bugs/312756 So far, I've identified 12 laptops, and we've got DSDT tables for 4 of them: http://linux-hybrid-graphics.blogspot.com/2009/03/412-linux-dsdt-tables-for-laptops-with.html Please let me know if you think we should be asking any other info, Cheers, Albert. -- 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
On Sat, Mar 28, 2009 at 12:11:51PM +0000, Albert Vilella wrote: > I am right in thinking that reading the DSDT tables for hybrid > graphics laptops is sufficient to infer their workings? Yes, though nvidia and AMD use quite different approaches to this. The nvidia chips all appear to have a _DSM with the same UUID. > I've been compiling a list of hybrid graphics laptops and been asking > people to provide their DSDT tables > in this bug report: > https://bugs.launchpad.net/bugs/312756 Ah, convenient, thanks! I'd only had the Thinkpad DSDT to look at so far, so this gives me a chance to work out if there's any standardisation of the AMD approach.
On Sat, Mar 28, 2009 at 09:41:12AM +0100, Matthias Welwarsky wrote: > Looking at the somewhat twisted way the Sony DSDT code handles power > management for the graphics adapters, I have my doubts that there will be a > generic way. Of course a framework like for the rf kill switch could be > useful, but the vendor and model specific code would end up in sony-laptop > anyway. The Dell XPS 13 has an identical _DSM despite having dual nvidia/nvidia graphics. The _DSM code in the Vaio DSDT is also very stylistically different to the rest of it, heavily supporting the idea that it's nvidia-derived code.
On Saturday 28 March 2009 13:22:13 Matthew Garrett wrote: > On Sat, Mar 28, 2009 at 09:41:12AM +0100, Matthias Welwarsky wrote: > > Looking at the somewhat twisted way the Sony DSDT code handles power > > management for the graphics adapters, I have my doubts that there will be > > a generic way. Of course a framework like for the rf kill switch could be > > useful, but the vendor and model specific code would end up in > > sony-laptop anyway. > > The Dell XPS 13 has an identical _DSM despite having dual nvidia/nvidia > graphics. The _DSM code in the Vaio DSDT is also very stylistically > different to the rest of it, heavily supporting the idea that it's > nvidia-derived code. Since it's not covered by any standard, I guess switching methods will deviate over time as more hybrid graphics laptops are released. It could be interesting to add generic functions to access _DSM methods, which is part of the ACPI spec. But first and foremost I'm interested in how to initialize it the secondary adapter to the point where an X driver would be able to work with it. Obviously _DSM is not enough. What could I try additionally? Oh, and no need to Cc me, I've subscribed to the list meanwhile. regards, matthias -- 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
On Sat, Mar 28, 2009 at 03:19:21PM +0100, Matthias Welwarsky wrote: > On Saturday 28 March 2009 13:22:13 Matthew Garrett wrote: > > The Dell XPS 13 has an identical _DSM despite having dual nvidia/nvidia > > graphics. The _DSM code in the Vaio DSDT is also very stylistically > > different to the rest of it, heavily supporting the idea that it's > > nvidia-derived code. > > Since it's not covered by any standard, I guess switching methods will deviate > over time as more hybrid graphics laptops are released. It could be > interesting to add generic functions to access _DSM methods, which is part of > the ACPI spec. _DSM is only specced in the loosest of senses - it's just a standardised namespace and calling convention, with the method being able to do whatever it wants. Given that nvidia support the hybrid switching in their Windows drivers without needing third party support, I think it's pretty likely that they'll just extend the current interface rather than change it completely. Of course, Apple's solution is implemented differently. > But first and foremost I'm interested in how to initialize it the secondary > adapter to the point where an X driver would be able to work with it. > Obviously _DSM is not enough. What could I try additionally? You need to work out how to reinitialise the chip from cold. This is non-trivial. Start with nouveau - you'll need to extend the BIOS parsing and script execution to cover G80, but then it "should" just be a matter of calling the init script and letting the BIOS do the rest of the work. > Oh, and no need to Cc me, I've subscribed to the list meanwhile. It's normal practice on kernel lists. Set an appropriate header if you don't want them.
I've done some more work on this and here's the current state of things. It's a module that loads, checks what state the firmware thinks the hardware is in and then ensures that the hardware is actually in that state. I believe that it gets the choice between internal and discrete GPUs correct. It doesn't support runtime switching right now since there's no way to do anything useful with it, but it's a trivial sysfs attribute. I've done this outside sony-laptop since it's not specific to Sonys in any way. It would be wonderful if anyone with any of the other hybrid nvidias (except the Apples, which seem to be entirely different) could give it a go.
Hi all, (back from mountains and destroyed laptop) On Di, 31 Mär 2009, Matthew Garrett wrote: > It's a module that loads, checks what state the firmware thinks the > hardware is in and then ensures that the hardware is actually in that > state. I believe that it gets the choice between internal and discrete > GPUs correct. It doesn't support runtime switching right now since > there's no way to do anything useful with it, but it's a trivial sysfs > attribute. I tested it the following way: - 2.6.29 - all patches from Mattia send for rc1 and rc2 - the module from your email - boot and start x as ususal - *after* starting X I loaded the module Output: [ 2120.435908] nvidia-control: hardware status gave 0x801f and it seems that the Stamina LED did light up (I don't remeber whether it was on before). Anything else I can test? Best wishes Norbert ------------------------------------------------------------------------------- Dr. Norbert Preining <preining@logic.at> Vienna University of Technology Debian Developer <preining@debian.org> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------------- BALLYCUMBER One of the six half-read books lying somewhere in your bed. --- Douglas Adams, The Meaning of Liff -- 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
On Mon, Apr 13, 2009 at 05:03:02PM +0200, Norbert Preining wrote: > Output: > [ 2120.435908] nvidia-control: hardware status gave 0x801f > and it seems that the Stamina LED did light up (I don't remeber whether > it was on before). > > Anything else I can test? Is the power consumption then what you expected?
On Mo, 13 Apr 2009, Matthew Garrett wrote:
> Is the power consumption then what you expected?
Hard to say, suddenly powertop tells me
no ACPI power usage estimate available
anyone any idea what that could come from???
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining <preining@logic.at> Vienna University of Technology
Debian Developer <preining@debian.org> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
HEATON PUNCHARDON (n.) A violent argument which breaks out in the car
on the way home from a party between a couple who have had to be
polite to each other in company all evening.
--- Douglas Adams, The Meaning of Liff
--
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
On Mon, Apr 13, 2009 at 05:11:36PM +0200, Norbert Preining wrote: > On Mo, 13 Apr 2009, Matthew Garrett wrote: > > Is the power consumption then what you expected? > > Hard to say, suddenly powertop tells me > no ACPI power usage estimate available > anyone any idea what that could come from??? The system's unplugged, right?
On Mo, 13 Apr 2009, Matthew Garrett wrote:
> The system's unplugged, right?
Umpfs, sorry, duck and hide. No, it wasn't.
So yes, it looks fine. Turning off all the devices but wifi, and
regulating down the brightness a bit, etc, I am back to around 13-14W. I
guess that is fine.
Thanks a lot.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining <preining@logic.at> Vienna University of Technology
Debian Developer <preining@debian.org> Debian TeX Group
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
GOLANT (adj.)
Blank, sly and faintly embarrassed. Pertaining to the expression seen
on the face of someone who has clearly forgotten your name.
--- Douglas Adams, The Meaning of Liff
--
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
On Mon, Apr 13, 2009 at 05:43:31PM +0200, Norbert Preining wrote: > So yes, it looks fine. Turning off all the devices but wifi, and > regulating down the brightness a bit, etc, I am back to around 13-14W. I > guess that is fine. Ok, sounds good. I'll tidy this up and submit it.
--- sony-laptop.c-2.6.29-rc8-matthew5 2009-03-23 17:31:19.000000000 +0100 +++ sony-laptop.c 2009-03-23 17:32:29.000000000 +0100 @@ -3,6 +3,7 @@ * * Copyright (C) 2004-2005 Stelian Pop <stelian@popies.net> * Copyright (C) 2007 Mattia Dongili <malattia@linux.it> + * Copyright (C) 2009 Matthias Welwarsky <matze@welwarsky.de> * * Parts of this driver inspired from asus_acpi.c and ibm_acpi.c * which are copyrighted by their respective authors. @@ -115,6 +116,11 @@ "set this to 1 to enable Motion Eye camera controls " "(only use it if you have a C1VE or C1VN model)"); +static int speed_stamina; +module_param(speed_stamina, int, 0444); +MODULE_PARM_DESC(speed_stamina, + "Set this to 1 to enable SPEED mode on module load (EXPERIMENTAL)"); + #ifdef CONFIG_SONYPI_COMPAT static int minor = -1; module_param(minor, int, 0); @@ -475,9 +481,161 @@ } /*********** Platform Device ***********/ +static int sony_ovga_dsm(int func, int arg) +{ + static char *path = "\\_SB.PCI0.OVGA._DSM"; + static char muid[] = { + /*00*/ 0xA0, 0xA0, 0x95, 0x9D, 0x60, 0x00, 0x48, 0x4D, /* MUID */ + /*08*/ 0xB3, 0x4D, 0x7E, 0x5F, 0xEA, 0x12, 0x9F, 0xD4, + }; + + struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL }; + struct acpi_object_list input; + union acpi_object params[4]; + int result; + + input.count = 4; + input.pointer = params; + params[0].type = ACPI_TYPE_BUFFER; + params[0].buffer.length = sizeof(muid); + params[0].buffer.pointer = (char*)muid; + params[1].type = ACPI_TYPE_INTEGER; + params[1].integer.value = 0x00000102; + params[2].type = ACPI_TYPE_INTEGER; + params[2].integer.value = func; + params[3].type = ACPI_TYPE_INTEGER; + params[3].integer.value = arg; + + result = acpi_evaluate_object(NULL, (char*)path, &input, &output); + if (result) { + printk("%s failed: %d\n", path, result); + return -1; + } + +#ifdef DEBUG + { + union acpi_object *obj = (union acpi_object*)output.pointer; + if (obj->type == ACPI_TYPE_PACKAGE) { + int i; + printk("returned package sized %d\n", obj->package.count); + for (i = 0; i < obj->package.count; i++) + printk("%d %08x\n", i, obj->package.elements[i].integer.value); + } else + if (obj->type == ACPI_TYPE_INTEGER) { + printk("returned integer %08X\n", obj->integer.value); + } else + if (obj->type == ACPI_TYPE_BUFFER) { + int i; + printk("returned buffer sized %d\n", obj->buffer.length); + for (i = 0; i < obj->buffer.length; i++) + printk("%d %02x\n", i, obj->buffer.pointer[i]); + } + } +#endif + kfree(output.pointer); + return 0; +} + +static int sony_led_stamina(void) +{ + return sony_ovga_dsm(2, 0x11); +} + +static int sony_led_speed(void) +{ + return sony_ovga_dsm(2, 0x12); +} + +#ifdef DEBUG +static int sony_led_off(void) +{ + return sony_ovga_dsm(2, 0x13); +} + +static int sony_dgpu_sta(void) +{ + return sony_ovga_dsm(3, 0x00); +} +#endif + +static int sony_dgpu_off(void) +{ + return sony_ovga_dsm(3, 0x02); +} + +static int sony_dgpu_on(void) +{ + return sony_ovga_dsm(3, 0x01); +} + +static ssize_t sony_pf_store_speed_stamina(struct device *dev, + struct device_attribute *attr, + const char *buffer, size_t count) +{ + if (!strncmp(buffer, "speed", strlen("speed"))) { + sony_dgpu_on(); + sony_led_speed(); + speed_stamina = 1; + } else + if (!strncmp(buffer, "stamina", strlen("stamina"))) { + sony_dgpu_off(); + sony_led_stamina(); + speed_stamina = 0; + } else + return -EINVAL; + + return count; +} + +static ssize_t sony_pf_show_speed_stamina(struct device *dev, + struct device_attribute *attr, char *buffer) +{ + return snprintf(buffer, PAGE_SIZE, "%s\n", speed_stamina ? "speed":"stamina"); +} + +static struct device_attribute sony_pf_speed_stamina_attr = + __ATTR(speed_stamina, S_IWUSR|S_IRUGO, + sony_pf_show_speed_stamina, sony_pf_store_speed_stamina); + +static int sony_pf_probe(struct platform_device *pdev) +{ + int result; + + result = device_create_file(&pdev->dev, &sony_pf_speed_stamina_attr); + if (result) + printk(KERN_DEBUG "sony_pf_probe: failed to add speed/stamina switch\n"); + + /* initialize default, look at module param speed_stamina */ + if (speed_stamina == 1) { + sony_dgpu_on(); + sony_led_speed(); + } else { + sony_dgpu_off(); + sony_led_stamina(); + } + + return 0; +} + +static int sony_pf_resume(struct platform_device *pdev) +{ + /* on resume, restore previous state */ + if (speed_stamina == 1) { + sony_dgpu_on(); + sony_led_speed(); + } else { + sony_dgpu_off(); + sony_led_stamina(); + } + return 0; +} static atomic_t sony_pf_users = ATOMIC_INIT(0); static struct platform_driver sony_pf_driver = { + .probe = sony_pf_probe, +#ifdef CONFIG_PM + .resume_early = sony_pf_resume, +#endif .driver = { .name = "sony-laptop", .owner = THIS_MODULE,