Message-ID: <20100819193146.GB32665@darkside.kls.lan>
Date:	Thu, 19 Aug 2010 21:31:46 +0200
From:	"Mario 'BitKoenig' Holbe" <Mario.Holbe@...Ilmenau.DE>
To:	Ike Panhc <ike.pan@...onical.com>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	"platform-driver-x86@...r.kernel.org" 
	<platform-driver-x86@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	Thomas Renninger <trenn@...e.de>,
	Alan Cox <alan@...ux.intel.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Corentin Chary <corentincj@...aif.net>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	"Brown, Len" <len.brown@...el.com>,
	Matthew Garrett <mjg@...hat.com>
Subject: Re: [PATCH 0/8] [Resend] ideapad: using EC command to control
 rf/camera power

On Thu, Aug 19, 2010 at 11:21:01AM +0800, Ike Panhc wrote:
> On 08/18/2010 11:51 PM, Mario 'BitKoenig' Holbe wrote:
> > It works for me too on S12 w/ VIA Nano - at least somehow... I have two
...
> > Fn-Esc switches the Camera off and on, but there seems to be no soft
> > killswitch for it. I have no idea how to parse through acpidump to find
> You can find the entry by "find /sys/devices -name 'camera_power'"

Thanks a lot. I found it and it works.

> > 2nd: both Bluetooth killswitches reproducibly disappear when I block
> > ideapad_bluetooth either via Gnome bluetooth-applet or via rfkill block
> > 1 and subsequently reboot.

All right, I did some more testing...

I was not able to reproduce this with Windows somewhere in the game -
neither via switching BT off in Windows and rebooting to Windows nor via
switching BT off in Linux and rebooting to Windows nor via switching BT
off in Windows and rebooting to Linux.

> This is interesting. looks like the cfgbit will change on S12 if BIOS
> remember it has to shutdown when booting. I will try if the same problem
> happen on my ideapads.

Yes, the cfgbit changes. It's normally 0xd0000 and it's 0xc0000 when the
bluetooth switch is not detected.

It's not that reproducible as it first appeared to be. Sometimes it does
not happen, i.e. sometimes after rfkill block 1 and reboot the
bluetooth killswitch is available again.

If the bluetooth killswitch is not available, a second reboot usually
makes it available again.

Once the cfgbit is 0xc0000 it's stable, i.e. modprobe -r ideapad-laptop;
modprobe ideapad-laptop doesn't change anything.

I tried to enforce the existence of the bluetooth killswitch (the
attached diff is not for inclusion but to show what I did) with some
kind of success:

[  682.260288] ideapad_acpi_add(): cfg=0xc0000
[  682.260293] ideapad_acpi_add(): found: ideapad_camera
[  682.260297] ideapad_acpi_add(): found: ideapad_wlan
[  682.260301] ideapad_acpi_add(): forced: ideapad_bluetooth
[  682.856049] usb 4-1: new full speed USB device using uhci_hcd and address 2
[  683.028220] usb 4-1: New USB device found, idVendor=0a5c, idProduct=2150
[  683.028234] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  683.028244] usb 4-1: Product: BCM2046 Bluetooth Device

So, forcing the existence of the killswitch enables the bluetooth
device. I'm also able to switch if off again - the bluetooth device
disappears. Trying to switch it back on then fails - the bluetooth
device does not appear again. But this case doesn't work all that well
anyways even with cfgbit 0xd0000:

$ rfkill block 1
[  124.648059] usb 4-1: USB disconnect, address 2
[  124.648512] btusb_intr_complete: hci0 urb f6825700 failed to resubmit (19)
[  124.648531] btusb_bulk_complete: hci0 urb f697ee80 failed to resubmit (19)
[  124.649510] btusb_bulk_complete: hci0 urb f6872400 failed to resubmit (19)
[  124.650114] btusb_send_frame: hci0 urb f67acf00 submission failed
$ rfkill unblock 1
[  133.148059] usb 4-1: new full speed USB device using uhci_hcd and address 3
[  148.260042] usb 4-1: device descriptor read/64, error -110
$ rfkill block 1
[  151.092060] hub 4-0:1.0: unable to enumerate USB device on port 1
$ rfkill unblock 1
[  155.628052] usb 4-1: new full speed USB device using uhci_hcd and address 4
[  170.740049] usb 4-1: device descriptor read/64, error -110
[  185.956033] usb 4-1: device descriptor read/64, error -110

Sometimes it doesn't even come back at all on unblock. Seems like the
bluetooth device doesn't really like to be powered off and on that way.
Btw.: once I messed up the bluetooth device that way not even Windows
sees it anymore when I reboot to it.

From all this I'm inclined to assume it has more to do with the
bluetooth device's USB interface than with the killswitch handling
itself. I believe the S12 BIOS just probes the device(s) on it's own and
sets the cfgbit accordingly and sometimes it just doesn't find the
bluetooth device - why ever.

This all does btw. not happen when I use the hci0 killswitch instead.
The device doesn't disappear then, has no issues with re-initialization,
etc. Looks way more stable that way.
I'm not absolutely sure about the different implications of using the
one or the other killswitch - maybe using the ACPI killswitches saves
more power than using the device-specific killswitches because it powers
the device(s) down completely, but that's just a wild guess - maybe it's
absolutely wrong, though.
However, it would probably be worth thinking about not offering the
additional RF killswitches at all but just doing the initialization
stuff to make sure the devices power up and are thus able to be handled
via their own killswitches subsequently.

Please let me know if I can provide more testing - and what kind of :)


Mario
-- 
We know that communication is a problem, but the company is not going to
discuss it with the employees.
                       -- Switching supervisor, AT&T Long Lines Division

View attachment "ideapad_laptop.diff" of type "text/x-diff" (896 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (483 bytes)

Powered by blists - more mailing lists