[gta04] Meeting minutes for GTA04 discussion 20080411

[Anthony Chang]

hi Andy,

very thank your reply, this my honor...



Andy Green 提到:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Somebody in the thread at some point said:
>
> Hi Anthony -
>
> I changed this to kernel list to save Wolfgang some blood pressure :-)
>
> |> My consider is a some user case:
> |
> |> I think if the vibrator is active, it notified the user of some
> |> message(or something), Next we need turn on LCM and display an 
> image for
> |> user(like call-in, SMS, alarm&etc.). At moment, the S3C6400 and MCU is
> |> active. Because LCM control by S3C6400.
> |> keypad same as vibrator, user press keypad do something, then LCM also
> |> need turn on and display image for user, Even touch-screen. If our
> |> handset doesn't turn on a LCM, the user can't to identify what 
> happen on
> |> our handset.
>
> Sure.  I guess I may have made it sound like we should never turn the
> S3C6400 on :-)
>
> I propose some guidelines about it without mentioning MSP430.  I try to
> consider in this mail working without MSP430.
>
> ~ - if the LCM backlight is powered, the S3C6400 MUST also be active,
> because it provides the video data for the LCM.
>
> ~ - the phone usage has "modes" or "states", ie, standby, in a call, user
> is using applications.  When the phone is stuck in a state, it can turn
> off everything it doesn't need in that state.  That includes when we are
> "in a call", we don't need the LCM or the CPU.
>
> ~ - User interaction with the phone moves us between states.  If we
> didn't see a button or touchscreen or motion, we remain in the state.
> For example if we are in a call, we stay "in a call" with CPU and LCM
> off until the user wants to hang up or the other side hangs up.
> Likewise, if we go to deep standby, we stay in standby until incoming
> call, buttons pressed, etc.
>
> ~ - If we see any user interaction with the phone, ie, touchscreen,
> buttons, we always power the LCM backlight and S3C6400 ready to respond
> to what it is he wanted to do
>
> ~ - If there is no user interaction with the phone or other events, we
> move to "Deep Standby" after a little timeout, with LCM backlight off
> and CPU off.
>
> |> if main function active will be influence to S3C6400, let S3C6400 is
> |> active.
> |> maybe we can move these key/main functions into S3C6400. next, we 
> remove
> |> MCP430, then an other function (except: keypad, vibrator&) replace by
>
> 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.

of course, we can discuss other method for our project.
>
> Stuff that goes through the CPU has dead-time when the CPU is down, and
> loads the CPU when it is up.  For example, currently the motion sensors
> generate 200 or 800 interrupts a second on the CPU all the time neod is
> up, this has a power dimension.  But in truth, we can improve that using
> the thresholding on the sensors and improving the driver around that.
>
> 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
> a desktop linux box not a mobile device that has to take care about
> battery life at each step, and the CPU running is pretty expensive.  To
> get really good use from the battery we need to adapt that thinking to
> understand that the CPU is expensive and should not stay up when it has
> nothing useful to do.
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)

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

if CPU need send AT_CMD into GSM, then detect nCTS.
if nCTS is high, then use GPIO_1 to trigger GSM. next detect nCTS again
(loop and need setting timeout)
until nCTS is low, next CPU send AT_CMD into GSM
the CPU behavior same as GSM, use GPIO_2 to trigger CPU

if nCTS/nRTS is low, then send AT_CMD immediate

