From: "Mario 'BitKoenig' Holbe" <Mario.Holbe@TU-Ilmenau.DE>
To: Ike Panhc <ike.pan@canonical.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
"platform-driver-x86@vger.kernel.org"
<platform-driver-x86@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
Thomas Renninger <trenn@suse.de>, Alan Cox <alan@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Corentin Chary <corentincj@iksaif.net>,
Randy Dunlap <randy.dunlap@oracle.com>,
"Brown, Len" <len.brown@intel.com>,
Matthew Garrett <mjg@redhat.com>
Subject: Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power
Date: Fri, 20 Aug 2010 11:08:24 +0200 [thread overview]
Message-ID: <20100820090824.GA23186@darkside.kls.lan> (raw)
In-Reply-To: <4C6E2833.6080407@canonical.com>
[-- Attachment #1: Type: text/plain, Size: 4074 bytes --]
On Fri, Aug 20, 2010 at 03:01:07PM +0800, Ike Panhc wrote:
> Could you attach or upload the DSDT of S12 somewhere I can reach?
http://sandbox.fem.tu-ilmenau.de/s12/dsdt-s12-via.dsl
> I check DSDT for S10-3 and B550, return value of _CFG is fixed.
> [Ref: http://people.ubuntu.com/~ikepanhc/DSDTs]
Looks more fixed than on my S12, indeed.
I don't really speak AML, but while S10-3 ILDD (called from _CFG) seems
to read fixed values only, here on S12 PHSR (called from _CFG) seems to
do some kind of I/O operation. I'm not sure about this, but it somehow
looks like.
> On 08/20/2010 03:31 AM, Mario 'BitKoenig' Holbe wrote:
> > Once the cfgbit is 0xc0000 it's stable, i.e. modprobe -r ideapad-laptop;
> > modprobe ideapad-laptop doesn't change anything.
> sounds like we need an exception handle for detecting camera
Why? The camera is always detected - bit 19 is always set, 0xc0000 and
0xd0000 only differ in bit 16. Bit 19 btw. seems to be the only fixed
bit in S12-VIA _CFG :)
> > [ 682.260288] ideapad_acpi_add(): cfg=0xc0000
> As I know the cfgbit for lower 16bit shall not be all zero.
Mh, judging from S12-VIA _CFG they definitely are zero here.
> > 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:
> bluetooth device shall disappear after disable from EC. But if can not be enabled
> again, ahh.....
> > [ 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
> This looks like the device is power up, but usb host unable to recognize..
The bluetooth device seems not to initialize well enough to answer (110
is ETIMEDOUT).
> > 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.
> did you see any kernel message said timeout when it does not come back at all?
No, when I said "does not appear again" and "it does not come back at
all" I meant I see not a single message in dmesg about anything
happening.
> If the rfkill for the whole bluetooth module makes trouble, I prefer not to
> do it. User will feel confused if the device does not come back and the
> rfkill of hci0 offers the function user need.
Hmmm, maybe provide a module parm to block rfkill devices and default it
to 1 on S12? Users would not need to care too much then but can change
it if they like...
> > Please let me know if I can provide more testing - and what kind of :)
Okay, did some more...
I played with the hardware killswitch under Linux. The bluetooth device
disappears and re-appears there and always seems to initialize
correctly. No USB read errors this way.
I also played with the soft killswitch under Windows. The bluetooth
device disappears from device manager and re-appears on unblock
(together with the Windows device plug sounds). This looks to me like
the ACPI killswitch is used for it.
No initialization-problems here, the device always comes back fully
operational. So, Windows doesn't seem to suffer from a bad
initialization.
I'm not exactly sure what this means - especially because I don't know
how the hardware killswitch works internally.
It *could* mean, the initialization problem is proably something that
could be dealt with in the USB layer long term (and would then probably
not have to be worked around anymore in ideapad_laptop). I'm not sure
about this, because this would mean the hard killswitch power-cut
somehow differs from the soft killswitch power-cut.
Mario
--
As a rule, the more bizarre a thing is, the less mysterious it proves to be.
-- Sherlock Holmes by Arthur Conan Doyle
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 478 bytes --]
next prev parent reply other threads:[~2010-08-20 9:09 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-18 8:36 [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power Ike Panhc
2010-08-18 8:36 ` [PATCH 1/8] ideapad: add ACPI helpers Ike Panhc
2010-08-18 8:37 ` [PATCH 2/8] ideapad: check VPC bit before sync rfkill hw status Ike Panhc
2010-08-18 8:37 ` [PATCH 3/8] ideapad: make sure we bind on the correct device Ike Panhc
2010-08-18 13:27 ` Matthew Garrett
2010-08-19 2:51 ` Ike Panhc
2010-08-18 8:38 ` [PATCH 4/8] ideapad: use return value of _CFG to tell if device exist or not Ike Panhc
2010-08-18 8:38 ` [PATCH 5/8] ideapad: use EC command to control camera Ike Panhc
2010-08-18 8:42 ` Oliver Neukum
2010-08-18 8:51 ` Ike Panhc
2010-08-18 8:38 ` [PATCH 6/8] ideapad: rewrite the hw rfkill notify Ike Panhc
2010-08-18 8:38 ` [PATCH 7/8] ideapad: rewrite the sw rfkill set Ike Panhc
2010-08-18 8:38 ` [PATCH 8/8] ideapad: Change the driver name to ideapad_laptop Ike Panhc
2010-08-25 20:56 ` Len Brown
2010-08-26 5:43 ` Corentin Chary
2010-08-26 6:16 ` Ike Panhc
2010-08-26 7:43 ` Corentin Chary
2010-09-01 11:55 ` Ike Panhc
2010-08-18 10:35 ` [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power David Woodhouse
2010-08-18 13:04 ` Ike Panhc
2010-08-18 15:51 ` Mario 'BitKoenig' Holbe
2010-08-19 3:21 ` Ike Panhc
2010-08-19 13:28 ` David Woodhouse
2010-08-19 19:31 ` Mario 'BitKoenig' Holbe
2010-08-20 7:01 ` Ike Panhc
2010-08-20 9:08 ` Mario 'BitKoenig' Holbe [this message]
2010-08-23 8:22 ` Ike Panhc
2010-08-25 11:59 ` Ike Panhc
2010-08-30 18:19 ` Mario 'BitKoenig' Holbe
2010-09-01 11:49 ` Ike Panhc
2010-09-01 19:56 ` Mario 'BitKoenig' Holbe
2010-09-03 9:06 ` Ike Panhc
2010-09-09 18:17 ` Mario 'BitKoenig' Holbe
2010-09-10 6:44 ` Ike Panhc
2010-09-10 7:11 ` Mario 'BitKoenig' Holbe
2010-09-15 10:13 ` Ike Panhc
2010-09-15 11:48 ` Mario 'BitKoenig' Holbe
2010-09-15 12:39 ` Ike Panhc
2010-09-16 11:59 ` Ike Panhc
2010-09-21 13:47 ` Mario 'BitKoenig' Holbe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100820090824.GA23186@darkside.kls.lan \
--to=mario.holbe@tu-ilmenau.de \
--cc=akpm@linux-foundation.org \
--cc=alan@linux.intel.com \
--cc=corentincj@iksaif.net \
--cc=dwmw2@infradead.org \
--cc=ike.pan@canonical.com \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg@redhat.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=randy.dunlap@oracle.com \
--cc=trenn@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox