-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: > Andy Green wrote: >> Why do we still have charging logic in U-Boot at all? > > So far, all this is about the maximum supply current we can draw. > Whether we charge or not doesn't really matter.
Charging obviously affects the maximum current we choose to draw, but I take the point. I think of it as "charging logic" because that was the last work I did on it and the basis I was thinking about for a wider solution there. I just had to do various exciting things like clean out the cat litter and I had a chance to think at a bit more length about what is bothering me about this sequence of events today. Earlier in the thread that wasn't on the list, I proposed this (about the PMU and charging overall): ''We need to stop on that and write up the full behaviour in English that we are aiming for, then implement it in one step. Currently there is no actual definition of all the corner cases and behaviours we aim for, which is why we stepped into this 100mA mantrap already.'' For a commercial project, the system side at least of GTA02 (and 01 before it evidently) are pretty woefully specified. The plan is to rely on the coders on the ground making decisions that result in the "right" things happening. Generally we are fairly good at doing the right thing, but because there are more things to look after than there are hands to do it, and different hands have different ways to come at it, one way or another the right thing sometimes isn't done, or stuff is done without a holistic overview. Your reply (quoting me): '' > It's usually not a good sign when we can't articulate > what it is we are trying to achieve :-) ...and are about > to commit it to write-once memory. Duh. Code speaks louder than words ;-)'' Well that is right: because you didn't post what you have done to the list, I won't see it, it is just directly committed as you insist to do without review: a fait accompli without other input as if it was your private project and other opinions are worthless anyway. At the same time, the idea of drawing up a specification for what we try to achieve as an end result is undermined. Both of these things bother me because they turn their back on the advantages of both really open development and basically the company development process being something other than random surges of one man hacking -- as it is, it seems to implicitly assume what you are doing and the choices you made are already perfect all the time, and that would be a dangerous conceit. (As you know I post all my patches here for review). I have a great reference on the value of review I will write up elsewhere. At least until now we didn't take care of PMU events happening inside U-Boot, for example with a battery in we swap USB power sources in U-Boot we will not react. (If you did eat PMU events in your patch, you need to take care that Linux will no longer see the initial interrupt sources.) Did we take care of the situation that we started with a 1A charger and then swapped to a laptop port in U-Boot? I dunno because I have never seen any of your patches, and we didn't plan for it. Maybe it is fine this time, next time too, but it isn't really the point. >> Are we planning on having charging logic in this minimal bootloader that >> is to replace U-Boot? > > I hope not :-) Almost everything we are doing in U-Boot is waste because we will abandon it soon, NOR U-Boot especially so. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFH1Ek2OjLpvpq7dMoRAjeMAJ46VZR+WWdeFsJ97WtL0kV5s+5LNQCgjXmn iFlWdmmQ+nGVsumjQCuRhEo= =7FIe -----END PGP SIGNATURE-----
