My Gta02s wont charge / chgena = 0 by default

[Andy Green]

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

Somebody in the thread at some point said:

|> because you said: ''It is utterly nonsense to intentionally disable
|> battery charging in any time whatsoever.''  For the pcf50633 case, I
|> don't think you are ready to be so certain either, because when I look
|> at MBCC1 reset state for our variant, I see it wakes up with chgena = 0,
|> so the manufacturer disagrees with you.
|
| No, don't think so. It's the manufacturer's way to say "set max
voltage and
| max current etc, before you even think about enabling charging).

Hey so be careful with the ''in any time whatsoever'' if you like it
disabled at that time :-)

| When we've done this, manufacturer does us the favor to make this
| state "sticky" so PMU will awake from backup-battery with whatever we
decided
| it should. And it should awake with charging nicely configured and
enabled.

The pcf50633 does not include the intelligence to figure out the type of
charger supply available (USB enumeration or 1A charger), so it is not
able to deliver on coming from pcf50633-standby "charging nicely
configured".  What is does deliver is charging forced configured for
500mA USB supply, which is wrong, and we can't change it since that is
forced set by transition to pcf50633-standby using the variant-specific
data.  So we should probably also want to come up from pcf50633-standby
with charging disabled there until we can set correct parameters.

|> |> What makes the trouble is the setting is sticky
|> | that's an *option*, no trouble!
|>
|> Werner seems to blame chgena being sticky in suspend for the failure to
|> charge issue if I read him right (and it sounds right).
|>
|> As for "option" you have to take care.  There are many registers which
|> have a notation "this register is reset in NoPower state".  Because of
|> the privileged position of pcf50633 in the power handling, there is a
|> possible deadlock here where the default state of pcf50633 registers
|> after NoPower does not suit us.  And the CPU being down then, with no
|> other intelligence up, we have no control over that to modify it.
|> NoPower comes when we not only have no power externally or in main
|> battery but the backup battery is down too.  Other registers reset in
|> standby.  It's a maze.
| Yeah, but doesn't apply to our discussion here. We're talking about
return
| from low-bat / suspend, not initial wakeup from a drained backup-bat.

Actually we have to consider all the cases to figure out what to do for
the best.

|> If you look at MBCC7 in the datasheet and our variant data, there is no
|> option here.  In suspend mode usbdevstat gets forced to 01 == 500mA.
|> chgena is sticky in suspend and set = 0 in NoPower.  No option.
| See above.

I see above you saying it was an "option and no trouble".  It isn't.

|> I hope the other notes in this email make it clear we have little or no
|> control over those actions, the variant decides it for us.
| Nope, the variant decides about those registers that are reset on
suspend, and
| it decides on the way the whole PMU comes up from NoPower. We are free
to set
| the "sticky" registers to whatever we think is best for us.

Oh well.

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

iEYEARECAAYFAkhfZGsACgkQOjLpvpq7dMoSuACeOIUdx6dytfz+3EZjOe4sfSxE
kE4AnjAZdThwfeM3o5ZtGa7vorvzLDVU
=a5Zc
-----END PGP SIGNATURE-----