GTA series power design

[Andy Green]

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

Somebody in the thread at some point said:

|> If Linux makes requests to the MPU using a simple API, we can hide
|> details like which PMU is used because we get a manifest from the MPU
|> (this device has touchscreen, backlight, WLAN power, etc) and scan ask
|> for "Backlight off"... how that is done Linux doesn't have to care even
|> if on another variant we changed PMU.
|
| That scenario should be fairly straightforward to support with the
| framework - the regulator chip driver interface uses a series of fairly
| high level callbacks:

I noticed "Wolfson" in connection with the regulator API... it seems
like a fine effort.

| If the MPU was doing the actual PMU control then you could hide as much
| information about the interconnects as you feel like in there.

Yes... as much as is wise anyway.

It's really a choice about whether the MPU or CPU controls the PMU.  But
~ the same question appears for many other peripheral assets.  If the CPU
is responsible as in the GTA02, since the CPU is not always up,
sometimes UI behaviours will stutter or be flat out missed if we rely on
the CPU to capture or process them.  And I want to see the CPU kept down
as often as possible for as long as possible, same way we don't leave an
LED lit longer than we need.

What I think will be ideal is if all UI IO is managed by the MPU with
the goal of 100% consistent device behaviours as far as possible whether
the CPU is up or not.

I sent a PDF to the list with the kind of architecture I am thinking about.

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

iEYEARECAAYFAkfyUWAACgkQOjLpvpq7dMpBpQCcC5+lcs9UHTlfbJG0JvkDtxLC
dX0AnRa/HB2tppwvABZVwhvZ4RdD6kru
=BRQS
-----END PGP SIGNATURE-----