[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
>>>        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.


More information about the Gta04-owner mailing list