tvall has quit [Read error: Connection reset by peer]
tvall has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
joerg has quit [Ping timeout: 248 seconds]
joerg has joined #maemo-leste
_Gary has joined #maemo-leste
Gary_M has quit [Ping timeout: 248 seconds]
fab_ has joined #maemo-leste
xmn has quit [Ping timeout: 252 seconds]
xmn has joined #maemo-leste
leste has quit [Remote host closed the connection]
leste has joined #maemo-leste
ceene has joined #maemo-leste
fab_ has quit [Quit: fab_]
<freemangordon>
sicelo: ok, we shall read the tocs more carefully then, taking 8s for bq to report status does not seem like HW issue, but rather how it is programmed
<freemangordon>
*docs
<freemangordon>
sicelo: it seens this 2s timeout is to re-start charging on temporal low input voltage, see "Input Source Detection"
<freemangordon>
*seems
fab_ has joined #maemo-leste
<freemangordon>
so, I would think that we shall have (almost) immediate status change
<sicelo>
freemangordon, have you done the LED test?
<sicelo>
we can report instantaneous charging state if we want, by simply setting ONLINE true when reported_mode changes in notifier_call. but that's cheating, because in reality, the chip has not yet decided that we're charging or not. it's possible (although not very likely) that it'll end up in fault state instead
fab_ has quit [Quit: fab_]
<sicelo>
that's why I prefer we rely on the STAT_1 & STAT_2 flags, which the STAT pin also uses
<sicelo>
i have looked at the docs multiple times, and i have never seen a way to influence how fast the detection/reporting takes place
<sicelo>
anyway, i guess in the meantime we can drop the whole thing, blacklist bq24 in the status applet, so it will automatically switch to tracking isp1704.
leste has quit [Remote host closed the connection]
leste has joined #maemo-leste
<sicelo>
but please do the STAT pin LED test, or someone else can do it and report their result, so we're sure i don't have a broken N900. Wizzup, arno11 ...
xmn has quit [Ping timeout: 252 seconds]
<sicelo>
echo 1 > /sys/class/power_supply/bq24150a-0/stat_pin_enable from a fresh boot. plug in charger, note how fast steady amber LED comes on. disconnect charger. reconnect it, not when steady amber LED comes on. repeat as much as you can afford to
<sicelo>
s/not/note/
<freemangordon>
sicelo: will do once I am home, next week
<freemangordon>
in the meanwhile it will be good if arno11 does it
<freemangordon>
however, it is not reasonable charging detection to take 8 seconds
arno11 has joined #maemo-leste
<arno11>
sicelo: on my device, the amber led never comes
<arno11>
(leds work fine on Fremantle)
<arno11>
the green led is ok
<sicelo>
arno11: that's not possible. did you do the stat_pin_enable?
<arno11>
let me try again (sorry, not too much spare time atm)
<sicelo>
arno11: ah, what you're talking about is what i want to fix. you mean it never comes when running 'normally' :-)
<arno11>
yes indeed
<sicelo>
but yes, please do the test mentioned above. no rush. note how fast, or how slow that amber led comes up, each time you plugin charger
<arno11>
ok no probs
<arno11>
results in sec: 9, 7, 8, 0, 0, 0
<arno11>
if i wait a couple of seconds and test again, same results
<arno11>
that's a bit random
<arno11>
now: 6, 0, 0
<arno11>
5, 0, 0
<arno11>
7, 0, 0, 0
<sicelo>
thank you so much! you're testing with a real charger or port on pc?
<arno11>
and now after waiting 30 sec to plug it again: 0, 2, 2, 3, 7
<arno11>
i use a real charger
<sicelo>
perfect. thank you ;-)
<arno11>
no probs
<sicelo>
don't forget to zero the stat_pin_enable sysfs node
<sicelo>
if you want, i can share the fixed charger driver corresponding to my PR. amber LED works with it
<arno11>
yup already set to zero, no rush for amber led :) , thx anyway
Anasko has joined #maemo-leste
Anasko has quit [Read error: Connection reset by peer]
Anasko has joined #maemo-leste
uvos has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
<uvos>
so the problem is that sometimes the chip takes a long time to detect?
<sicelo>
let me say, long to report
* sicelo
is 99% sure his fix is correct
<uvos>
sicelo: ok so i gues you sleep for the maximum time so that you allways catch the register state after it has "settled"?
<sicelo>
yup
<uvos>
if the time is very variable (like arno's msg seams to suggest)
<uvos>
i gues it would be better to use a periodic timer to poll the state for 10s, so most of the time it finishes sooner
<sicelo>
in reality, we run call power_supply_changed() three times for every charger insertion or removal, since for some magical reason, the PHY sends events twice
<sicelo>
so if your device is in 'fast mode' so to speak, then it doesn't wait for the 10s at all
<uvos>
i see
<uvos>
ok
<sicelo>
also important to note that this whole dance doesn't affect charging itself ... chip is charging just fine. this is only about reporting to userspace. i don't think we have a very big need to report very quickly, especially here the delay is in the hw itself. so that's why i'm not really in favor of polling
<uvos>
well 10s is a long time
<uvos>
the user might get confused and think something is wrong with his cable etc
<uvos>
so i can see the apeal of keeping this responsive
<sicelo>
my samsung phones, for some reason i don't know, also take a little while
<sicelo>
anyway, if we really want this to be snappy, then sure, i'll restore the blacklist in the status applet. that causes it to use the PHY for reporting, and that microsecond fast. then we can leave bq to take its 10s and userspace won't even know about that
<sicelo>
still curious what causes the bq to be very fast first time, then start delaying. maybe there was (or should have been) some errata for it :)
JKShadow has joined #maemo-leste
ShadowJK has quit [Ping timeout: 246 seconds]
_Gary has quit [Ping timeout: 260 seconds]
DFP has joined #maemo-leste
<uvos>
mz617 sensor suite is quite extensive
<uvos>
we have a max9635 als (no driver in mainline), a lis3dh accel, an akm8975 compass, a l3g4200d gyro, a bmp180 pressure sensor, and an attiny48 driveing a custom pannel wide capacative proximity sensor (for the pen i presume)
<sicelo>
docs for the als available?
<uvos>
yeah
narodnik 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]