[PATCH 0/3] PMU and Battery interaction in regard to kobject uevent
andy at openmoko.com
Tue Jun 3 13:33:51 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
|> So it looks like it's gonna be cool, but I think we need to make a new
|> kobject to carry these events at platform level, instead of hanging off
|> the battery one, and use platform callbacks opaquely (existing cb or new
|> specific ones) in both pcf50633 and bq27000 to access the platform-level
|> kobject so there is no dependency created between them (and any other
|> drivers that also end up notifying using this scheme). How does that
| Well. We need the kobject of the struct power_supply device. To my
| understanding we exactly need that kobject because it is used for the
| entry of uevent.
So your goal there is really just to push "I am being charged"
notifications into the battery kobject?
| So mach-gta02.c is already handling the callbacks for the pcf50633, if we
| would have access to the kobject if the power_supply of the bq27000
| could send the uevent there.
| So how would we get access to? platform_data is normally just a way to
| data to the driver, not the other way around and we should leave it
| The other option would be the bq27000 informing the machine about the
| (neo1973_set_battery_kobect(struct kobject*))?
If it's just "I am being charged" appearing in battery uevent context
that you are basically thinking about, why not export a bq27000 API that
is just charger_state_change(int) and bq27000 privately makes his own
events on his private kobject in there. You call charger_state_change()
then from platform callback from pcf50633 charger event actions.
It's always legitimate that an external charger would be associated with
bq27000 so this is a feature rather than a workaround.
|> Also, I didn't see yet it broke the guts of the charging tracking patch
|> from me too badly, and it can basically integrated using the new
|> notification action: what is the view from your side?
| Yeah, it would require a manual merge but the same approach would work.
OK, maybe I can take care of that when we get to the bottom of this
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel