vgratian has left #maemo-leste [Error from remote client]
__20h__ has quit [*.net *.split]
_alice has quit [*.net *.split]
__20h__ has joined #maemo-leste
_alice has joined #maemo-leste
Livio has joined #maemo-leste
Livio has quit [Ping timeout: 245 seconds]
Livio has joined #maemo-leste
pere has quit [Ping timeout: 272 seconds]
xmn has quit [Quit: ZZZzzz…]
mardy has joined #maemo-leste
xmn has joined #maemo-leste
Livio has quit [Ping timeout: 245 seconds]
Daanct12 has joined #maemo-leste
Danct12 has quit [Ping timeout: 255 seconds]
Livio has joined #maemo-leste
Daaanct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 268 seconds]
macros_ has joined #maemo-leste
vagag has joined #maemo-leste
pere has joined #maemo-leste
uvos has joined #maemo-leste
luciamber[m] has quit [Quit: You have been kicked for being idle]
<Wizzup>
uvos: I made a few calls and the speaker and handset switching works fine )on the d4 at least)
<uvos>
Wizzup: great :)
<uvos>
could you try the pp?
<uvos>
and if that works ill promote sphone
<uvos>
maybe after your rtcomm patch
<uvos>
if thats comeing today
<Wizzup>
should, but my day's been filled with work and meetings
<uvos>
ok
<uvos>
but you have a pp around?
<Wizzup>
yes
<uvos>
ok
<Wizzup>
I will also test the other thing you asked me to test out
<uvos>
thanks yeah
<Wizzup>
I just want to do the rtcom el patch first
<uvos>
that ones wierd, it worked on pp before and still works on bionic and d4
<uvos>
but multiple people have reported it
<Wizzup>
btw, I've "received" the same sms about 9 times today on my d4
<uvos>
yeah i have seen that
<Wizzup>
just got it again :D
<uvos>
ofono is a mess still
Pali has joined #maemo-leste
<Wizzup>
I think it relates to me turning on the screen or something
<Wizzup>
ah, got it 3 times
<Wizzup>
odd
<uvos>
might be mce kicking the modem
<Wizzup>
right
<uvos>
and ofono failing to tell the modem its been recieved or somehting
<Wizzup>
I am not sure if the problem is ofono or the kernel
<uvos>
dunno yeah
<Wizzup>
we should probably try it with the power consuming ofono as well, just to see if that works fine
<Wizzup>
(the other ofono driver)
<uvos>
the whole modem infra also behaves really wierd in a different way
<uvos>
so i have a contract with 2 sim cards
<uvos>
and often when the d4 is with the sim unlocked the other device wont be able to make or recive calls or send or recive sms
<uvos>
as if the operator thinks the d4 is sending something on gsm
<uvos>
(other than data)
<uvos>
this even presits if the device is turned off
<uvos>
the only way to make it go away is to reboot the d4 into android and connect to the operator there
<uvos>
or wating a couple of h
<Wizzup>
odd.
<sicelo>
the issue with droid-4 refusing to charge if booted from cable is a bit annoying (because how else do you boot from a depleted battery?). anyway ... most times, the kernel is able to start, but then you have to know when to remove cable, and reinsert it (i think buZz explained this a couple of days/weeks ago).
<uvos>
i dont see this
<uvos>
but i can see why it would happen
<uvos>
depending on when the charge enable interrupt comes in it will fail to work
<sicelo>
i was wondering - would a forced reset in kernel be helpful *after* the module has loaded. clearly reinserting usb cable works, so i suppose a forced reset in s/w should help too
<uvos>
depending on when cpcap-battery probes realatvie to cpcpa-mfd
<uvos>
sicelo: not sure what you mean by reset
<uvos>
sicelo: the way it works is cpcap fires an intterupt when the interrupt is enabled
<uvos>
depending on how it goes timeing wise thats before the kernel is ready to start charging
<uvos>
im not sure if theres a register you can read to see if the usb cable is plugged in
<uvos>
iirc alot of the other negotaing stuff goes by the fw
<uvos>
which we dont understand at all
mrkrisprolls has quit [Ping timeout: 260 seconds]
<uvos>
id have to check
<uvos>
a temporary fix might be to just build the charger module into the kernel
<uvos>
that would help with booting with a low battery anyhow since charging would start earlyer
<sicelo>
maybe that's what should be done then
<sicelo>
or delay loading the charging module until things have settled
<uvos>
the problem is that the intterupt infa is enabled by the mdf code
<uvos>
not the charging module
<uvos>
*mfd
enyc has joined #maemo-leste
<sicelo>
mmm. this is kernel code you're talking about? or firmware that we have no control over?
<sicelo>
(mfd code, i mean)
<uvos>
kernel code
<uvos>
another way that might also work ist to just enable charging unconditionally on probe
<uvos>
and just let the vbus low irq disable it again
<uvos>
if vbus is low
<uvos>
ie 0v
<sicelo>
oh btw, this happens even when battery has power (just in that situation, you can simply boot without the cable)
<sicelo>
anyway ... hope someday a solution will be found
mardy has quit [Ping timeout: 268 seconds]
akossh has joined #maemo-leste
<uvos>
sicelo: yeah the driver just tries to read CPCAP_REG_INTSx at boot
<uvos>
of you cant expect that to show the current state, or even to contain valid data at all if you just read the irq state registers without wating for cpcap to fire an irq
<uvos>
no suprise its buggy and behaves inconsistantly
<uvos>
looks like android itterogates the fw
<uvos>
we cant do that
<uvos>
ofc that dosent mean its the only way to gain the information
mardy has joined #maemo-leste
<uvos>
looks like while i cant repo this on d4 i can on xt875