stack_overflow has quit [Remote host closed the connection]
stack_overflow has joined #maemo-leste
exolight has quit [Ping timeout: 268 seconds]
k1r1t0 has quit [Read error: Connection reset by peer]
norly_ has quit [Quit: Leaving.]
Juest has quit [Ping timeout: 268 seconds]
norly has joined #maemo-leste
Juest has joined #maemo-leste
<tmlind>
freemangordon: to me sounds like the issue is that the phy pads don't see the modem k-state wake-up event after ohci runtime suspends when no more active child devices
<tmlind>
freemangordon: when we idle things, everything gets powered off, including the power domain. only the padconf wake-up events work at that state, not the ohci host feeatures
<tmlind>
freemangordon: the HCOCPSYS related stuff and quirks should be already handled by ti-sysc.c driver but as ohci is not in the wake-up domain, it's wake up capabilities won't help
ungeskriptet has joined #maemo-leste
joerg has quit [Ping timeout: 260 seconds]
joerg has joined #maemo-leste
pere_ has joined #maemo-leste
ungeskriptet3 has joined #maemo-leste
ungeskriptet has quit [Ping timeout: 264 seconds]
ungeskriptet3 is now known as ungeskriptet
k1r1t0 has joined #maemo-leste
ungeskriptet1 has joined #maemo-leste
ungeskriptet has quit [Ping timeout: 268 seconds]
ungeskriptet1 is now known as ungeskriptet
ungeskriptet0 has joined #maemo-leste
ungeskriptet has quit [Ping timeout: 255 seconds]
ungeskriptet0 is now known as ungeskriptet
<sicelo>
uvos, do i understand correctly that in sphone config, if in section [Sphone] i remove 'calls' from 'Features', then incoming calls will no longer be handled by sphone?
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #maemo-leste
k1r1t0 has quit [Read error: Connection reset by peer]
ceene has joined #maemo-leste
Enviosity has joined #maemo-leste
ungeskriptet has quit [Ping timeout: 252 seconds]
ungeskriptet has joined #maemo-leste
ungeskriptet6 has joined #maemo-leste
ungeskriptet has quit [Ping timeout: 256 seconds]
ungeskriptet6 is now known as ungeskriptet
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #maemo-leste
<freemangordon>
tmlind: I see. ok, will try to configure wakeirq.
stack_overflow has quit [Remote host closed the connection]
stack_overflow has joined #maemo-leste
ungeskriptet has quit [Quit: Ping timeout (120 seconds)]
ungeskriptet has joined #maemo-leste
ungeskriptet4 has joined #maemo-leste
<tmlind>
freemangordon: yeah try just with one pin at a time for the shared struct device for omap-usb-host.c to see which one works the best
ungeskriptet has quit [Ping timeout: 272 seconds]
ungeskriptet4 is now known as ungeskriptet
ungeskriptet7 has joined #maemo-leste
ungeskriptet has quit [Ping timeout: 260 seconds]
ungeskriptet7 is now known as ungeskriptet
ungeskriptet has quit [Client Quit]
akossh has joined #maemo-leste
stack_overflow has quit [Ping timeout: 255 seconds]
ceene has quit [Ping timeout: 256 seconds]
stack_overflow has joined #maemo-leste
stack_overflow has quit [Remote host closed the connection]
<freemangordon>
Value at address 0x4A1000D0 (0xb6f2e0d0): 0x11F411D
<freemangordon>
Value at address 0x4A1000CC (0xb6f030cc): 0x11D411D
xmn has joined #maemo-leste
<freemangordon>
the same result with usbb1_mm_txen
<sicelo>
arno11 you should use a pastebin, e.g. paste.debian
<sicelo>
paste.debian.net
<sicelo>
also, i would like to get the complete output from that command, even if there are many devices listed there (upower has an extra "DisplayDevice" device)
<sicelo>
and when you take it, ensure all the following conditions are true: (1) charger is still connected, but battery is 100%
<sicelo>
100% according to /sys/class/power_supply/bq27200-0/capacity
<sicelo>
but i might also do the test myself. i do have N900 with working USB, but it has dead modem and dead TS :-P
<sicelo>
so i just use it to charge battery, that i then swap into the n900 that has working modem but dead USB. i should fix the USB actually
duuude has joined #maemo-leste
<duuude>
sicelo: is the fact that it keeps "charging" dangerous? or it is just the way it is in GUI
<sicelo>
just gui mostly. the actual charging is done under kernel control
<sicelo>
again, it's not a problem i experience myself, but when you say always charging, you mean on the status bar, and led stays on blinking orange?
<sicelo>
you can also help by providing the info i requested above. don't worry about the patch for now
<sicelo>
arno11, duuude , here is the revised information that I'd like to get: (1) output of `cat /sys/class/power_supply/bq27200-0/uevent`, and (2) output of `upower -d`
<sicelo>
required conditions when producing that output: (1) device is still connected to charger, (2) sysfs indicates 100% charge
mdz has joined #maemo-leste
<sicelo>
i already see a caveat though ... maybe i shouldn't burden you guys. I'll do the tests :-)
<sicelo>
the caveat is .
<sicelo>
it might start reporting discharging while the charger is still connected :-P
<sicelo>
thanks. i'm also on my N900 now. in the meantime i'm doing some updates (my internet is slow)
<sicelo>
nice, you even got POWER_SUPPLY_CAPACITY_LEVEL=Full !!!
<sicelo>
add the following: cat /etc/modprobe.d/blacklist-upower.conf
<sicelo>
blacklist twl4030_charger
<sicelo>
blacklist bq27xxx_battery_hdq
stack_overflow has quit [Ping timeout: 255 seconds]
stack_overflow has joined #maemo-leste
arno11 has joined #maemo-leste
duuude has quit [Ping timeout: 268 seconds]
<sicelo>
arno11: when you got into the state shown in your pastes, was the charging animation still showing? green led?
<arno11>
sicelo: the charging anim was still there iirc and no green led
<arno11>
in fact, not sure for the charging anim...
<sicelo>
ok, thanks. i see mce looks at each device individualy, instead of using the DisplayDevice like others do. not saying it's a problem :-)
<arno11>
ok
<arno11>
sicdelo: for the blacklisted modules, could you plz clarify a bit ? possible idle blockers ?
<arno11>
*sicelo
<sicelo>
you can ignore them for now ... they're already ignored in mce ... they're additional 'batteries' :p
<arno11>
ah ok
<sicelo>
when i'm done, i'll remove their ignores from mce, because we don't need to be loading them in the first place. ideally we should drop them from kernel config, but i guess they're there in omap2plus in general. so a module blacklist will do just fine
<sicelo>
goodness the locales!!
<arno11>
argh...the locales...
<sicelo>
btw, the animation & led thing was fixed in the past. the trick now is to find what broke
<arno11>
Wizzup: btw what's the plan for locales ? :P just US or UK by default and all others as additional packages ?
<arno11>
sicelo: iirc it was working with last beowulf
<sicelo>
19:17 < sicelo> nice, you even got POWER_SUPPLY_CAPACITY_LEVEL=Full !!! ... < i was looking at the wrong thing. it still said "charging"
<arno11>
you mean in displaydevice ?
<arno11>
maybe my polarcell is not calibrated enough
<Wizzup>
yes, spinal patched upower for the led
<sicelo>
in sysfs ... CAPACITY_LEVEL is something else, which UPower doesn't care about in the case of a battery
<Wizzup>
I don't know if we ported over his patches
<sicelo>
arno11: yes i see you're out of calibration, but that shouldn't cause the problem
duuude has joined #maemo-leste
diejuse has joined #maemo-leste
duuude has quit [Ping timeout: 246 seconds]
noidea_ has joined #maemo-leste
<sicelo>
man ... src/modules/battery-upower.c and status-area-applet-battery/batmon.c are duplications somewhat. would it have been possible to share the code somehow?
<sicelo>
mce for the first path
<Wizzup>
sure, you can put in the work to make it a shared c library and package it
<Wizzup>
I decided it was not worth the effort at the time
<sicelo>
i get it
mdz has quit [Quit: mdz]
mdz1 has joined #maemo-leste
<sicelo>
Wizzup: how to run mce and get logging?
mdz1 is now known as mdz
<sicelo>
arno11: with my patch from yesterday, no charging animation :-P ... so at least status-area-applet-battery is happy. now to figure out why the orange led still blinks. that's mce