Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camera power

[Ike Panhc <ike.pan@canonical.com>]

On 08/20/2010 05:08 PM, Mario 'BitKoenig' Holbe wrote:
> 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.
> 
It accesses something in system memory, but I have no idea what will happen
after writing..

>> 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 :)
> 
That's my misunderstanding.

>>> [  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).
> 
There are two variables need to be written for turning on/off bluetooth. They are
BTST(in memory) and BTEN(is EC register). I will guess there are some sync failed
when enable bluetooth.

>>> 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...
This could be a plan. I have several idea to go and need your help.
- Add some debug message to read BTST/BTEN when turning on/off bluetooth.
- Force to set BTST/BTEN before reading _CFG
- Provide a module parm to force enable rf devices.

Will have the drivers and please test it and let me know the result.

> 
>>> 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.
Usually the hw rf switch turning off PHY only. When turning off, device and
its driver is still there. I believe S12 is designed in this way after
reading your test result.

> 
> 
> Mario