[Announce] kernel-power stable v49 in Extras-Testing - Page 74 - maemo.org

Active Topics

The N900 is now 15 years old! (9)
to Nokia N900 by Arno_11 - 3 hrs, 2 mins ago
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 5 days, 15 hrs ago
more...

Page 74 of 300

Thread Tools

	Temporal	2011-06-18 , 23:29
	Posts: 323 \| Thanked: 189 times \| Joined on Oct 2010 @ Brazil	#731

Can someone that is using Shortcutd tell me if the proximity sensor is working under v47? I'm not that excited in upgrading, but I might if someone can confirm about the sensor.

Thanks.

__________________
Love and Goodness are not a property. Are not a franchising. They are present in each one of us, and must be cultivated with KNOWLEDGE.

Quote & Reply |

Hurrian	2011-06-19 , 22:00
Posts: 1,225 \| Thanked: 1,905 times \| Joined on Feb 2011 @ Quezon City, Philippines	#732

Originally Posted by Temporal

Can someone that is using Shortcutd tell me if the proximity sensor is working under v47? I'm not that excited in upgrading, but I might if someone can confirm about the sensor.

Thanks.

Confirmed working, and it feels like I'm a Jedi Master for using it.

__________________
N9 PR 1.3 Open Mode + kernel-plus for Harmattan
@kenweknot, working on Glacier for Nemo.

Quote & Reply |

	Estel	2011-06-19 , 23:40
	Posts: 5,028 \| Thanked: 8,613 times \| Joined on Mar 2011	#733

Originally Posted by pali

If you have bq27x00_battery blacklisted, you can't get current_now from bq module (it is blacklisted).

And if you are talking about bq module, in v46 was all values in bad units (22/3570 uAh or 22/3570 uA). Now in v47 is all in correct normalized units (1 uAh or 1 uA) So recalculate current_now from this units to uAh/uA.

Hey, i was sure that something is wrong here!

I'm 100% certain that i blacklisted module properly (checked many tiomes that

blacklist bq27x00_battery

i present in "/etc/modprobe.d/blacklist" without any typos, rebooted many times since adding it there), ho ever i still can get data from bq module (cat sys/class/power_supply/bq27200-0/current_now for example). If I'm wrong correct me, but i understand that it shouldn't be unavailable with module blacklisted?

---

Anyway, I un-blacklisted module - not having any issues so far.

Ho ever, bq report some data obviously wrong way... As i understand it - again, correct me if I'm wrong please - charge_full and charge_now is calculated using real current usage/charging in given time (current at the given moment can be checked by current_now), as opposed to charge_design, which is based on resistor in battery PCB and wrong most of the time.

Still, for just simple example, charge_now report for me 1300753 uAh (1301 mAh) and charge_full gives 1416040 uAh (1416 mAh) for battery that i know of being exactly 1100 mAh. I double checked battery both with RC charging equipment dedicated to all variants of Li-Ion batteries + discharging via resistor with time monitoring (i wanted to be 100% sure that my RC charger report correct value).

So, if my statements about how charge_now and charge_full should work are correct, they're obviously working wrong.

Quote & Reply |

jpala16	2011-06-20 , 08:01
Posts: 169 \| Thanked: 71 times \| Joined on Aug 2010 @ Spain	#734

Regarding those incorrect outputs in KPv46, is there a way to correct that? Without upgrading kernel-power, of course. Yesterday I had to do a full reflash and I installed KPv46 (I had KPv47 before reflashing). I prefer to stay with v46, as I had some trouble with bluetooth, my car radio and http://wiki.maemo.org/Bluetooth_PBAP, with KPv47

Now, conky-n900 report -1.0ºC, and before (with KPv47) it reported the actual temperature. It isn't that important to me the temperature thing, but just in case. Thanks in advance.

Quote & Reply |

pali	2011-06-20 , 08:21
Posts: 2,154 \| Thanked: 8,464 times \| Joined on May 2010	#735

Originally Posted by Estel

Hey, i was sure that something is wrong here!

I'm 100% certain that i blacklisted module properly (checked many tiomes that

blacklist bq27x00_battery

i present in "/etc/modprobe.d/blacklist" without any typos, rebooted many times since adding it there), ho ever i still can get data from bq module (cat sys/class/power_supply/bq27200-0/current_now for example). If I'm wrong correct me, but i understand that it shouldn't be unavailable with module blacklisted?

---

Anyway, I un-blacklisted module - not having any issues so far.

Ho ever, bq report some data obviously wrong way... As i understand it - again, correct me if I'm wrong please - charge_full and charge_now is calculated using real current usage/charging in given time (current at the given moment can be checked by current_now), as opposed to charge_design, which is based on resistor in battery PCB and wrong most of the time.

Still, for just simple example, charge_now report for me 1300753 uAh (1301 mAh) and charge_full gives 1416040 uAh (1416 mAh) for battery that i know of being exactly 1100 mAh. I double checked battery both with RC charging equipment dedicated to all variants of Li-Ion batteries + discharging via resistor with time monitoring (i wanted to be 100% sure that my RC charger report correct value).

So, if my statements about how charge_now and charge_full should work are correct, they're obviously working wrong.

I think that values reported by bq in v47 are correct. This values are reported by chip (not calculated and doing magick as BME). Note that DESIGN values is configured at factory and can be changed on chip (using i2cset). If I remeber FULL values are calculated from DESIGN after rechange.

You can read datasheet for this battery chip. Here are also explained registers (exported to kernel values) what contains:

http://focus.ti.com/docs/prod/folder...t/bq27000.html

