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