about the power management of part,
Sansung doc (S3C6400X_UM_rev1.00_20080228.pdf, user's manual) say:

chapter 1: 1.2 POWER MANAGEMENT
• Clock-off control for individual components
• Various power-down modes are available such as Idle, Stop and Sleep mode
• Wake-up by one of external interrupts or by various interrupt sources. 
Refer system controller manual.

I don't have a system controller manual... so, I can't sure it is 
workable or not.

>
> We can still meet the gsm polling if we schedule wakeups from deep sleep
> externally or via RTC to do the polling, we still spend the vast bulk of
> time during the call with the CPU down.
>
> Something else is that we won't achieve really instant suspend and
> resume with Linux.  Depending on what the Samsung BSP drivers act like
> it can be many 100ms each way or variable.  Its possible this laggy
> behaviour will make a bad user experience.  We can find out about this
> when we have the BSP and eval boards.
>
> |> other chipset/component. Thus, we maybe can try to reduce cost.
>
> Let's identify what that other chipset/component does and costs then we
> can compare it.  I don't have shares in TI :-) but I know MSP430 is very
> low power and Milosch for example had success with it.
>
> | ~ - Split mDDR 64 / 64 is not ideal, external bus routing for mDDR is
> | likely to be challenging. We can end up that the external bus routing
> | slows down even the internal MCP mDDR. It is better if Samsung can
> | provide 128MB mDDR on the MCP (and no NAND!), I understand we don't
> | control that, if we can't do it well ok.
> |
> |> I don't suggest use MCP (oneNAND 256MB, mDDR 64MB).
>
> Well see a bit later about mDDR / MCP discussion.
>
> |> I get a some message: the kernel, root-fs.img, home.img will be to 
> place
> |> into internal SD card. If this right, then the oneNAND will be to 
> place:
> |> bootloader& (I guess also have: SIM-IMEI, network NIC-MAC address& I
> |> can't sure. Somebody can tell me? Please)
> |> If data size is very small in oneNAND, I think it is an extravagance.
>
> Right.  We perfer not to have the NAND at all and use a small 256KByte
> NOR to hold the bootloader.  It is not clear if Samsung will force us to
> have NAND in the MCP.  If they force us to have it, we cannot waste it
> :-(  It will mean we have to put stuff in there and that means all the
> crap about bad block management, JFFS2 and so on.
>
> These MCPs with NAND and mDDR in there rock... IF they give you the
> ingredients you want.  If they give you the wrong ingredients (NAND we
> didn't want, not enough mDDR) it will make pain.
>
> |> Second, if we need add extra mDDR (64MB). Why can't combine both
> |> (internal and extra mDDR) to become a single extra mDDR_128MB? or
> |> replace by other DDR?
>
> There are two issues with the mDDR.
>
> ~ - 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...

> ~ - external mDDR requires tight tolerance in PCB routing and techniques
> like impedence matched routing.  I don't know how good a job we will do
> on that if we didn't have experience of doing it before or the CAD
> software doesn't support impedence / length matched routing.  We can end
> up with degraded or unreliable memory bus performance quite easily.  So
> it is ideal if we can get 128MB of mDDR in the MCP and no NAND.
>
> But if we can answer the second part about PCB routing, and Samsung do
> offer the CPU with no memory in MCP, then actually I think that is not a
> bad way.  We can get away from NAND, take our own responsibility for
> mDDR and have a small NOR for bootloader.
>
> |> Third, the cast view: chipset/component should be share with other
> |> project/platform
> |
> |> Example: if we can select 2 component on our project, and each unit
> |> price is same:
> |
> |> 0  5000 pcs = $ 5/pcs
> |
> |> 5001  10000 pcs = $ 4.8/pcs
> |
> |> 10001  20000 pcs = $ 4.5/pcs
> |
> |> 20001  30000 pcs = $ 4/pcs
> |
> |> 30001  50000 pcs = $ 3.5/pcs
> |
> |> &&
> |
> |> In GTA04, we need 15000 pcs.
> |
> |> Next project/other platform, we need 13000 pcs.
> |
> |> If 2 project component is different
> |
> |> Cast = 15000 * 4.5 + 13000 * 4.5
> |
> |> If 2 project/platform use same component:
> |
> |> Cast = (15000 + 13000) * 4
> |
> |> I think this component is difficult use on other platform&it is almost
> |> bind on Samsung's product.
> |
> |> I suggest we can use common/universal flash and DDR.
>
> I am not sure that for a company like FIC, the pricing is quite as fixed
> as it is for small companies as you show.  Even for smaller companies,
> it's often possible to negotiate starting at one or two price breaks
> better if you can convince the vendor you have a good chance to reach
> high volumes.  When the volumes can be very big like with FIC, probably
> a vendor might support a low volume introduction at higher volume
> pricing routinely just to get the design-in.
don't think too much please, just a example. my mean is if we can booking
more, then we can reduce cost more...
>
> But I agree about component reuse for a different reason.  Once we get
> anything working, software or hardware, it's pretty cheap and low risk
> for us to deploy it again.  We already have proven schematics and
> drivers and so on.
>
> We are fixed on whatever CPU we choose for the same reason, once we took
> the hit of prototyping it and getting it working, we are going to want
> to amortize that over more than one design.  (This is doubled when you
> consider the software investment in getting Linux working well on the
> platform).  On the subsequent designs, the risk is low for us because we
> deploy the same schematics we just had success with.  So it isn't a
> consideration to be locked into a particular CPU for some period, we
> actually want that.
>
> - -Andy
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkgDO6MACgkQOjLpvpq7dMrUjwCfbaffiNzZQXuDSvXpskW+Bstd
> mFEAn3fqYuYkKknypvw9agjyAqd0BLQY
> =Gfwr
> -----END PGP SIGNATURE-----