diff mbox

new fixes for sony-acpi

Message ID 20090323163459.GB5463@gamma.logic.tuwien.ac.at (mailing list archive)
State RFC, archived
Headers show

Commit Message

Norbert Preining March 23, 2009, 4:34 p.m. UTC
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.

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
-------------------------------------------------------------------------------
HIGH LIMERIGG (n.)
The topmost tread of a staircase which disappears when you've climbing
the stairs in the darkness.
			--- Douglas Adams, The Meaning of Liff

Comments

Len Brown March 28, 2009, 1:34 a.m. UTC | #1
--
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
Matthew Garrett March 28, 2009, 1:38 a.m. UTC | #2
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.
Norbert Preining March 28, 2009, 8:33 a.m. UTC | #3
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
Matthias Welwarsky March 28, 2009, 8:41 a.m. UTC | #4
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
Matthew Garrett March 28, 2009, noon UTC | #5
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.
Albert Vilella March 28, 2009, 12:11 p.m. UTC | #6
>> > 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
Matthew Garrett March 28, 2009, 12:19 p.m. UTC | #7
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.
Matthew Garrett March 28, 2009, 12:22 p.m. UTC | #8
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.
Matthias Welwarsky March 28, 2009, 2:19 p.m. UTC | #9
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
Matthew Garrett March 28, 2009, 2:44 p.m. UTC | #10
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.
Matthew Garrett March 31, 2009, 3:20 p.m. UTC | #11
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.
Norbert Preining April 13, 2009, 3:03 p.m. UTC | #12
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
Matthew Garrett April 13, 2009, 3:06 p.m. UTC | #13
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?
Norbert Preining April 13, 2009, 3:11 p.m. UTC | #14
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
Matthew Garrett April 13, 2009, 3:26 p.m. UTC | #15
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?
Norbert Preining April 13, 2009, 3:43 p.m. UTC | #16
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
Matthew Garrett April 13, 2009, 3:45 p.m. UTC | #17
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.
diff mbox

Patch

--- 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,