[Gta04-owner] QtMoko v41

[NeilBrown]

On Thu, 15 Mar 2012 07:57:59 +0100 "Dr. H. Nikolaus Schaller"
<hns at goldelico.com> wrote:

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

Nice theory.  Practice is a little bit different.

See https://lkml.org/lkml/2011/12/15/84 - note the author works for Marvel.

Particularly:

> CMD52 Card Reset (writing bit3=1 to CCCR 0x06) may not reset the SD8686
> properly for some systems. The reliable way to reset SD8686 is via
> RESETn toggling.

When the driver doesn't know what state the card is in, it must reset the card.  As the above says, that cannot be done reliably with a command - it requires a RESET toggle.

The particularly happens when the driver wakes the card up.  It doesn't know if the card has actually been powered off or not - so it must send the init sequence.
If the card was powered off, this worked.
If the card wasn't, this causes a problem.
So the only safe thing to do is to toggle the reset line.

The 3.2-gta04 kernel manages this by always pulling the line low when the driver
says it doesn't need power any more, and letting it back up when the driver wants
to apply power.  This is simiply because it was easy to implement.  A simple pulse
anywhere during that time would work, but was not as easy to implement.

Because the two lines are tied together, this holds the bluetooth reset too.

> 
> 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 why wire the reset line up at all if it isn't needed?


However if the wifi responds to a 20usec pulse, while the BT will ignore
anything less thant 1ms, then it shouldn't be too hard to make it work.
The patch I sent out uses a 10usec pulse which seems to be enough.  I haven't
tested if it interferes with BT.

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

Unfortunately there is a big step from "this is how I imagine it could work"
and "here is working code that is acceptable upstream" :-)

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

I don't follow you here - this has nothing to do with power saving.  It is
about correct behaviour.
Obviously we would power off the whole chip when neither BT nor WIFI are in
use.  The issue is getting one of the devices into a known state while the
other is being actively used.

Thanks,
NeilBrown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20120316/74e22e2e/attachment.bin>