<buZz>
but i now have a 1750mAh reporting BMS , on a 2250mAh battery :)
<buZz>
considering my options here , i could just make charge_full_design writeable? :D
<buZz>
or eh, add a option to charge beyond charge_full_design
<buZz>
oh, 6*x/5 , it allows ~20% higher
<buZz>
i wonder whats the motivation for the 20% , if we could stretch that to 30% , 2250 would fit :P
<buZz>
maybe (4*x)/3 ?
<tmlind>
buZz: maybe add a module option to use a generic battery and ignore the eeprom?
<tmlind>
or a module option to force e960 battery, then we could have a proper profile for it
<buZz>
hmm, well, atm its still charging, takes forever :P
<buZz>
and i'll make charge_full be 2088000 for now (the max this 6/x*5 allows)
<tmlind>
buZz: how about modprobe cpcap-battery batt_type=polarcell_lg_e960 or something similar
<tmlind>
then ignore eeprom, keep the temp sensor in case it's wired to the eb41 pcb
<tmlind>
then additionally ignore_temperature_probe=1 option can be used if using uvos' pcb
<buZz>
would be nice yeah, but this is not my area of expertise :P
<buZz>
a batt_type would be best i guess
<tmlind>
uvos: would the above work for you for module options?
<Wizzup>
freemangordon: sapwood has a commit in -devel that's not in normal beowulf, I think we can move that to normal beowulf, yeah?
<Wizzup>
dsme needs some fixes, will do when I get back
norayr has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
<Wizzup>
Pali: I think I need some help with the u-boot thing that Tom is asking about, I really don't know where to start
<Pali>
hm... I just do not know where to start too... Maybe asking Tom for that?
norayr has joined #maemo-leste
<sicelo>
OAOB
uvos has joined #maemo-leste
<uvos>
tmlind: sure yeah @ options
<uvos>
buZz: for now just blacklist the one wire interface module
<uvos>
that way you will not get 1750mAh as charge_full_design instead you will get something really high
<uvos>
the 20% comes from me estimateing how far the callibration may undereport the real capapacity of the battery
<freemangordon>
unless the battery is charged @ 4.35, 1750 is a good estimation
<freemangordon>
mine calibrates @ 1594
<Wizzup>
uvos: btw I think we might have pm regressions, will need some time to confirm properly
<uvos>
im dose 1800 so yours is a bit wierd
<uvos>
but yeah 1700 is resonable estimation
<uvos>
+-20% especcaly
<uvos>
tollerance
<freemangordon>
uvos: +1 on the PM regressions
<uvos>
as cpcap dose offer
<buZz>
uvos: oh right! thats simple :P
<freemangordon>
uvos: BTW, charge-mode bug appears every time device is connected to charger after low-battery power down
<freemangordon>
please give me some hints how to debug
<freemangordon>
are there logs or something
<uvos>
not really, i would write a wpa_supplicant conf and connect wifi and start ssh before chargeing_sdl starts
<uvos>
then just ssh in and look around
<uvos>
freemangordon: Wizzup: ok, mine has idled at 100mW all day, so im not really seeing it, but ofc this is power_avg, not external mesurement
<buZz>
uvos: is it hdq1w ?
<uvos>
buZz: yes
<buZz>
alright
<freemangordon>
uvos: what to look for? device charges fine, it is just that battery animation stays at one red line and if you deisconnect the charger device is shut down
<uvos>
ok
<freemangordon>
maybe cpcap-battery is probed *after* chargeing_sdl is started?
<uvos>
freemangordon: should not be possible, probing happens afaik shound happen within sysinit
<uvos>
and charging_sdl runs after sysinit
<uvos>
but maybe this is me miss interpreting how openrc should behave
<uvos>
also idk why it should probe later when the battery is low
<uvos>
i gues when poking around:
<uvos>
check if the cpcap sysfs files are resonable
<freemangordon>
I don;t think EPROBE_DEFER has anything to do with runlevels
<uvos>
right defer true
<uvos>
but i think sysinit waits until udev sais its ready
<uvos>
dunno how defer interacts with udev really
<buZz>
hmmz, i added 'blacklist hdq1w' to blacklist-idle.conf , still reading 1740mAh from eeprom it seems
<uvos>
really charging_sld is really simple code wise so i dont quite see how it could missbehave, other than wat you said or cpacp driver misbehaveing.
<uvos>
its callded omap_hdq1w or something like that
<uvos>
iirc
<buZz>
oh
<freemangordon>
buZz: lsmod is your friend
<buZz>
omap_hdq , right
<buZz>
:)
<uvos>
freemangordon: btw
<uvos>
you can runn charging_sdl after boot too
<uvos>
just to check if it behaves ok then too
<uvos>
it has flags to be run in a window in x11
<freemangordon>
I think it needs some logs added here and there
<uvos>
it logs some stuff
<uvos>
but only to stdout
<freemangordon>
where?
<uvos>
so you could save that somehwere
<uvos>
its not captured in the initscript afaik
<uvos>
you could do that
<uvos>
but it dosent log mutch more than the battery percent
<freemangordon>
it logs to stdout?
<uvos>
which its also showing you
<uvos>
yeah
<uvos>
so it prints to stdout
<buZz>
could put a >> charging_sdl.log on it
<uvos>
you could redirect that somewhere
<freemangordon>
well, I can put some printfs here and tehre
<uvos>
sure
<freemangordon>
ok
<freemangordon>
will do
<uvos>
for one thing
<freemangordon>
oh, I was about to try to implement SOC estimation based on the voltage
<uvos>
whenever charging_sdl runs
<uvos>
pvrk compains about something
<uvos>
might be related to the eventual hang
<freemangordon>
hmmm
<buZz>
ah yez
<freemangordon>
ok, will check
<freemangordon>
where did you get that code from?
<uvos>
charging_sdl?
<freemangordon>
mhm
<uvos>
its from pmos
<uvos>
but i also added quite some stuff
<uvos>
not sure what part of it your asking about
<freemangordon>
I asked in general
<buZz>
ah, meh, blacklisting omap_hdq prevents charging to 4.35v
<freemangordon>
makes sense, no?
<buZz>
welp, beats my purpose anyway :P
<uvos>
sure but i gues he dosent want that
<buZz>
yes i do, obviously :D
<freemangordon>
we *will not* allow you to charge non-HV lipo to 4.35
<buZz>
right, thats fine
<buZz>
i just want to charge this HV lipo to 4.35 :P
<freemangordon>
I dodn;t get why did you remove 1wire protocol driver
<freemangordon>
*didn't
<freemangordon>
what is the issue?
<uvos>
he has a eb41 pcb/eeprom
<uvos>
on a larger battery
<uvos>
cpcap will discard the callibration
<uvos>
if its to larg
<buZz>
ah, well, cpcap_battery prevents to calibrate the battery to >120% of charge_full_design
<uvos>
ie mutch larger than max_design
<freemangordon>
ah
<buZz>
yeah well, its 28% more
<freemangordon>
well, I guess that shall be fixed in the driver
<uvos>
or you could
<uvos>
you know, change the eeprom
<buZz>
its writeable?
<freemangordon>
isn't it OTP?
<uvos>
idk
<freemangordon>
wait, there are checksums as well
<buZz>
the suggestion was adding a battery definition to override
<uvos>
freemangordon: true but we dont care
<uvos>
so for android yeah
<freemangordon>
yes, we care as android will refuse to charge
<uvos>
sure but buzz might not care about android
<uvos>
this is about a now solution
<freemangordon>
well, yeah
<uvos>
so check if the eeprom is writeable
<freemangordon>
buZz: right, you may try to write
<buZz>
hehe well, its 2088mAh now
<uvos>
and just change the value of so
xmn has joined #maemo-leste
<freemangordon>
buZz: see driver code for the offset and the value you have to write
<freemangordon>
uvos: btw, what is the rationale behind that 120% restriction?
<uvos>
the callibration sometimes goes totaly bonkers here
<uvos>
if you charge and discarge and charge again
<uvos>
the errors of the charge counter accumulate
<uvos>
its to prevent absurd values form being accepted
<freemangordon>
yeah, voltage based SOC it is
<uvos>
motorola came to same conclusion i gues
<freemangordon>
not only, BME does the same
<freemangordon>
so, I will ask upstream upower if they are willing to accept something like that
noidea_ has quit [Quit: Leaving]
noidea_ has joined #maemo-leste
noidea_ has quit [Quit: Leaving]
noidea_ has joined #maemo-leste
noidea_ has quit [Client Quit]
noidea_ has joined #maemo-leste
norayr has left #maemo-leste [Disconnected: Replaced by new connection]
norayr has joined #maemo-leste
<sicelo>
buZz: btw did you upstream the droid4 keymap?
Daanct12 has quit [Read error: Connection reset by peer]
Danct12 has joined #maemo-leste
Danct12 has quit [Ping timeout: 260 seconds]
Danct12 has joined #maemo-leste
sunshavi_ has quit [Remote host closed the connection]
sunshavi_ has joined #maemo-leste
<tmlind>
buZz: if you really want to charge it to 4.35 volt, first change the battery max voltage in sysfs to 4.35, then set the max charger voltage to 4.35
<bencoh>
do we default to 4.2V now?
<freemangordon>
tmlind: by looking at the code, that should happen automagically if you set the voltage in the charger driver. is that a bug that it does not happen?
Danct12 has quit [Ping timeout: 260 seconds]
<tmlind>
freemangordon: it's that way because of the bloated batteries we had folks report earlier
<freemangordon>
tmlind: maybe I didn;t explain it correctly:
<freemangordon>
IIUC, in charger driver there is a code that set battery driver limit as well
<freemangordon>
so, when you set charger limit to 4.35, it sets battery driver limit to 4.35 as well
<freemangordon>
for some reason this does not work
<freemangordon>
or, I don;t understand how it is supposed to work
<tmlind>
first echo the new desired max value to the battery/constant_charge_voltage
<tmlind>
then allow the charger to use it by echo to usb/constant_charge_voltage
<freemangordon>
yes, but that's not what I am talking about
<freemangordon>
anyway
<tmlind>
well we don't want to allow the charger to set the charge voltage higher unless the allowed battery voltage is configured first
<freemangordon>
ok, but shouldn;t allowed voltage be tied to design voltage?
<freemangordon>
or at least set to design voltage on probe?
<tmlind>
no.. at least i have zero interest ruining my batteries after few monts of connected to a dock or lapdock
<freemangordon>
it will still default to 4.2
<freemangordon>
because of the charger default
<tmlind>
yeah that's good
<freemangordon>
but having to change 2 things in a special sequence just to charge a battery to a voltage it is designed for lokks like an overkill to me
<freemangordon>
*looks
<tmlind>
no it's not in this case :)
<freemangordon>
also, I would say that holding a mobile phone on a dock for months is not what usually happens to mobiles ;)
<freemangordon>
so this is an edge use-case that shall be taken care of in the charger diver, perhaps, but not a reason to not charge to full capacity
<freemangordon>
but lets not go into that now
<tmlind>
well we don't know how long it takes, few weeks or few months it seems. anything higher than 4.2v you really need to do a statiscically meaningful test for let's say a year to prove that the batteries don't bloat.. so pretty much impossible :)
<freemangordon>
I am much more concerned that neither sre nor greg reply :(
<tmlind>
i'm mostly concerned about people ruining their batteries
<freemangordon>
tmlind: when (and if) it comes to it I will send a patch that fixes that (like I already proposed, it will be really easy to wait for voltage dropping < 4.2 before starting charging again)
<freemangordon>
it will take couple of weeks for that to happen if device is connected to a charger all the time
<freemangordon>
actually, as uvos said, we *must* do the same for 4.2 batteries
<tmlind>
yeah 4.2v batteries probably should have some lower maintenance charge voltage
<freemangordon>
which we don't, basically ruining batteries of those users that did not replace their aged original ones with ordinary LiPo batteries
<freemangordon>
if they keep them connected to a charger that is
<freemangordon>
so, I will make/send a patch for cpcap-charger
<tmlind>
hmm yeah bionic has 4.2v battery, but not sure if that too has had bloating issue
<freemangordon>
why it shouldn't?
<tmlind>
but please not we are not going to enable 4.35v charge by default without proper proof of it not bloating people's batteries
<freemangordon>
we start charging almost immediatelly after full is hit
<freemangordon>
tmlind: as I said, I'll make a patch when and if it comes to it and will try to convinc you and whoever has doubts that it will be ok
<freemangordon>
but, before that I want to understand what the hell is going on and why a simple 2-liner takes 3 weeks to get a "send v2"
<freemangordon>
or, why sre replies to other mails but not mine
norayr has left #maemo-leste [Disconnected: closed]
<tmlind>
and it might be that it will now just take a lot longer to ruin the battery
<freemangordon>
well, if lot longer is 10 years, I would say we are ok
<freemangordon>
no?
<buZz>
atm it seems the BMS came loose from the cell, having a hard time getting it connected back
<buZz>
might just leave it as-is and fix it later
<tmlind>
freemangordon: 30 devices connected to a charger for a year and i'll be happy :)
<freemangordon>
tmlind: I think I can can easily prove we are fine once I have measured the time needed for a battery to self-discharge to (made-up value) 96% of its design max voltage
norayr has joined #maemo-leste
<freemangordon>
tmlind: not really needed
<tmlind>
in any case the logic can be there for sure, let's just not enable it unless the user really wants to do it
akossh has joined #maemo-leste
<tmlind>
note that motorola was in business of selling accessories and batteries, they do not need them to last very long
<freemangordon>
so, if it takes 2 weeks, you will have 24 charge cycles 4.176->4.35 fo year
<freemangordon>
yet those 10yo batteries keep like 900mAh capacity
<freemangordon>
so I would say they did it right for the usual mobile-phone use case
<tmlind>
hmm yeah that's a good point, if the discharge to a maintenance voltage takes so long that charge cycles are very limited
<freemangordon>
I don;t see why not, given that DCP charger detection works :)
<tmlind>
the first bloated case i heard of was android baby monitor use case
<freemangordon>
so device can be fully supplied by the charger only and battery only self-discharges
<tmlind>
anyways, stuff to discuss on the mailing lists
<freemangordon>
also, a dock can be easily detected and different ruls applied there
<freemangordon>
sure
<freemangordon>
the point was that we don;t really need 30 devices and a year to prove :p
<tmlind>
well we should treat all the chargers the same
<freemangordon>
how's that?
<freemangordon>
USB(SDP) - max 500mA
<freemangordon>
DCP - 1800
<tmlind>
well take the baby monitor example, and no dock. or a trail cam use case (once the camera works)
<freemangordon>
ACA - we have to measure the ID pin to detect what max charging current we can draw
norayr has left #maemo-leste [Disconnected: Replaced by new connection]
<freemangordon>
tmlind: baby monitor connected to a charger (1500mA min) is perfectly fine
norayr has joined #maemo-leste
<freemangordon>
because battery will only do self-discharge
<freemangordon>
as the highest current reading I was able to measure here was about 1600 mA
<tmlind>
well that's a theory :) i want to see some real tested-by for a long time for sure in this case
<freemangordon>
hehe :)
<freemangordon>
but yeah, you are right, this is to be discussed over the ML
<freemangordon>
if there is anyone but you to discuss with there
<freemangordon>
I am really worried about the silence
<tmlind>
nah, just people busy with dealing with all the patches
<freemangordon>
will see
<tmlind>
pavel had some strong opinions too about the min and max voltages to preserve batteries
<freemangordon>
I would love to hear his opinions
<freemangordon>
but really, we need charger detection first working
<freemangordon>
before that
<tmlind>
yeah maybe search lore.kernel.org, i think he had some links to too there
<freemangordon>
with your maintainer hat on, what am I supposed to do there?
<freemangordon>
fixx the drivers and framework and send a new patch?
<tmlind>
yeah i don't know, it's like all the folks dealing with mobile charging disappeared 10 years ago
<tmlind>
it's like nothing has happened to make things better?
<tmlind>
kind of like the same story as with modem support stuff..
<freemangordon>
see, it is not that I expect anything but what upstream will accept. once I know what it is, I will send a patch.
<tmlind>
yeah sorry no idea how it should be done for the charger detection..
<tmlind>
android probably does this all in userspace?
juustohiiri[m] has joined #maemo-leste
<freemangordon>
yes
<freemangordon>
afaik
<freemangordon>
with the exception that it has extcon driver to detect charger types
<freemangordon>
in android it seems to be called "swith" or something
<freemangordon>
*switch
<freemangordon>
it reports what is connected to the userspace and userspace set max current in the charger driver
<freemangordon>
IIUC
xmn has quit [Ping timeout: 248 seconds]
uvos has quit [Ping timeout: 268 seconds]
<tmlind>
ok
Danct12 has joined #maemo-leste
Daanct12 has joined #maemo-leste
Danct12 has quit [Ping timeout: 268 seconds]
<vectis>
Hi all. I'm trying to get my D4 to connect to various audio devices that I have with bluetooth, but I can never get connected. I can pair with the devices but when trying to connect, bluetooth manager complains about a protocol not being available.
Juest has joined #maemo-leste
<Wizzup>
hi
<Juest>
hi, been a few years :)
<Wizzup>
vectis: so...
<Wizzup>
vectis: there's a few things
<Wizzup>
vectis: first, you need to set it to phone class, and then secondly, you need to load the module
<Wizzup>
I have some notes, I'll publish them this week
<uvos>
ok there are some extra patches in there we dont have, and we have extra patches not in there
<uvos>
we dont have an equiavlent to 0005-kernel-dma-workaround-n900-modem-oops.patch
<uvos>
but you told me that allready and this should not cause it to not boot
<uvos>
same with 0006-bus-ti-sysc-Add-otg-quirk-flags-for-omap3-musb.patch
<uvos>
and 0009-Revert-partially-Revert-usb-musb-Set-the-DT-node-on.patch
<uvos>
we also dont have 0003-ARM-dts-N900-use-iio-driver-for-accelerometer.patch
<uvos>
but thats def irrelivant
<uvos>
but we have lots of extras too
Juest has joined #maemo-leste
Juest has quit [Changing host]
<uvos>
enable modem and increase cma size, make watchdog built in, tsc2005: disable irqs on suspend, n900: camera: magic bit makes it work, et8ek8: Support for EXPOSURE_ABSOLUTE
<uvos>
so i gues ill sync it up
<uvos>
tomorrow
<uvos>
ttyl
akossh has quit [Quit: Leaving.]
uvos has quit [Ping timeout: 265 seconds]
Twig has quit [Remote host closed the connection]
doc has quit [Quit: Things to do]
doc has joined #maemo-leste
Danct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 265 seconds]
xmn has joined #maemo-leste
norayr has left #maemo-leste [Disconnected: Received SIGTERM]