[Gta04-owner] QtMoko v41

Dr. H. Nikolaus Schaller hns at goldelico.com
Thu Mar 15 07:57:59 CET 2012


Am 14.03.2012 um 22:25 schrieb NeilBrown:

> On Tue, 13 Mar 2012 17:55:17 +0100 Christoph Mair <christoph.mair at gmail.com>
> wrote:
> 
>> On Tue, Mar 13, 2012 at 6:50 PM, Radek Polak <psonek2 at seznam.cz> wrote:
>>> On Tuesday 13 March 2012 12:59:23 Michele Brocco wrote:
>> 
>>>> * Bluetooth: I think some paths changed with the never kernel, because
>>>> the "bluetooth up" script does mentions wrong paths. it used to work
>>>> in previous versions so I guess it's really just a matter of paths.
>>> 
>>> For me bluetooth is not working with 3.2 kernel. This is what i get:
>>> 
>>> root at neo:~# rfkill list
>>> 0: GPS: GPS
>>>        Soft blocked: no
>>>        Hard blocked: no
>>> 1: Bluetooth: Bluetooth
>>>        Soft blocked: no
>>>        Hard blocked: no
>>> 2: hso-5: Wireless WAN
>>>        Soft blocked: no
>>>        Hard blocked: no
>>> 6: phy3: Wireless LAN
>>>        Soft blocked: no
>>>        Hard blocked: no
>>> root at neo:~# hciattach -s 115200 /dev/ttyO0 any 115200 flow && sleep 2
>>> Device setup complete
>>> root at neo:~# hciconfig -a
>>> hci0:   Type: BR/EDR  Bus: UART
>>>        BD Address: 00:00:00:00:00:00  ACL MTU: 0:0  SCO MTU: 0:0
>>>        DOWN INIT RUNNING
>>>        RX bytes:0 acl:0 sco:0 events:0 errors:0
>>>        TX bytes:39 acl:0 sco:0 commands:9 errors:0
>>> 
>>> root at neo:~# hciconfig hci0 up; sleep 2
>>> 
>>> Can't init device hci0: Connection timed out (110)
>>> 
>>> and there is following error in dmesg repeated:
>>> 
>>> 14573.206573] Bluetooth: hci0 command tx timeout
>> 
>> If you enable WLan (ifconfig wlan0 up) BT will work too (at least it
>> stops reporting errors). Maybe the chip is not powered up if only BT
>> is used. I have to test a bit more to find out what happens.
> 
> I know what is happening here.
> 
> The chip is powered OK, but while wlan0 is "down" the wifi reset is
> also held low (necessary for proper reset).

Hm. Why that?

The WiFi chip has three power states which can be controlled through
SDIO commands (unfortunately I have no details about them).

1. Deep Sleep (~2mA)
2. Sleep (IEEE Power Save, ~10mA, continues to receive and acknowledge
     beacons every 100ms if the AP has DTIM=1),
3. Full operation

So I think there is no need to reset the chip after power up and the 2mA
are neglectable if we only want to operate the Bluetooth part.

After power-up the reset line should be active for >500us and then
go high. A short impulse (1-20 us) can later reset the WiFi part.

> And unfortunately the wifi reset is tied to the BT reset.  Oops.

BT also does not need a reset (unless you try to communicate
with wrong baudrate and the HCI protocol gets unsynchronized).

An impulse >5ms does a BT reset. Or a break condition on the
RX line.

So it appears to be possible to reset both components independently
in the current setup (but I have not tried).

> This might be messy to fix.

IMHO it should be:
- if user requests either WLAN or BT, apply reset, power on VAUX4,
   release the reset.
- If the seconf of both is to be powered down, apply reset and
   remove VAUX4.

Power-Up and Power-Down of WiFi should also control the "SDIO"
card detect lines and the driver (ifup/ifdown) should control the
sleep/deep sleep states through SDIO commands (unfortunately
I have no idea if this is already implemented by SDIO/libertas
power management).

> 
> If future boards could have separate GPIOs for these two reset lines, that
> would be good.

Unfortunately it is not specified how much power the chip draws
during the reset state. With the GTM601W I had found that it draws
considerably more power if reset is held active than if the chip
is sent to deep sleep by software.

BR,
Nikolaus



More information about the Gta04-owner mailing list