[gta04] Meeting minutes for GTA04 discussion 20080411

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| hi Andy,
|
| very thank your reply, this my honor...

cough well don't worry you'll find me annoying soon enough :-)

| On GTA01 and GTA02 we used this approach where the CPU is responsible
| for everything, so we have some experience with this method.  It
| basically works.  This and the MSP430 method are the two approaches we
| can consider that are largely in conflict.
|
| In the GTA01/02 cases, we implemented support for charging modes and PMU
| into U-Boot and kernel separately which was a major pain.  U-Boot and
| kernel power implementations are different (U-Boot does not respond to
| PMU interrupts like USB cable change) and act different.  While the
| kernel boots, there service for PMU actions is deferred, but it still
| gets serviced eventually.  For GTA04+ case we determined to kill U-Boot,
| without MSP430 it means we could just ignore power management until we
| get into Linux... that is a simplification over GTA01/02 that is OK
| for me.
|> in my experience,  we can use GPIO to detect charger in/out. in past, we
|> use
|> charge_ic and GPIO to detect has provide power form USB_Cable or Charge,
|> without PMU. when change or USB_Cable plug-in device, bootloader is
active,
|> and show charging image for user. CPU go into lower frequency.

Yes the PMU chips we use consolidate a lot of "interesting events" into
one IRQ that we can put on a wake-capable interrupt, so we don't need to
go to CPU GPIO for individual events.

There are a few things we want to get away from you mention and I
explain a little why for each.

~ - excessive GPIO to CPU.  All of them need taking care of in Linux, for
other peripherals GPIO connection may change or conflict on different
variant designs.  GPIO is always fine if it is in our "core
architecture" and never changes between variants -- the PMU you mention
is in this category.  But we need to take some care if we start randomly
bringing peripheral IO to CPU GPIO differently on each variant otherwise
we can end up with a big confusing mess and possibly peripherals that
can't be used together "cut and paste" on another design directly
because their GPIO allocation conflicts.

~ - smart bootloader ("show charging image for user")  Until now we used
U-Boot which is pretty much standard practice for this kind of work.
But I found that U-Boot is like the fat girl that hangs around the
popular girl copying her fashion and mannerisms, all she does is make
the popular girl look better.  We add driver support to Linux, we have
to cut and paste it into U-Boot -- except everything in U-Boot is uglier
(sometimes WAY uglier) and we do not maintain this fork.  We provide
power management driver in Linux, we make a garbage barely-functional
copy of it in U-Boot.  And so on.  U-Boot ONLY exists with all that junk
because Linux takes TOO LONG to boot!  This is not a good way, we decide
to throw out U-Boot and make a VERY thin bootloader, and focus on fast
boot of Linux.  The bootloader only needs

~  - SD Card read / write capability
~  - Minimal NAND bad block / ECC management for read / write
~  - Kernel commandline setting
~  - Jump into Linux

No shell, no commands, no display init, no nothing.  If there is to be a
special "I am idle and charging" display, that display is implemented
ONCE in Linux ONLY using X (I dunno it is a great idea to leave the
backlight up while charging).

~ - CPU go to lower frequency.  I think we will find there is a big
difference in power consumption between lower frequency operation and
SLEEP mode in S3C6400.  What I try to do is make the first assumption
every time that we don't reduce CPU clock (although that is MUCH easier
on 6400 than 2442) but we go to the best level of SLEEP.  Sometimes that
assumption won't work out and we will rely on clock reduction or lesser
sleep level.  But this way, the default that we examine each time is
"can we force the CPU to lowest possible power at that time?" and many
times the answer can be "yes" I think.

| Also there is an assumption at every level that the CPU is always up,
| for example during a call at the moment the CPU is assumed to be able to
| continually poll the gsm chipset.  Some folks think about this device as

|> maybe we can consider use a HW_flow-control of UART mechanism ?
|> The S3C6400X UART_0 and UART_1 support auto flow control with nRTS and
|> nCTS signals.
|> (chapter: 31.3.3)

Yeah it sounds good, I didn't examine this circuit.

|> in past, I use GPIO to trigger CPU or GSM:
|
|> GPIO_1 control by CPU, GPIO_2 control by GSM.
|> CPU detect nCTS, and GSM detect nRTS
...

I guess we rely on Linux tty/UART driver RTS/CTS handling for this, but
the idea of flow control signal used for wake sounds good.

|> about the power management of part,
|> Sansung doc (S3C6400X_UM_rev1.00_20080228.pdf, user's manual) say:
...
|> I don't have a system controller manual... so, I can't sure it is
|> workable or not.

Some better data came via Tony, see
SC36400X54_UM_PreliminaryRev0.0_20071019.pdf in the
docs/by_component/s3c6400 folder.  This is meant to be the final chip we
use.  (BTW I find a good way to navigate these PDFs is Ctrl-F then
search for keyword like SLEEP).

It discusses about what the various idle/stop/sleep modes actually do in
there... SLEEP is the one we aim for because it kills the PLLs and turns
off the core, DDR will be in lowest power selfrefresh (~250uA @ 1.8V at
<45 degrees C IIRC).

| ~ - Samsung may force us to have some in the MCP, like the NAND issue.
| We can't waste it then same as we can't waste NAND they force us to have
| in MCP.
|
|> ...about Samsung's policy, I don't have a any commit...

Yes me either.  This is resolved for us anyway we got one choice in the
end apparently.  Using non-MCP and separate DDR is disallowed on space
grounds.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgEXFQACgkQOjLpvpq7dMrnQACfbmctNTvmKYnAAtwudF6fTzbH
WtcAn1uyDYSvpiX8yqY4q6R+EsMfWeMb
=YxUc
-----END PGP SIGNATURE-----