[PATCH 0/2] Charger monster taming

Andy Green andy at openmoko.com
Tue Jul 22 21:11:10 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| On Tuesday 22 July 2008 19:16:02 you wrote:
|> mach-gta02.c doesn't directly deal with pcf50633_charge_enable or
|> charger enable after this patch at all.  The only thing it glues
|> together now is the USB enumeration event to pcf50633 world, but it does
|> that by calling an opaque export from pcf50633 which then does the
|> pcf50633_charge_enable call on that side of the fence.  So pcf50633
|> charger got a little bit more selfcontained and mach-gta02.c needed to
|> know less detail about the PMU.
| my bad. My memory confused the call to
| pcf50633_notify_usb_current_limit_change
| with pcf50633_usb_curlim_set.
| So there are two ways we end up enabling the charger?
| 	- pcf50633_work_usbcurlim (triggered from mach-gta02.c)

Yes, only via pcf50633_notify_usb_current_limit_change(), that's the
only related call in mach-gta02.c.  In one patch coming shortly I remove
the exports for setting curlim and charger enable completely and put
them as static, because it's not anyone's business except pcf50633
driver to deal with that at that level (and if we leave 'em in,
someone'll use them).

| 	- configure_pmu_for_charger (triggered through interrupts)

Yes, I think it's true.  And we need both because of the 100mA
pre-enumeration limit at USB insertion / PMU interrupt time does not
enable charging, but subsequently without further PMU interrupts we get
notified we're good for 500mA and now we can enable charging.  So I
think it hangs together.

|> Too late, but good advice.  It doesn't affect the code just the patch
|> beauty level.  I find unless I layer them while I do them often stuff
|> gets mingled in single patch stanzas and then it is hard to pick them
|> apart.  And when I am sweating about what I am doing, I don't even know
|> the patch is viable until it works much later so beautification seems a
|> double waste.
| hehe, this is what git-add -i is for :)

Yes with stgit there is stg edit -d where you can edit the diff directly
too.  But it doesn't help when "stuff gets mingled in single patch
stanzas", sometimes even layers of edits to the same line.  I definitely
like the broken out approach and try to do it, but sometimes it ain't
happening.  Other times you know it'll work and can plan ahead easy.

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


More information about the openmoko-kernel mailing list