maemish_ has quit [Quit: Connection closed for inactivity]
xmn has quit [Quit: ZZZzzz…]
uvos__ has quit [Ping timeout: 240 seconds]
uvos__ has joined #maemo-leste
xmn has joined #maemo-leste
<sicelo>
Wizzup: n900 bq27200 charge_full is always 2050560 when no calibration has taken place. this value will also be charge_now if battery reaches 100% full. it only starts becoming 'sane' once you have a full, uninterrupted discharge
<sicelo>
tldr; don't mind charge_* until you have calibrated
joerg is now known as Guest730
joerg has joined #maemo-leste
Guest730 has quit [Ping timeout: 255 seconds]
k1r1t0 has joined #maemo-leste
<freemangordon>
tmlind: is it acceptable to have sysfs attribute in cpcap_adc driver that controls single vs multi channels? otherwise I would have to have 8 more channels dedicated to single-channel ADC
<freemangordon>
IOW: when buffer support is implemented, one should enable the channels she would like to read. Having 4x2 single-channel read means 8 additional channels.
<freemangordon>
Unless I a missing something
Twig has joined #maemo-leste
<tmlind>
freemangordon: hmm yeah i don't know, best to ask the iio folks.. maybe IIO_CHAN_INFO_AVERAGE_RAW could be used?
<Wizzup>
it seems to be charging, but the led doesn't show it, neither does status applet
<Wizzup>
it's kind of weird
<Wizzup>
# cat capacity
<Wizzup>
8
<Wizzup>
better than 1, I guess
<freemangordon>
sorry, no idea
<freemangordon>
better ask Pali or joerg
<joerg>
hm?
<Wizzup>
I think I might try to unblacklist a few modules first
<Wizzup>
and see if it's related at all
<freemangordon>
ok
<freemangordon>
joerg: something weird on n900, see backscroll if you have some spare time
<joerg>
please provide a anchor quote
<freemangordon>
" sicelo: ok, but I am not sure if my n900 is charging anymore even with empty battery"
<Wizzup>
it is charging now, I can see it, but it's a bit weird
<freemangordon>
ok
<Wizzup>
I'll have to check upower and our status applet code
<joerg>
the kernel module taking charge about 2translating" bq27200 data into sysnodes, it's... tricky. Pali implemented it for maemo
<Wizzup>
we had this working for sure
<joerg>
taking care about...
<joerg>
yes, it works IFFF
<joerg>
and e.g. my and speedevi's bq27k-detail.sh scriopts iirc only work when you unload the kernel module
<Wizzup>
I'll report back when I've figured this out, it might be a kernel change or just the module blacklist
<joerg>
something about I2C device exclusive open()
<joerg>
there are several mutually exclusive kernel midules which may try to access the bq27k stuff
<joerg>
and twl4030 iirc only involved regarding some A/D or USB-ID-pin or whatever
<joerg>
twl4030 can not emergency-charge
<joerg>
aka bootstrap-charge
<Wizzup>
freemangordon: battery_bq27200_0 has state charging, battery_bq24150a_0 has state charging (but is meaningless), DisplayDevice is state charging
<Wizzup>
both the displaydevice and the bq27200_0 seem ok info wise, so somehow our code decides not to use it
<Wizzup>
both mce and status applet
<Wizzup>
mce for led, status applet for gui
<Wizzup>
I'll check the code in a bit and see if I can find anything there
<freemangordon>
ok
<joerg>
to start with, the bq24150 charger chip needs D+/- short for bootstrap-charging (when the battery voltage is too low to bring up the CPU)
<freemangordon>
joerg: well, it seems kernel-wise it is fine
<joerg>
basically no USB wallwart charger supports this any more nowadays
<freemangordon>
some userspace issues
<joerg>
ok, then I'm probably out :-)
<joerg>
pali should know more details
<freemangordon>
yeah, thanks
<joerg>
yw
arno11 has joined #maemo-leste
<Wizzup>
arno11: do you ever see the orange led when charging/
<Wizzup>
or the battery charging animation
<arno11>
Never seen the orange led since beowulf in 2021-2022
<arno11>
always troubles with battery animation
<arno11>
but charging always works
<arno11>
did you try to charge through fremantle to see any difference ?
<arno11>
i mean with your current battery
Daanct12 has quit [Quit: Quitting]
<Wizzup>
arno11: yeah fremantle is fine I think
<arno11>
maybe we have new issues if the battery is not already calibrated
<Wizzup>
arno11: in any case that is not normal, I think we had this working ok
<Wizzup>
(status applet and led)
<arno11>
indeed
<joerg>
during early boot, NOLO/uBoot takes care about amber breathing indicator LED. Before even NOLO gets loaded to CPU, on batter_very_low the hardware BQ24150 enables the green and red (=amber) indicator LEDs on a mere hardware level
<joerg>
the latter mode is steady amber, not breathing
<Wizzup>
I think the problem here is just mce's upower module not picking up on this
<joerg>
if you don't see it on completely depleted battery durning the first fraction of a second on pluggin in USB, extending to a usually max ~20s until battery voltage got boosted up to a level where CPU can load NOLO and take over management of the indicator LED, then either you got no D+/- short in your USB wallwart charger, or your indicator LED and associated hardware is broken
<Wizzup>
mce: xup_check_device: accepting device as line power twl4030_ac
<Wizzup>
mce: xup_check_device: accepting device as battery bq27200-0
<Wizzup>
hm... I wonder if we simply miss some patch the report sysfs values over udev
<Wizzup>
unplugged cable makes the charging symbol start in battery applet
<Wizzup>
s/symbol/pattern/
<Wizzup>
I guess it would be better to use isp1704 and not twl4030_ac
<Wizzup>
same logic in as mce as battery applet
<Wizzup>
will have a fix soon I hope
<joerg>
>>line power twl4030_ac<< hmmmm
<Wizzup>
the mce code just iterates over upower devices
<Wizzup>
and it picks the first line power device
<Wizzup>
(there are at least three)
<joerg>
afaik in N900 the twl4030 does zilch for power
<Wizzup>
eaxctly, this is the problem
<Wizzup>
it also rarely reports on udevadm monitor
<Wizzup>
yup
<Wizzup>
now it works again, with blacklist mod
<joerg>
:-D
<Wizzup>
the 'problem' we have with leste is that we support more than one device, so we need heuristics to find the right devices on a phone that exposes at least line power devices
<Wizzup>
and also several battery devices
<Wizzup>
it's possible the only thing that changed is the way the devices are loadeds or ordered in upower
<Wizzup>
uvos__: I assume you're not opposed to blacklisting two more n900 line power devices in mce's upower blacklist
<Wizzup>
isp1704, twl4030_ac and twl4030_usb are all 'power_supply: yes' and have a line-power property
<Wizzup>
I see nothing that we can distinguish them on in code
<tmlind>
freemangordon: i guess the idea with the raw values is that the data can be processed later on with little overhead during sampling
<tmlind>
freemangordon: getting the gsm support to mainline needs quite a bit of work, mostly to switch to serdev read and write for the virtual ports
<Wizzup>
freemangordon: (status-area-applet-battery) I rebased maemo/chimaera-devel and master on maemo/beowulf-devel, since there were some unmerged changes there, and I'm making a new release 1.5.5, with the blacklist added
<freemangordon>
tmlind: ok, but do we need in the particular driver?
<freemangordon>
Wizzup: yeah
<tmlind>
freemangordon: sorry care to clarify, not following you
<freemangordon>
cpcap_adc driver exposes both raw and processed values to sysfs. My question is - what is the usecase in exporting raw values from this particular driver and wouldn't it be better to remove BIT(IIO_CHAN_INFO_RAW) from .info_mask_separate?
<freemangordon>
thus exporting processed values only
<freemangordon>
BTW, I got buffer reads working (with made-up data, but still)
<freemangordon>
tmlind: ^^^
<Wizzup>
uvos__: freemangordon: should we treat battery at 100% as full battery? right now n900 says battery-full-charging-symbolic with percentage at 100% but state is 'charging'
<Wizzup>
so the led never turns green
<Wizzup>
we check for UP_DEVICE_STATE_FULLY_CHARGED
<tmlind>
freemangordon: yeah maybe doable, the rate of data is very low volume for cpcap. nice that you got the buffer reads going
<freemangordon>
Wizzup: I don't think so
<freemangordon>
it is up to the driver/upower to set thta, no?
<freemangordon>
tmlind: sure it is doable, just that bit in question removed and we'll halve sysfs entries
<freemangordon>
not a biggie, but still
<Wizzup>
freemangordon: well, the icon state seems to imply it's full: battery-full-charging-symbolic
<Wizzup>
as in, charge_now == charge_full in sysfs