public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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 --]

  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