On 08/31/2010 02:19 AM, Mario 'BitKoenig' Holbe wrote:
quoted text
> Hello Ike,
> 
> On Wed, Aug 25, 2010 at 07:59:30PM +0800, Ike Panhc wrote:
>> 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..
> 
> Well, the pattern looks like I/O - mmapped I/O.
>         Store (Arg1, \_SB.INF0)
>         Store (Arg0, \_SB.BCMD)
>         Store (Zero, \_SB.SMIC)
>         Store (\_SB.INF0, Local0)
> 
> Note that INF0 is written before and read after writing SMIC. Hence,
> for this to be useful, something must have happened inbetween, i.e.
> I/O :)
> 
Yes, I have the same feeling. The problem is that I have no idea what happen after
writing.

quoted text
>> 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.
> 
> What exactly do you mean with "there are some sync failed"? I don't see
> anything like that in the logs.
> 
Oh, maybe I choose wrong word. Usually after some I/O writing, we have to wait for
some signal or time to make sure device complete operation. But it seems reading
right after writing. This is not important, just some nagging..

quoted text
>> 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.
> 
> Hmmm, I don't know if I got you right. I didn't find any new drivers to
> test, so I tried to add some more debug code myself. Hope this helps.
> I added some code to show_ideapad_cam() to be able to asynchronously
> trigger reading of BTST, BTEN, and BTPS. As before: the patch attached
> is not for inclusion but to show what I did. I'm usually not a kernel
> hacker, so please take a serious look at what I did before trusting the
> results :)
Sorry, I took some day off for a rest. And thank you, you did exactly
what I plan to do. From your log the values of BTST/BTEN match what it
shall be.

quoted text
> 
> I attached a full protocol of actions I performed including kernel
> dmesges. Typed commands are prepended by #, manual actions and comments
> are enclosed in <>, kernel messages are timestamped, the rest is output
> of the commands.
> Basically I did the following:
> 0. I started with a fresh powered up system, all RF devices powered on.
> 1. I hw-switched RF off and back on, which went okay.
> 2. I sw-switched BT off and back on, which resulted in erroneous
> initialization.
> 3. I again sw-switched BT off and back on, which resulted in BT being
> completely gone.
> 4. I hw-switched RF off and back on, which brought BT back and
> operational.
Your log tells a lot. It tells me if the bluetooth init failed. Then we
have to turning off and power on again by hw switch to make it alive again.

So, I believe we have two issue here.
* when rfkill unblock, sometimes bluetooth init failed.
* power up system after rfkill block bluetooth, sometimes the cfgbit = 0xc0000
Am I correct?

quoted text
> 
>>> 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'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.
> 
> Hmmm, I don't understand your reasoning here.
> I said the device disappears and re-appears when using the hw rf switch,
> this doesn't look like it would turn off PHY only.
I saw the USB disconnect in your log. You are right, the hw rf switch power
down the whole module.

Just check with B550, the hw rf switch power down the whole bluetooth, but
only turn off PHY for wifi. Looks like I can not take design for bluetooth
and wifi are the same. Thanks for let me check it again.

quoted text
> 
> 
> best regards
>    Mario

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/