[gta04] Meeting minutes for GTA04 discussion 20080411

[Anthony Chang]

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.

yes, I agree your point. we should be made a HW_layout is clearly.
about HW_layout, sorry, I am not professional...

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

I understand, maybe we don't need use GPIO to detect charging.
and show image on LCM for user.

if we don't need display image for notify user,
then I think we don't need turn on and adjust CPU frequency in bootloader.

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