[Gta04-owner] 3.2-rc6-gta04 - another week, another rc.

Dr. H. Nikolaus Schaller hns at goldelico.com
Mon Dec 19 22:32:15 CET 2011

Am 19.12.2011 um 21:21 schrieb NeilBrown:

> On Mon, 19 Dec 2011 13:06:13 +0100 "Dr. H. Nikolaus Schaller"
> <hns at goldelico.com> wrote:
>> Hi Neil,
>> Am 19.12.2011 um 12:53 schrieb NeilBrown:
>>> On Mon, 19 Dec 2011 11:03:40 +0100 "Dr. H. Nikolaus Schaller"
>>> <hns at goldelico.com> wrote:
>>>>> I'll have to build myself a uboot ... are there any tricks I need to know, or
>>>> What do you intend to change?
>>> Possibly nothing - just want to use the latest and want to know that I can
>>> build it myself.
>> If you have ideas or find issues, please report here:
>> http://projects.goldelico.com/p/gta04-uboot/issues/
>> U-Boot-bugs are usually easier and faster fixed than in the kernel.
>>> I have an idea that it might be good to drop 3V3 for a few milliseconds early
>>> in boot to make sure that the GPS is off so that when we toggle the
>>> on/off line we can be certain what state it is in.  That would best be done
>>> in uboot I think.
>> I am not sure if that is possible at all. The 3V3 line is coming from
>> a LDO that is a slave of the REGEN signal of the TPS65950. I.e.
>> it becomes enabled by hardware. And it can't be turned off because
>> there are other chips (e.g. the USB3322) which is not allowed to receive
>> 1.8V signals on the inputs if there is no 3V3.
> Oh - that's a shame.
> Is it safe to turn 3V3 off during suspend or is it meant to stay on the
> whole time?

It will stay on all the time since it is part of the proper power on/off sequencing
scheme. There is a timing diagram in the TPS65950 and DM3730 data sheets.

So suspend has to take care that it switches all devices to low power mode
(e.g by activating RESET or sending some I2C commands). According to the
data sheets this is possible. So 3.3V remains active but the system draws some
50 uA from the 3V3 rail. And the modem draws 3-10 mA from VBATT.

It is also that the 1.8V is not shut down not keep DRAM alive. And to keep
the GPIO pins active that are looking for wakeup impulses. But one core
voltage is completely shut down (I think VDD2).

But I have no real experience with it. We may have to do some tests as soon
as suspend/wakeup works. We can suspend the CPU and check the power
consumption and try to find out which chips are not shut down.

I would e.g. suspect the TSC2007 driver. It could be sent to deep sleep
where it just monitors the touch screen and can generate a PENIRQ
wakeup if someone touches the screen. 

>> So I think we have no real chance to bring the GPS into a specific
>> state if it isn't there.
>> But - there should be a systematic pattern: after 3V3 is turned on,
>> it should be in reset state and need exactly one impulse.
> Yes ... it should be off on boot and if we make sure to turn it off on reboot
> it should still be off on the next boot.  I worry about kernel crashes etc
> that might reboot without a clean shutdown, but maybe I'm worrying too much.

Ok, that may indeed happen.

> I'll probably just assume it is always off a boot and wait until someone
> proves me wrong :-)

Yes, the GPS chip has its internal power-on-reset logic and that starts in
deep sleep. Until it gets a wakeup impulse.

>> If we really want to bring that into a kernel driver I would suggest
>> the following: if there is data on the serial port /dev/ttyO0 and no
>> user process has opened the file, we can assume that GPS is
>> on. We set a flag and just reset a timer of approx. 2 seconds. If
>> there is a timeout, we reset the flag assuming that we have to
>> switch on. I think this could be encapsulated in a W2SG driver.
>> But needs to modify omap-serial to send such a "I did receive data"
>> notification. This may make it difficult to get it upstream.
> I we had a really good case and a clean design it might be possible, but
> maybe it isn't really needed after all.
> Thanks,
> NeilBrown

More information about the Gta04-owner mailing list