06:24 <freemangordon> sicelo: I don;t think this is the proper way to fix the issue. Also, you still have to cancel timer_work, otherwise schedule_delayed_work(&bq->timer_work, 0); does not work.

06:24 <freemangordon> did you look at what fremantle kernel is doing to properly refresh the state?

06:33 <sicelo> timer_work has no problem at all. it's not related to the detection issue in any way

06:41 <sicelo> IOW, if there is a problem in the way timer_work is called, it's a different problem, for a different commit. it would not help the reporting of charger

06:48 <sicelo> fremantle kernel doesn't have notifier_call afaict

07:15 <sicelo> mmm, or i'm looking at cssu power kernel, since i see author is Pali

10:28 <Wizzup> btw, I got up to (and just past) hildon-desktop in daedalus so far

10:28 <Wizzup> probably about 33% of the way there or so

10:28 <Wizzup> I forgot just how much work all of this is :D

10:38 <uvos__> Wizzup: i just find it pointless to have finished packages have versions <1

10:38 <uvos__> its not like this package of tiny config files is somehow in beta

10:50 <Wizzup> I mean I suppose

12:01 <freemangordon> sicelo: and how KP does notify userspace?

12:03 <freemangordon> I have the feeling that bq2415x is ignored and it is isp1704/bq27xxx that are used for charger detection

12:06 <freemangordon> sicelo: also, docs say detection timeout is 2 seconds, how comes that we need more then 5 seconds for reliable detection?

14:50 <sicelo> freemangordon: exactly. fremantle's bme uses multiple heuristics to determine battery state. actually it doesn't even use the chips to determine percentage. so yeah, unfortunately fremantle is not a good guide for what to do here

14:52 <sicelo> so, we can do something similar in Leste by simply blacklisting bq2415x. IOW, the problem is not major, as far as Leste is concerned :-)

14:53 <sicelo> however, i do want to get the kernel side to behave better, so we need less device-specific stuff in userspace. hence my desire to make the ONLINE state reporting work ootb, just kernel side. in future, these improvements may help Leste run just fine ootb with upstream upower

14:58 <sicelo> as for the timeout - the docs say typically 2s. they don't have max and min for that particular timeout, which i find interesting. anyway, the very first time you plugin the device, the detection is near-instant. hence, my original patch works. however subsequent plugin builds up more and more delays, for a reason i can't explain. that's why i was wondering if it's perhaps the USB gadget or something

15:01 <sicelo> that said, for argument's sake, let's say it's always 2s. now, you plugin charger, notifier_call gets run, and power_supply_changed() rechecks the flags. this takes ms. by that time, bq24 is still internally trying to detect charging. the uevent will say Not charging, so we haven't achieved our goal. we need a way to wait for those 2s before we run power_supply_changed(), hence i thought that wq was

15:01 <sicelo> best option

15:02 <sicelo> but then, as already mentioned, from testing, the delay can be as high as 8s. a quick way to see it in action is to echo 1 > /sys/class/power_supply/bq24150a-0/stat_pin_enable from a fresh boot, then see how fast the LED comes on. this is completely independent of kernel or userspace

15:04 <sicelo> the slow down doesn't seem to happen when you use a normal charger, as opposed to charging from PC. side note, my el-cheapo, but recent Samsung phones, A037 and A04e also take a few seconds before showing the charging animation. I don't think waiting 10s is that bad, if we were not able to get more instant notification

15:06 <sicelo> at least it's way better than waiting minutes until we infer that we are charging ... we do infer it from the fuel gauge's reported status, but that event only comes after you've gained 1% :-)

15:10 <sicelo> i think, ideally, the STAT pin should have been connected to a gpio or interrupt, instead of only the LED. it would simplify writing the driver more easily. bq2415x_notifier_call would then be kicked by bq24 itself, instead of being kicked by an independent chip, isp1707