<tmlind>
hmm yeah maybe, worth measuring if there is s difference in power consumption after shutdown
peetah has quit [Ping timeout: 246 seconds]
<freemangordon>
do you have d4 with lab psu?
mardy has joined #maemo-leste
Twig has joined #maemo-leste
<tmlind>
yeah i have one wired with an ina226 i2c shunt, afaik power consumption is already very low after poweroff but yet lower after android poweroff. the difference might be missing shtudown functions for cpcap audio or modem etc like you're suggesting
<tmlind>
will measure with your patch at some point when i get a chance
<tmlind>
for runtime measurements, polling the charge counter about once a minute follows the ina226 numbers reasonably close
alex1216 has joined #maemo-leste
pere has quit [Ping timeout: 255 seconds]
akossh has joined #maemo-leste
pere has joined #maemo-leste
uvos__ has joined #maemo-leste
<uvos__>
i no longer have a d4 on psu
<uvos__>
since my main device broke
<uvos__>
so now i use this one
<uvos__>
the difference between android and mainline shutdown is mutch greater on bionic btw
<uvos__>
it uses like 7-8mA
<uvos__>
and was even more recently
<uvos__>
there was an issue where the button backlights wherent turned off proparly, the upstream regulator was disabled
<uvos__>
but the leds where not in cpcap
<uvos__>
the upstream regulator leaked some power even when disabled
<uvos__>
you could even see the leds glow slightly while the device was off
<uvos__>
this is fixed
<uvos__>
by disableing the leds in cpcap on shutdown, but just sayiing its been cpcap before ;)
<freemangordon>
ok, lets wait for Wizzup to land, I guess he will measure the draw with and without the patch, unless tmlind is faster
<uvos__>
btw when considering shutdown voltage
<uvos__>
also consider the bionic, since it takes even loger to boot
<uvos__>
it has to boot android then mainline and then mainline again
<uvos__>
same for d3
<uvos__>
but we could fix that in kexecboot i gues
<freemangordon>
I understand that, but I think we shall not try to support batteries that has 500 mAh capacity left
<freemangordon>
or at least we shall give priority to good batteries over bad
<uvos__>
(ie add something that causes kexecboot to pause if its running on mainline)
<uvos__>
and the battery is low
<uvos__>
another option is also to add charging support to kexecboot, even when running on the android kernel
<uvos__>
and also haveing it pause if the battery is low
<uvos__>
maybe tmlind knows how the cpcap interface on the android kernel works
<freemangordon>
also, I think a simple lowering the mce shutdown voltage from 3350 to 3250 or similar will have great effect on UX while in leste
<uvos__>
i gues maybe you do to since you re'd the blob that uses it to do charging
<uvos__>
this is insufficant
<uvos__>
i tested this alot
<freemangordon>
well, 3300 then
<freemangordon>
or 3299
<uvos__>
the voltage is so noisy i doubt this makes a real difference
<freemangordon>
it will make all the difference on good battery
<uvos__>
i think you massively overestimate how mutch charge remains at so low voltages
<uvos__>
the discarge curve is realy steep here
<freemangordon>
sure, but we need 50 mAh
<freemangordon>
and I bed we have that @ 3.3
<freemangordon>
*bet
<freemangordon>
even for bad batteries
<freemangordon>
also, what we can do for d4 is to disable cpu1 on boot as soon as we have a chance
<uvos__>
im more refearing to that 50mV extra will make a difference
<freemangordon>
sure
<freemangordon>
but we can workaround that by disabling cpu1
<uvos__>
the discarge curve is too steep and the mesurement uncertanty is to high imo
<freemangordon>
but it still depends on the load
<freemangordon>
well...
<freemangordon>
we can at least try to
<freemangordon>
the other option is those with good batteries to have no low warnings
<freemangordon>
and I don;t think that's acceptable
<uvos__>
and we discused how to solve that
<uvos__>
its an independen problem from when shutdown happens exatcly
<freemangordon>
but this is a massive work compared to what I propose
<freemangordon>
also, how is upower going to produce low signals? polling?
<uvos__>
it polls allready
<uvos__>
how do you think mce gets the voltage
<freemangordon>
on kernel event
<uvos__>
no upower polls the battery
<freemangordon>
and by polling, I mean - timer based polling
<uvos__>
im very sure it polls the battery the kernel creates no events for changeing voltage
<freemangordon>
ah, it polls tha battery and when it sees low it generates dbus signal?
<uvos__>
and upower recodes it even
<freemangordon>
I am not si sure
<freemangordon>
*so
<uvos__>
mce just reacts to upowers signals
<uvos__>
they come in regular intervals
<freemangordon>
"/sys" supports inotufy
<freemangordon>
*inotify
<uvos__>
anyhow its imaterial if upower polls or gets a signal form the kernel at regular intervals, the point is upower gets voltage at regular intervals
<freemangordon>
also, if we do that, we risk calibration to never finish
<uvos__>
and could absolutly act on it
<freemangordon>
because it needs low irq, IIUC
<uvos__>
freemangordon: yes this is antoher problem
<uvos__>
it works ok rn tho
<freemangordon>
sure
<freemangordon>
that's why I prefer to keep it
<uvos__>
but yes if you set the tresh very high
<freemangordon>
and just reduce shutdown voltage by a bit
<freemangordon>
combined with idle fix(hopefully) and disabling cpu1 shall be ok
<freemangordon>
also, I will start working to bring charger detection at some point
<freemangordon>
and then we'll be more or less fine, no matter the charge
<uvos__>
iirc on android this works via cpcap-uc
<uvos__>
detection
<freemangordon>
well, 'almost'
<freemangordon>
ok
<freemangordon>
so, really, lets at least try what I propose. we can always revert it
<freemangordon>
assuming poweroff fix works
* freemangordon
checks what cpcap-uc is
<uvos__>
i came up with the current value by doing testing, chainging it just because you think is ok (and we use very good batteries so ofc its going to be ok for us, but it wont for others) is absurd
<uvos__>
freemangordon: microcontroller on cpcap
<uvos__>
android uploades short macros to it
<freemangordon>
uvos__: you checked in different conditions
<freemangordon>
now I propose to change the conditions and test again
<uvos__>
i dont see how you having a good battery now are valid conditions
<freemangordon>
1. you reserved some charge because of the idle draw, now that's (hopefully) fixed
<freemangordon>
I have a bad battery too
<freemangordon>
and another device to test with, if needed
<uvos__>
for sure you have not fixed it on bionic
<freemangordon>
how do you know?
<uvos__>
because i doubt that the same issue uses mutch more power on one device than the other
<uvos__>
ie there are at least 2 issues
<freemangordon>
why not, modem firmwares are diffirent, no?
<uvos__>
yes, slightly still i doubt
<freemangordon>
and 'fixing' it by putting a band-aid (lets shut down @ 3.35) is not a real fix
<uvos__>
never siad its a real fix
<freemangordon>
so, lets try to properly fix it
<uvos__>
how
<uvos__>
the real fix would be to drop every mapphone besides xt910
<freemangordon>
modem shutdown is step 1, for sure
<uvos__>
(wich has no locked bootloader)
<freemangordon>
disable cpu1 is step2
<freemangordon>
what you proposed (charge in kexecboot) - step 3
<uvos__>
you could also build cpcap modules into kernel
<uvos__>
to make it charge slightly sooner in boot
<freemangordon>
right
akossh has quit [Quit: Leaving.]
alex1216 has quit [Ping timeout: 252 seconds]
alex1216 has joined #maemo-leste
pere has quit [Ping timeout: 252 seconds]
<sicelo>
freemangordon: what do you mean 'bring charger detection' ... or you mean to kexecboot?
<uvos__>
sicelo: cpcap-charger dosent negotiate for power via usb protocoll
<uvos__>
nor dose it recognize the tied datapins signal
pere has joined #maemo-leste
<uvos__>
it just takes 500mA, no matter if the port supports less or more than that
<sicelo>
ok
<uvos__>
this causes additional headaches at boot
<uvos__>
as the device will continue to discharge even after enableing charging
<uvos__>
until its truely done with booting
nedko has quit [Remote host closed the connection]
<uvos__>
chipset can do good pm, but it is not teribly great on mainline
<uvos__>
note that everything only works on xt1602, (ie european variant) other people have wierd issues with the other variants
<Wizzup>
yeah I saw that on the wiki page
<Wizzup>
*shrug*
<Wizzup>
it would be good to support some of those, but it doesn't seem like it's only a little bit of work
<Wizzup>
I wonder if they have scripts for pm for example
<Wizzup>
and if it works with ofono (it mostly mentions mm, probably because phosh wants that)
<uvos__>
it works with ofono
<uvos__>
at least in very basic capacity
<Wizzup>
ok
<uvos__>
i dont think it would be mutch more work than mapphone bringup
* Wizzup
going to rest for bit, bbl
<uvos__>
to get it to the state of pp
<Wizzup>
right
<uvos__>
gn :P
<uvos__>
still on us clock i imagine
<Wizzup>
mostly just no sleep during travel, and I have more work in a few hours :)
<Wizzup>
but yes, also on west coast clock
<norayr>
i even think of n9 sometimes because it also looks good, i like square corners, jolla is pretty good looking for me. but i understand it is very difficult to find n9 with good battery and it is d to replace it.
<norayr>
and jolla has no mainline support.
<norayr>
i have the device and i dont use it. just hope it will have better mainline support one day.
<uvos__>
i kinda think the n9 is a poor target, it dident sell nearly as well as mainstream android devices and its hw was really outdated even when it was released
<norayr>
in generally it would be great to be available on something which is produced today.
<uvos__>
with a keyboard in d4 size :P
<uvos__>
i gues they still make the pp, at least the pro
<freemangordon>
not sure this one is good though, but you got the idea
<sicelo>
yes, no nexus phones ever landed here. anyway, i don't mind the capacity of this battery atm since i don't really use the droid 4. just boot it to update once in a while.
nedko has joined #maemo-leste
<freemangordon>
it is not about the capacity
<freemangordon>
but about the internal resistance
<freemangordon>
keep in mind that it is possible that eb41 BMS might cut off the connection under some unknown conditions
<freemangordon>
for example, the battery of the second d4 I have here (the one I used as a donor for battery circuit) was providing 0V at the terminals, despite the cell was @ 3.8V
<freemangordon>
I had to connect a charger to make it provide voltage
<freemangordon>
we don;t know what else protection logic there is
<Wizzup>
nedko: I'll get you the sticker files tomorrow
<nedko>
Wizzup: great, thanks
<uvos>
my d4 also ocassionaly hangs and watchdog reboots
<uvos>
its mutch less often than it used to
<uvos>
but it still happens
<uvos>
its def a hang and wd reboot
<Wizzup>
was the microwave wifi problem ever fixed?
<uvos>
because i use the device to listen to music alot, and when it happens the music will loop for a while untill wd kicks in
<uvos>
Wizzup: no idea, its at least better, it used to crash very often when loosing wifi
<uvos>
but havent tested that explictly
<uvos>
the wd reboot ends with no logs in pstore
<uvos>
hmm
<uvos>
maybe the reason why i dont see the wifi hang anymore could also be because i use gprs now while under way
<uvos>
so the device dosent autoconnect to public wifi aps anymore
<sicelo>
i would agree to the hang + wd observation