<freemangordon>
or maybe use cancel_delayed_work(), not cancel_delayed_work_sync()
<freemangordon>
we don;t really want to wait in notifier function, IIRC it is in atomic context
<freemangordon>
so yeah cancel_delayed_work it is
<sicelo>
thanks. will try that
Anasko has quit [Ping timeout: 244 seconds]
<sicelo>
freemangordon: we definitely need power_supply_changed() somewhere. isn't that what generates the uevent? i guess we should perhaps move it somewhere else ... question would be where?
<sicelo>
i.e. we need power_supply_changed() in addition to the cancel_delayed_work()...
Anasko has joined #maemo-leste
uvos has quit [Quit: Konversation terminated!]
uvos has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
<sicelo>
Lesson #1: freemangordon is always right
<sicelo>
mmm, back to square 1 ... so i used the suggested way, without power_supply_changed. it worked perfectly for first charger insertion. now it's back to the old behavior (ONLINE property isn't getting updated)
<sicelo>
maybe i should add a small delay to schedule_delayed_work :-/
leste has quit [Remote host closed the connection]
leste has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Read error: Connection reset by peer]
<Wizzup>
btw, delta.chat looks kinda neat
ceene has quit [Remote host closed the connection]
fab_ has quit [Quit: fab_]
xmn has joined #maemo-leste
Gary_M has joined #maemo-leste
GaryM_ has quit [Ping timeout: 246 seconds]
LeePen has quit [Read error: Connection reset by peer]
fab_ has joined #maemo-leste
<freemangordon>
sicelo: there might be more than one bug
<freemangordon>
also, do you see a change to OFFLINE on charger disconnect?
<freemangordon>
could be that some state var is not propery updated
<sicelo>
the problem I'm trying to fix is ... when the event fires, it reports wrong online state. however if you manually check online state after the event, it's fine
<freemangordon>
ok, with properly re-queuing wq, does it generate event when it shoud?
<freemangordon>
*should
<sicelo>
timer is like watchdog, yes. it's for ensuring the chip doesn't cause overcharging, etc.
<freemangordon>
sorry, I have no leste n900 around
<freemangordon>
yep, got the docs
<sicelo>
yes, events are sent at the right time (with your wq change, or my original power supply changed)
<sicelo>
just it doesn't update the properties, so event is effectively useless
<freemangordon>
ok, so more than one bug
<freemangordon>
which proerties are not updated when you say reading sysfs returns correct values?
<sicelo>
the ONLINE property is new (was added by me a couple of months ago). however, it's also not just ONLINE that's wrong in event, but also the STATUS ... reports Not Charging. so yeah, common cause, just not sure what source
<sicelo>
sorry I'm on android phone so my typing is a little erratic ...
<freemangordon>
sure
<sicelo>
but have a look at the udevadm output ... you can see event for isp1704, with ONLINE=1. also event for bq24150a,
<sicelo>
status says Not charging and ONLiNE=0 ... this is not correct
<freemangordon>
are you sure? shall it start auto charging? with no user interaction?
<sicelo>
if you now manually check in syfs, you'll see online=1, and status charging
<freemangordon>
ok, then someone is caching values
<freemangordon>
hmm, sec
<sicelo>
we somehow need a way to refresh all properties just before firing the uevent. t
<freemangordon>
mhm
<sicelo>
user interaction is user connecting charger. isp1704 reacts properly, and I'd say it's notifying bq24150 correctly, hence we get bq's uevent. but we seem to report default data in that uevent
<buZz>
maybe the data was cached from previous queries?
<freemangordon>
mhm
<freemangordon>
and the question is who caches the data
<buZz>
maybe just 'override data with known good' on the trigger?
<buZz>
so it can settle later
<buZz>
ah well, that might bite something later
* freemangordon
checks what isp does
<sicelo>
isp is the one doing charger detection. ba24 just charges when it sees power
<sicelo>
*bq24
<freemangordon>
I meant - what isp code is doing
<freemangordon>
sicelo: I don't see any cached data in bqxxx code
<freemangordon>
reading the properties reads registers
<sicelo>
I don't think bq24's problem is caching, yes (because then it would be correct at some point), the behavior hints at just reporting some (uninitialized?) defaults
<freemangordon>
no, how is that
<freemangordon>
it reports nothing basically
<freemangordon>
like, power supply core shall call bq2415x_power_supply_get_property() when it needs a value
<freemangordon>
maybe put printks all over the place to see what happens
<sicelo>
will do
<sicelo>
the ONLINE true does lag by a few milliseconds BTW... so thay could also be it. the uevent fires before it changes
<freemangordon>
ok, then schedule_delayed_work(&bq->work, msecs_to_jiffies(100));
<freemangordon>
instead of schedule_delayed_work(&bq->work, 0);
<freemangordon>
change 100 as appropriate
<sicelo>
yes, that was the last idea :-) will build in an hour or so and report back
<freemangordon>
ok
<freemangordon>
I might not be around though
<sicelo>
[13:22] sicelo: maybe i should add a small delay to schedule_delayed_work :-/
<freemangordon>
yeah
<freemangordon>
but that would not work without cancel anyways ;)
<sicelo>
thanks for looking into my pet problem :-)
<freemangordon>
np :)
<freemangordon>
sicelo: see INPUT POWER SOURCE DETECTION in the doc
<freemangordon>
seems input source detection interval is 2 seconds