Bme replacement - Revision history

imported_>pali: /* Current state */ Update links to DEB files

2014-10-25T18:29:50Z

Current state: Update links to DEB files

← Older revision		Revision as of 18:29, 25 October 2014
Line 14:		Line 14:

	.debs are available from:		.debs are available from:
	http://~~atrey~~.~~karlin~~.~~mff~~.~~cuni~~.cz/~~~pali~~/~~rx51-~~bme-replacement/		http://talk.maemo.org/showthread.php?t=93183
			http://maemo.merlin1991.at/cssu/bme-replacement/

	It works for everyday usage, but some major problems were found, see below.		It works for everyday usage, but some major problems were found, see below.

imported_>marmistrz at 16:14, 25 October 2014

2014-10-25T16:14:26Z

← Older revision		Revision as of 16:14, 25 October 2014
Line 20:		Line 20:
	'''Notice'''		'''Notice'''

	According to Estel, these bugs aren't present anymore. Compare [http://talk.maemo.org/showpost.php?p=1439376&postcount=1691 1] [http://talk.maemo.org/showpost.php?p=1439709&postcount=1693 2]		According to Estel, these bugs aren't present anymore. Compare [http://talk.maemo.org/showpost.php?p=1439376&postcount=1691 1] [http://talk.maemo.org/showpost.php?p=1439709&postcount=1693 2] --[[User:marmistrz\|marmistrz]] 16:13, 25 October 2014 (UTC)

	--[[User:marmistrz\|marmistrz]] 16:13, 25 October 2014 (UTC)

	=Problems/bugs and proposed solutions=		=Problems/bugs and proposed solutions=

imported_>marmistrz: /* Current state */

2014-10-25T16:13:48Z

Current state

← Older revision		Revision as of 16:13, 25 October 2014
Line 20:		Line 20:
	'''Notice'''		'''Notice'''

	According to Estel, these bugs aren't present anymore. Compare [http://talk.maemo.org/showpost.php?p=1439376&postcount=1691 1] [http://talk.maemo.org/showpost.php?p=1439709&postcount=1693 2]		According to Estel, these bugs aren't present anymore. Compare [http://talk.maemo.org/showpost.php?p=1439376&postcount=1691 1] [http://talk.maemo.org/showpost.php?p=1439709&postcount=1693 2]

			--[[User:marmistrz\|marmistrz]] 16:13, 25 October 2014 (UTC)

	=Problems/bugs and proposed solutions=		=Problems/bugs and proposed solutions=

imported_>marmistrz: bugs info

2014-10-25T16:11:51Z

bugs info

← Older revision		Revision as of 16:11, 25 October 2014
Line 17:		Line 17:

	It works for everyday usage, but some major problems were found, see below.		It works for everyday usage, but some major problems were found, see below.

			'''Notice'''

			According to Estel, these bugs aren't present anymore. Compare [http://talk.maemo.org/showpost.php?p=1439376&postcount=1691 1] [http://talk.maemo.org/showpost.php?p=1439709&postcount=1693 2]

	=Problems/bugs and proposed solutions=		=Problems/bugs and proposed solutions=

85.23.163.193: /* Current state */

2013-06-26T23:28:20Z

Current state

← Older revision		Revision as of 23:28, 26 June 2013
Line 14:		Line 14:

	.debs are available from:		.debs are available from:
	~~https~~://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement/		http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement/
	~~(might need to ignore expired certificate)~~

	It works for everyday usage, but some major problems were found, see below.		It works for everyday usage, but some major problems were found, see below.

imported_>joerg_rw: /* 1. Premature shutdown */ typo

2013-06-11T02:45:11Z

1. Premature shutdown: typo

← Older revision		Revision as of 02:45, 11 June 2013
Line 32:		Line 32:
	This method can be also augmented by solution 2, for "default" shutdown threshold.		This method can be also augmented by solution 2, for "default" shutdown threshold.

	'''1.a gconf value plus guard time''' use a timer plus frequent probing to ensure the voltage stays below the threshold set by gconf. This is the recommended method since the whole shutdown shouldn't get triggered by sub-second "brownouts" caused by power consumption spikes. A suggested guard time is 30..60s, a suggested sampling frequency for voltage is 1/s, though the hardware has limited support for such high sampling frequencies of voltage - further evaluation needed. Other alternative concepts like average over moving window (again ~~widow~~ size: ~~300~~..60s) might be worth to consider.		'''1.a gconf value plus guard time''' use a timer plus frequent probing to ensure the voltage stays below the threshold set by gconf. This is the recommended method since the whole shutdown shouldn't get triggered by sub-second "brownouts" caused by power consumption spikes. A suggested guard time is 30..60s, a suggested sampling frequency for voltage is 1/s, though the hardware has limited support for such high sampling frequencies of voltage - further evaluation needed. Other alternative concepts like average over moving window (again window size: 30..60s) might be worth to consider.

	Note that the high sampling frequency is only needed during the guard time. For moving window average this complicates the design a fair bit.		Note that the high sampling frequency is only needed during the guard time. For moving window average this complicates the design a fair bit.

imported_>joerg_rw: /* 1. Premature shutdown */ typos

2013-06-11T02:30:32Z

1. Premature shutdown: typos

← Older revision		Revision as of 02:30, 11 June 2013
Line 28:		Line 28:
	'''1. gconf value''', that allow power users to change voltage, at which device shutdowns to any arbitrary value.		'''1. gconf value''', that allow power users to change voltage, at which device shutdowns to any arbitrary value.

	This is ~~preffered~~ solution, as some devices are more like to have problems with GSM chip restarting at low voltage, even around '''EDV1''' 3248 mV. People with such problems, that ~~preffer~~ GSM stability over calibration, could bump voltage ~~treeshold~~, to avoid problems. OTOH, people with less picky devices and/or dual-cell setups, could decrease limit, getting more from their batteries.		This is preferred solution, as some devices are more like to have problems with GSM chip restarting at low voltage, even around '''EDV1''' 3248 mV. People with such problems, that prefer GSM stability over calibration, could bump voltage threshold, to avoid problems. OTOH, people with less picky devices and/or dual-cell setups, could decrease limit, getting more from their batteries.

	This method can be also augmented by solution 2, for "default" shutdown ~~treeshold~~.		This method can be also augmented by solution 2, for "default" shutdown threshold.

	'''1.a gconf value plus guard time''' use a timer plus frequent probing to ensure the voltage stays below the threshold set by gconf. This is the recommended method since the whole shutdown shouldn't get triggered by sub-second "brownouts" caused by power consumption spikes. A suggested guard time is 30..60s, a suggested sampling frequency for voltage is 1/s, though the hardware has limited support for such high sampling frequencies of voltage - further evaluation needed. Other alternative concepts like average over moving window (again widow size: 300..60s) might be worth to consider.		'''1.a gconf value plus guard time''' use a timer plus frequent probing to ensure the voltage stays below the threshold set by gconf. This is the recommended method since the whole shutdown shouldn't get triggered by sub-second "brownouts" caused by power consumption spikes. A suggested guard time is 30..60s, a suggested sampling frequency for voltage is 1/s, though the hardware has limited support for such high sampling frequencies of voltage - further evaluation needed. Other alternative concepts like average over moving window (again widow size: 300..60s) might be worth to consider.
Line 42:		Line 42:
	'''EDV1''' flag can be read from ''/sys/class/power_supply/bq24150a-0/registers'' address 0x55 0x0A, divided by 2.		'''EDV1''' flag can be read from ''/sys/class/power_supply/bq24150a-0/registers'' address 0x55 0x0A, divided by 2.

	'''2.a''' In case of '''EDV1''' flag being not available'''*''', fallback to using 3150 mV as shutdown ~~treeshold~~. Rationale: 3150 mV shouldn't cause GSM chip restarts on devices, where 3248 mV haven't caused it already.		'''2.a''' In case of '''EDV1''' flag being not available'''*''', fallback to using 3150 mV as shutdown threshold. Rationale: 3150 mV shouldn't cause GSM chip restarts on devices, where 3248 mV haven't caused it already.

	It doesn't guarantee calibration, as it require 15 seconds straight below 3248 mV (EDV1 voltage), and 3150 mV might be just momentary low voltage spike. But, it is better than current implementation, which permits calibration ever - and, after all, it is just theoretical fallback for hyphotetical, non-existing kernel.		It doesn't guarantee calibration, as it require 15 seconds straight below 3248 mV (EDV1 voltage), and 3150 mV might be just momentary low voltage spike. But, it is better than current implementation, which permits calibration ever - and, after all, it is just theoretical fallback for hyphotetical, non-existing kernel.

62.10.80.241: fix misinformation

2013-03-28T18:52:33Z

fix misinformation

← Older revision		Revision as of 18:52, 28 March 2013
Line 41:		Line 41:

	'''EDV1''' flag can be read from ''/sys/class/power_supply/bq24150a-0/registers'' address 0x55 0x0A, divided by 2.		'''EDV1''' flag can be read from ''/sys/class/power_supply/bq24150a-0/registers'' address 0x55 0x0A, divided by 2.

	~~NOTE: EDV1 flag might never get set, when discharge (=learning cycle) been "spoiled" by e.g. a short charging period in between.~~

	'''2.a''' In case of '''EDV1''' flag being not available'''*''', fallback to using 3150 mV as shutdown treeshold. Rationale: 3150 mV shouldn't cause GSM chip restarts on devices, where 3248 mV haven't caused it already.		'''2.a''' In case of '''EDV1''' flag being not available'''*''', fallback to using 3150 mV as shutdown treeshold. Rationale: 3150 mV shouldn't cause GSM chip restarts on devices, where 3248 mV haven't caused it already.

imported_>joerg_rw: /* 3. bq27x00_battery sysfs node reports -ENODATA when not calibrated */

2013-03-27T21:11:36Z

3. bq27x00_battery sysfs node reports -ENODATA when not calibrated

← Older revision		Revision as of 21:11, 27 March 2013
Line 94:		Line 94:
	* Proposal from Kerio on this: hald-addon-bme should provide a way to know if bq27k is calibrated or not, and the battery applet should show a "(CI)" whenever it's not; battery.reporting.design should always come from rx51-battery, other data should always come from bq27k (with the implicit message that if it's uncalibrated, it might be inaccurate); the battery applet should have three modes: a mode where it does the same thing as stock, without showing anything at all (default for CSSU stable maybe?), a mode (default on CSSU testing, maybe?) where it prefers to calculate against the battery design reported by rx51-battery, and a mode where it calculates against the last full charge as reported by bq27k, regardless of calibration (but showing the CI indicator next to the charge/full charge report)		* Proposal from Kerio on this: hald-addon-bme should provide a way to know if bq27k is calibrated or not, and the battery applet should show a "(CI)" whenever it's not; battery.reporting.design should always come from rx51-battery, other data should always come from bq27k (with the implicit message that if it's uncalibrated, it might be inaccurate); the battery applet should have three modes: a mode where it does the same thing as stock, without showing anything at all (default for CSSU stable maybe?), a mode (default on CSSU testing, maybe?) where it prefers to calculate against the battery design reported by rx51-battery, and a mode where it calculates against the last full charge as reported by bq27k, regardless of calibration (but showing the CI indicator next to the charge/full charge report)
	** Pali: I do not agree, there should be only one version of bme replacement, not N versions with different preconfigured modes.		** Pali: I do not agree, there should be only one version of bme replacement, not N versions with different preconfigured modes.

			there's no sane rationale in using battery.reporting.design for anything. User isn't interested in charge relative to what battery been able to store when it been new. This would result in battery never reaching 100%, which for sure is odd! Rather user is interested when battery has reached 100% of capacity it can store '''right now''' - and that's LMD, not battery.reporting.design --[[User:joerg_rw\|joerg_rw]] 21:11, 27 March 2013 (UTC)

imported_>joerg_rw: /* 3. bq27x00_battery sysfs node reports -ENODATA when not calibrated */

2013-03-27T21:06:20Z

3. bq27x00_battery sysfs node reports -ENODATA when not calibrated

← Older revision		Revision as of 21:06, 27 March 2013
Line 87:		Line 87:
	* Pali: I do not want to touch kernel drivers in maemo 2.6.28 kernel - this is very old version. Also "registers" sysfs entry is deprecated and is not upstreamed. In upstream kernel there is "regmap" api for exporting all needed registers to userspace, but there is no patch yet... See https://lkml.org/lkml/2013/1/19/162 Problem that userspace application cannot read battery i2c registers directly can be fixed with flag I2C_SLAVE_FORCE see: https://lkml.org/lkml/2013/3/26/580		* Pali: I do not want to touch kernel drivers in maemo 2.6.28 kernel - this is very old version. Also "registers" sysfs entry is deprecated and is not upstreamed. In upstream kernel there is "regmap" api for exporting all needed registers to userspace, but there is no patch yet... See https://lkml.org/lkml/2013/1/19/162 Problem that userspace application cannot read battery i2c registers directly can be fixed with flag I2C_SLAVE_FORCE see: https://lkml.org/lkml/2013/3/26/580
	** Pali: it should be safe to use i2cget for (and only for) bq27200 device when bq27x00_battery kernel driver is loaded, because i2c transfers are atomic. See: https://mg.pov.lt/maemo-irclog/%23maemo.2013-03-27.log.html#t2013-03-27T14:03:02		** Pali: it should be safe to use i2cget for (and only for) bq27200 device when bq27x00_battery kernel driver is loaded, because i2c transfers are atomic. See: https://mg.pov.lt/maemo-irclog/%23maemo.2013-03-27.log.html#t2013-03-27T14:03:02

			A: we don't need to read registers of bq27200, what we need are proper decoded data from bq27200 available in sysfs nodes like /CI etc. This is perfectly allowable even for power-supply according to readme excerpts shadowjk digged up. Usage of I2C_SLAVE_FORCE is strongly deprecated, since there is no justification why direct register read/write should be allowed when bq27200 has a proper comprehensive feature-complete driver. --[[User:joerg_rw\|joerg_rw]] 21:06, 27 March 2013 (UTC)

	* Pali: question what should power supply function return to power supply interface when data are/could be incorrect is for power supply kernel maintainer. TODO: add link for mailinglist (lkml) discussion about it.		* Pali: question what should power supply function return to power supply interface when data are/could be incorrect is for power supply kernel maintainer. TODO: add link for mailinglist (lkml) discussion about it.