If you think that there is bug in bq module, find maintainser/mailing list of battery submodule in http://git.infradead.org/battery-2.6...D:/MAINTAINERS and report bug. bq27x00 battery is in upstream (same version as in v47) so if there are bugs it should be fixed in upstream.

Quote & Reply |

The Following 2 Users Say Thank You to pali For This Useful Post:
Estel, phedders

412b	2011-06-20 , 16:52
Posts: 462 \| Thanked: 550 times \| Joined on Sep 2008 @ Moscow	#736

Originally Posted by pali

I think that values reported by bq in v47 are correct. This values are reported by chip (not calculated and doing magick as BME). Note that DESIGN values is configured at factory and can be changed on chip (using i2cset). If I remeber FULL values are calculated from DESIGN after rechange.

Nevertheless bq produces wrong values for me.

capacity

Code:

charge_full

Code:

charge_full_design

Code:

charge_now

Code:

current_now

Code:

And since it uses uA, why values exported to HAL still use mAh? Whom should I file a bug?

__________________
Advanced Power, Advanced Interface Switcher, MediaBox Home Widget

Quote & Reply |

pali	2011-06-20 , 18:26
Posts: 2,154 \| Thanked: 8,464 times \| Joined on May 2010	#737

First, this thread is about kernel and we are talking about bq kernel module and what it reports. So please do not use values from user space applications like HAL (it can do some magic or report some incorrect values...).

I see that some people have problems with units. mAh != uA... and I think that not all people know what which value mean. So here is info from power_supply subsystem kernel documentation:

Code:

Units:

  All voltages, currents, charges, energies, time and temperatures in µV,
  µA, µAh, µWh, seconds and tenths of degree Celsius unless otherwise
  stated. It's driver's job to convert its raw values to units in which
  this class operates.

CHARGE_* attributes represents capacity in µAh only.
CAPACITY attribute represents capacity in *percents*, from 0 to 100.

CHARGE_FULL_DESIGN, CHARGE_EMPTY_DESIGN - design charge values, when
battery considered full/empty.

CHARGE_FULL, CHARGE_EMPTY - These attributes means "last remembered value
of charge when battery became full/empty". It also could mean "value of
charge when battery considered full/empty at given conditions (temperature,
age)". I.e. these attributes represents real thresholds, not design values.

TEMP - temperature of the power supply.

TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e.
while battery powers a load)
TIME_TO_FULL - seconds left for battery to be considered full (i.e.
while battery is charging)

And this is from bq27x00_battery driver:

Code:

CURRENT_NOW - battery average current in µA

===

@412b: What is wrong with your output?

Quote & Reply |

The Following 2 Users Say Thank You to pali For This Useful Post:
Estel, vi_

412b	2011-06-20 , 19:11
Posts: 462 \| Thanked: 550 times \| Joined on Sep 2008 @ Moscow	#738

Originally Posted by pali

@412b: What is wrong with your output?

Originally Posted by pali

First, this thread is about kernel and we are talking about bq kernel module and what it reports. So please do not use values from user space applications like HAL (it can do some magic or report some incorrect values...).

My values are from /sys and are correctly mapped in HAL, in fact (with unit conversion from uAh to mAh and uA to mA).
So... charge_full is measured in µAh. Nice. So I have a 78mAh battery ))) Straaange???

EDIT:
checked values in /sys/class/power_supply one more time...
At the moment I have charge_now=0 (zero) and device is normally working and will at least till morning, isn't that strange?

__________________
Advanced Power, Advanced Interface Switcher, MediaBox Home Widget

Last edited by 412b; 2011-06-20 at 19:15. Reason: Checked values one more time

Quote & Reply |

pali	2011-06-20 , 19:26
Posts: 2,154 \| Thanked: 8,464 times \| Joined on May 2010	#739

See again what is doc.

Code:

CHARGE_FULL, CHARGE_EMPTY - These attributes means "last remembered value of charge when battery became full/empty".

Maybe it is remembered incorrectly. And in bq27000.pdf doc is written that this value is updated on a valid learning cycle. Try to discharge and then fully charge battery again.

what is reporting BME?

Quote & Reply |

colin.stephane	2011-06-20 , 19:35
Posts: 458 \| Thanked: 783 times \| Joined on Jan 2010 @ France	#740

Originally Posted by 412b

My values are from /sys and are correctly mapped in HAL, in fact (with unit conversion from uAh to mAh and uA to mA).
So... charge_full is measured in µAh. Nice. So I have a 78mAh battery ))) Straaange???

EDIT:
checked values in /sys/class/power_supply one more time...
At the moment I have charge_now=0 (zero) and device is normally working and will at least till morning, isn't that strange?

I already tried to explain the behavior of this driver.

If you are interrested, please read from here : http://talk.maemo.org/showthread.php?t=71879&page=54

Read until you reach the message where I say the driver doesn't able to calibrate a new battery inserted in the device.

Same problem for me as you (bad report of current battery charge) with this driver, so, just blacklist it with this command as root :

Code:

clear && ID=$(id -un) ; if [ ${ID} != "root" ] ; then echo "You are not 'root', please use this command line as 'root' ..." ; else echo "Ok, you are 'root' ..." ; if grep -q "blacklist bq27x00_battery" /etc/modprobe.d/blacklist 2>/dev/null ; then echo "Patch already applyed, nothing to be done ..." ; echo "" ; else echo "Applying patch now ..." ; echo "blacklist bq27x00_battery" >>/etc/modprobe.d/blacklist ; echo "" ; echo "DONE, PLEASE REBOOT YOUR DEVICE ..." ; echo "" ; fi ; fi

The bme binary blob hack is here for this reason (at least this is the only reason I can understand ...).

A++