Re: [PATCH 13/14] twl4030_charger: Increase current carefully while watching voltage.
Hi! The USB Battery Charging spec (BC1.2) suggests a dedicated charging port can deliver from 0.5 to 5.0A at between 4.75 and 5.25 volts. To choose the correct current voltage setting requires a trial and error approach: try to draw current and see if the voltage drops too low. Even with a configured Standard Downstream Port, it may not be possible to reliably pull 500mA - depending on cable quality and source quality I have reports of charging failure due to the voltage dropping too low. To address both these concerns, this patch introduce incremental current setting. The current pull from VBUS is increased in steps of 20mA every 100ms until the target is reached or until the measure voltage drops below 4.75V. If the voltage does go too low, the target current is reduced by 20mA and kept there. Still nervous. If it is possible to overheat the charger, without tripping internal fuse, then you'll do it. If it is possible to overheat the charger without tripping an internal fuse, then sure the charger is mis-designed - is it not? Can you suggest an algorithm for determining how much current can safely be pulled from a charger that would *not* make you nervous? Not nervous? No. Less nervous? Run detection as you do, but then round down to known reasonable max charging currents? If you detected 1.1A charger, you are probably overloading 1A charger. So idea would be to round down to 0.5A, 1A, 1.7A. Idle device. Code will find that it can charge using 1A, backs up to 0.9A. User starts hotspot. Now device will draw 1.4A, overloading the charger and not charging at all...? The current being measured and controlled is the current flowing in from the USB VBUS, not flowing out to the battery. So I the code choose 0.9A, that is all that will be drawn. This is a possible issue similar to this though. If the device is idle and the battery is fully charged, then it won't draw much current from USB even if we allow it too. So the algorithm might decide it is OK to draw 1.7A because at that time the device cannot use more than 200mA, and that doesn't cause the voltage to drop. Then later when user enabled wifi-hotspot, the current needed might go up above what the charger can provide. Maybe I should only increase the limit while the actual current is also increasing. Maybe also revisit the setting when the battery starts charging. Yes, that sounds better. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi Pavel, Am 04.04.2015 um 10:16 schrieb Pavel Machek pa...@ucw.cz: Hi! Please propose your own code doing that so that we can test if it is better. So, how does this look? It looks to me like you have cca 0.1 Ohm resistance in your system, This is completely unknown. and are using cca 75mA while discharging, and charge by cca 1.4A. Where do you get these figures from? Least squares fitting of my coefficients to your tables. Ah, I see. A GTA04 board discharges usually between 50 and 400 mA (depending on activities) and if you turn on WiFi, it will be up to 600 mA. If you use 3G it can draw even more during operation. How big battery do you have? 1200 mAh According to least squares fitting, assuming maximum charge of .46A, you were taking about 25mA when doing the discharge test. No, that can’t fit well. But I do not remember who has done this calibration in which situation because it was done many months ago for the platform data version. We have just reformatted the table for the DT. Total current going in is 500-800 mA (depending on USB negotiations) and this is split into system operation and charging current. So 1.4A charging current is not possible. Rather 200-500 mA. So it might be that the battery is discharged although the system is connected to a charger. Yah, and your battery meter will be wrong in such case, as will be mine, because they are based on same information. Well, it is not “mine”, it is the platform_data based driver already in kernel.org since ca. 3.12. We have just updated it to DT to get rid of platform_data in this area as well… Yes, I see your argument that hiding the tables (two characteristic curves) into an analytic approximation can be superior. The problem I see is just that your formula needs some parameters which are difficult to derive or estimate. And must be adjusted to the specific battery and system setup in a non-trivial way. At least we must supply a tool (in the kernel/scripts directory?) where someone can can estimate the parameters of the formula from the characteristic curves. Maybe a tool that automatically runs several charge/discharge cycles at different system load. And measures time vs. voltage. And assumes a linear capacity decrease between the end points. (i.e. if it needs 10 hours to charge from completely empty to full, we can assume 50% after 5,0 hours). So my goal is to measure all characteristics of the battery - and no need to study a (potentially non-existing) data sheet. If you can provide that for all parameters of your algorithm I am fine with it. The thing is, mine can be improved without adding more tables. How can you improve your algorithm without tweaking or adding new parameters? It is tricky to do a good job near 0%... or anywhere else. See for example http://cseweb.ucsd.edu/~trosing/lectures/battery.pdf You start a call, percentage goes down, end a call, it will go back up. I'm pretty sure you will not be able to make a call with 5% indication from your code at low battery temperature (say -10C). The whole system is heating up a little, so that you never have -10C for the battery. Umm. When not calling, your phone should not heat itself up. Yes, in suspend it needs 20 mA which does not heat or course. But steady operation at 20-400 mA does significantly rise OMAP temperature beyond environment temperature. And you definitely can power it down, leave it in outer pocket, then power it up. It is actually something people do when they want to preserve battery... I think you are trying to solve situations that don’t exist in practice. And AFAIK, the GTA04 board is the only user of this driver in case the battery has no built-in fuel gauge. So why improve it beyond what the GTA04 users need? Because then other users can share the same code, and because you But you have ugly parameters in dts that nobody can easily see in the schematics and that are full of assumptions. From a perspective of uncertainty analysis, estimation of the internal parameters needs a higher precision than the calibration points. avoid big ugly tables in dts. Well, the biggest tables I have seen in dts are keyboard matrix codes… I repeat myself: this driver is not built for highest precision because there are better methods (fuel gauge chip). These might not be available so this fall-back driver has been built. It is definitively better than no driver and worse than the optimum. And my email suggested solution better than your driver, so why not just use it? I am not yet convinced that it is better. It just moves the (unavoidable) limitations (measuring multiple calibration points) just to a different area (measuring the hidden and not precisely known parameter of the system). #perc = percent(volt) compute(charging, 1) compute(discharging, 0) Please explain what you calculate here. Especially what “Badness” is?
Re: [PATCHv6] media: i2c/adp1653: Documentation for devicetree support for adp1653
Hi Pavel, On Sat, Apr 04, 2015 at 09:43:37AM +0200, Pavel Machek wrote: Documentation for adp1653 binding. s/binding/bindings/ Signed-off-by: Pavel Machek pa...@ucw.cz --- Please apply. Sorry, wrong version of patch was sent last time. Pavel diff --git a/Documentation/devicetree/bindings/media/i2c/adp1653.txt b/Documentation/devicetree/bindings/media/i2c/adp1653.txt new file mode 100644 index 000..4607ce3 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt @@ -0,0 +1,37 @@ +* Analog Devices ADP1653 flash LED driver + +Required Properties: + + - compatible: Must contain be adi,adp1653 s/be // + + - reg: I2C slave address + + - enable-gpios: Reference to the GPIO that controls the power for the chip. How about: enable-gpios: Specifier of the GPIO connected to EN pin I can make the changes if you're ok with that, otherwise please send v7. Then I'll apply that to my tree. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6] media: i2c/adp1653: Documentation for devicetree support for adp1653
Documentation for adp1653 binding.
Signed-off-by: Pavel Machek pa...@ucw.cz
---
Please apply.
Sorry, wrong version of patch was sent last time.
Pavel
diff --git a/Documentation/devicetree/bindings/media/i2c/adp1653.txt
b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
new file mode 100644
index 000..4607ce3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
@@ -0,0 +1,37 @@
+* Analog Devices ADP1653 flash LED driver
+
+Required Properties:
+
+ - compatible: Must contain be adi,adp1653
+
+ - reg: I2C slave address
+
+ - enable-gpios: Reference to the GPIO that controls the power for the chip.
+
+There are two LED outputs available - flash and indicator. One LED is
+represented by one child node, nodes need to be named flash and indicator.
+
+Required properties of the LED child node:
+- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+
+Required properties of the flash LED child node:
+
+- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+- flash-timeout-us : see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+
+ adp1653: led-controller@30 {
+ compatible = adi,adp1653;
+ reg = 0x30;
+ enable-gpios = gpio3 24 GPIO_ACTIVE_HIGH; /* 88 */
+
+ flash {
+ flash-timeout-us = 50;
+ flash-max-microamp = 32;
+ max-microamp = 5;
+ };
+ indicator {
+ max-microamp = 17500;
+ };
+ };
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi! Please propose your own code doing that so that we can test if it is better. So, how does this look? It looks to me like you have cca 0.1 Ohm resistance in your system, This is completely unknown. and are using cca 75mA while discharging, and charge by cca 1.4A. Where do you get these figures from? Least squares fitting of my coefficients to your tables. A GTA04 board discharges usually between 50 and 400 mA (depending on activities) and if you turn on WiFi, it will be up to 600 mA. If you use 3G it can draw even more during operation. How big battery do you have? According to least squares fitting, assuming maximum charge of .46A, you were taking about 25mA when doing the discharge test. Total current going in is 500-800 mA (depending on USB negotiations) and this is split into system operation and charging current. So 1.4A charging current is not possible. Rather 200-500 mA. So it might be that the battery is discharged although the system is connected to a charger. Yah, and your battery meter will be wrong in such case, as will be mine, because they are based on same information. The thing is, mine can be improved without adding more tables. It is tricky to do a good job near 0%... or anywhere else. See for example http://cseweb.ucsd.edu/~trosing/lectures/battery.pdf You start a call, percentage goes down, end a call, it will go back up. I'm pretty sure you will not be able to make a call with 5% indication from your code at low battery temperature (say -10C). The whole system is heating up a little, so that you never have -10C for the battery. Umm. When not calling, your phone should not heat itself up. And you definitely can power it down, leave it in outer pocket, then power it up. It is actually something people do when they want to preserve battery... I think you are trying to solve situations that don’t exist in practice. And AFAIK, the GTA04 board is the only user of this driver in case the battery has no built-in fuel gauge. So why improve it beyond what the GTA04 users need? Because then other users can share the same code, and because you avoid big ugly tables in dts. I repeat myself: this driver is not built for highest precision because there are better methods (fuel gauge chip). These might not be available so this fall-back driver has been built. It is definitively better than no driver and worse than the optimum. And my email suggested solution better than your driver, so why not just use it? #perc = percent(volt) compute(charging, 1) compute(discharging, 0) Please explain what you calculate here. Especially what “Badness” is? Badness is error in least squares method. Here are updated tables: pavel@duo:~/g/tui/ofone$ ./liion_maps Charging Voltage 4.2 V ; table 100 % internal voltage 4.18 V current 0.078 A computed 97 % Voltage 4.1 V ; table 75 % internal voltage 4.08 V current 0.078 A computed 87 % Voltage 4.0 V ; table 55 % internal voltage 3.93 V current 0.233 A computed 69 % Voltage 3.9 V ; table 25 % internal voltage 3.76 V current 0.467 A computed 26 % Voltage 3.8 V ; table 5 % internal voltage 3.66 V current 0.467 A computed 3 % Voltage 3.7 V ; table 2 % internal voltage 3.56 V current 0.467 A computed 2 % Voltage 3.6 V ; table 1 % internal voltage 3.46 V current 0.467 A computed 1 % Voltage 3.3 V ; table 0 % internal voltage 3.16 V current 0.467 A computed -1 % Badness 395.4861761427434 Discharging Voltage 4.2 V ; table 100 % internal voltage 4.21 V current -0.025 A computed 100 % Voltage 4.1 V ; table 95 % internal voltage 4.11 V current -0.025 A computed 91 % Voltage 4.0 V ; table 70 % internal voltage 4.01 V current -0.025 A computed 79 % Voltage 3.8 V ; table 50 % internal voltage 3.81 V current -0.025 A computed 46 % Voltage 3.7 V ; table 10 % internal voltage 3.71 V current -0.025 A computed 3 % Voltage 3.6 V ; table 5 % internal voltage 3.61 V current -0.025 A computed 2 % Voltage 3.3 V ; table 0 % internal voltage 3.31 V current -0.025 A computed 0 % Badness 171.69576218433212 pavel@duo:~/g/tui/ofone$ python Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/14] clkdev: get rid of redundant clk_add_alias() prototype in linux/clk.h
Russell King rmk+ker...@arm.linux.org.uk writes: clk_add_alias() is provided by clkdev, and is not part of the clk API. Howver, it is prototyped in two locations: linux/clkdev.h and linux/clk.h. This is a mess. Get rid of the redundant and unnecessary version in linux/clk.h. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Tested-by: Robert Jarzmik robert.jarz...@free.fr Actually, this serie fixes a regression I've seen in linux-next, and which was triggering the Oops in [1] on lubbock. With your serie, the kernel boots fine. Cheers. -- Robert [1] Oops without this serie on linux-next (20150213, commit b8acf73) [0.223403] Unable to handle kernel paging request at virtual address 32617878 [0.231047] pgd = c0004000 [0.233810] [32617878] *pgd= [0.237486] Internal error: Oops: f5 [#1] ARM [0.241881] Modules linked in: [0.245051] CPU: 0 PID: 1 Comm: swapper Tainted: GW 3.19.0-next-20150213-09795-g3bd95ad-dirty #433 [0.255288] Hardware name: Intel DBPXA250 Development Platform (aka Lubbock) [0.262412] task: c3e46000 ti: c3e48000 task.ti: c3e48000 [0.267903] PC is at __clk_get_hw+0x8/0x10 [0.272150] LR is at clk_get_sys+0xd0/0x120 [0.276437] pc : [c0249018]lr : [c0248f30]psr: a053 [0.276437] sp : c3e49e10 ip : fp : c3e67480 [0.288009] r10: 0003 r9 : 0001 r8 : c0807cc4 [0.293310] r7 : c3e755c0 r6 : c0390d0e r5 : 0001 r4 : c3e67480 [0.299919] r3 : 32617870 r2 : r1 : c0390d0e r0 : c3e75440 [0.306527] Flags: NzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel [0.313996] Control: 397f Table: a0004000 DAC: 0017 [0.319809] Process swapper (pid: 1, stack limit = 0xc3e48190) [0.325710] Stack: (0xc3e49e10 to 0xc3e4a000) [0.330177] 9e00: c07f64c8 c3e75920 c07f64c8 c07f6a98 [0.338502] 9e20: c07f64b8 c07f64c8 0131 c07f6aac c00182e0 c03b6378 c3e79690 [0.346822] 9e40: c3e7afa0 0001 ffed c07f64c8 c07f313c c040a318 [0.355141] 9e60: c041f738 c01e7a40 c07f64c8 c07f64fc c07f313c c01e6614 [0.363466] 9e80: c07f64c8 c07f64fc c07f313c c01e676c c01e67d4 c3e49ea8 [0.371793] 9ea0: c07f313c c01e5030 c3e4534c c3e72870 c07f313c c07f313c c3e72ae0 [0.380119] 9ec0: c0802ff0 c01e5e74 c0390df8 c0390df8 0070 c07f313c c07f1898 c07f1898 [0.388440] 9ee0: c080ce60 c01e6df8 c07f1898 c040a338 c3e75800 c000882c [0.396761] 9f00: c3ffcaaa c03bb7ee c03e2ab0 c03e2ac0 c3e49f30 [0.405082] 9f20: 0086 c3ffcb56 c3ffcb56 c0030450 6053 c03e2b70 c03e27e0 0086 [0.413396] 9f40: 0004 0004 0004 0004 c041f724 c0423ec0 c080ce60 [0.421719] 9f60: 0086 c0404588 c041f738 c0404d3c 0004 0004 c0404588 c3e46000 [0.430028] 9f80: c001cb88 c3e03c14 c02f7d20 [0.438341] 9fa0: c02f7d28 c000e718 [0.446642] 9fc0: [0.454950] 9fe0: 0013 [0.463318] [c0249018] (__clk_get_hw) from [c0248f30] (clk_get_sys+0xd0/0x120) [0.471122] [c0248f30] (clk_get_sys) from [c00182e0] (sa_probe+0x68/0x4c4) [0.478902] [c00182e0] (sa_probe) from [c01e7a40] (platform_drv_probe+0x30/0x78) [0.487155] [c01e7a40] (platform_drv_probe) from [c01e6614] (driver_probe_device+0xac/0x204) [0.496089] [c01e6614] (driver_probe_device) from [c01e67d4] (__driver_attach+0x68/0x8c) [0.504669] [c01e67d4] (__driver_attach) from [c01e5030] (bus_for_each_dev+0x50/0x88) [0.512986] [c01e5030] (bus_for_each_dev) from [c01e5e74] (bus_add_driver+0xc8/0x1c8) [0.521311] [c01e5e74] (bus_add_driver) from [c01e6df8] (driver_register+0x9c/0xe0) [0.529499] [c01e6df8] (driver_register) from [c040a338] (sa_init+0x20/0x30) [0.537393] [c040a338] (sa_init) from [c000882c] (do_one_initcall+0xf8/0x1cc) [0.545362] [c000882c] (do_one_initcall) from [c0404d3c] (kernel_init_freeable+0xe8/0x1b0) [0.554171] [c0404d3c] (kernel_init_freeable) from [c02f7d28] (kernel_init+0x8/0xe4) [0.562444] [c02f7d28] (kernel_init) from [c000e718] (ret_from_fork+0x14/0x3c) [0.570149] Code: 1593 e12fff1e e350 15903000 (15930008) [0.576450] ---[ end trace cb88537fdc8fa201 ]--- [0.581232] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/14] clkdev: get rid of redundant clk_add_alias() prototype in linux/clk.h
On Sat, Apr 04, 2015 at 02:43:22PM +0200, Robert Jarzmik wrote: Russell King rmk+ker...@arm.linux.org.uk writes: clk_add_alias() is provided by clkdev, and is not part of the clk API. Howver, it is prototyped in two locations: linux/clkdev.h and linux/clk.h. This is a mess. Get rid of the redundant and unnecessary version in linux/clk.h. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Tested-by: Robert Jarzmik robert.jarz...@free.fr Actually, this serie fixes a regression I've seen in linux-next, and which was triggering the Oops in [1] on lubbock. With your serie, the kernel boots fine. Yes, this series does fix a regression - I mentioned that the per-user clk patches broke quite a bit of this code in the cover to the series. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
am335x crypto module clocks
Hi all, To my surprise, the am335x clock tree (am33xx-clocks.dtsi) currently lists the functional clock of the AES accelerator and other crypto modules to be the (max 26 MHz) main osc. This struck me as rather unlikely, since the AES module is clocked much higher on other devices, and such a slow clock would condemn it to being slower than a software AES implementation. As usual the TRM is silent on the crypto accelerators and their clock management, but I did some preliminary tests. The AES module turned out far from slow. I actually had a lot of trouble keeping the module continuously fed with data with a simple non-dma test from userspace, since for most modes of operation the AES module could even keep pace with a tight loop using 128-bit neon load/store without even checking its status register for readiness. Although I haven't been able to get obtain a very reliable measurement yet as a result, it appears to be clocked at ~200 MHz. This also matches the fact that it is hooked up to the L3F (which would be rather pointless if it had a separate low-rate fck). It seems very likely to me the other crypto modules will also have a unified fck/ick (L3F for the hash accelerator, L4LS for the RNG and PKA). This should preferably still be double-checked of course. Matthijs -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM errata 430973 on multi platform kernels
On 4 April 2015 at 00:52, Tony Lindgren t...@atomide.com wrote: Right, it affects n900 for sure. My point is that it also seems to affect 37xx versions not listed to suffer from this issue. They shouldn't... erratum 430973 only affected Cortex-A8 r1, and the dm37xx should have an r3p2 right? A word of caution though: at least on the DM814x and AM335x, secure ROM sets bit 6 (IBE) in the Auxiliary Control Register, thereby enabling BTB invalidate instructions (which normally execute as nops). This is presumably a leftover of the erratum 430973 workaround, but it means there is a risk of running afoul of erratum 687067 if BTB invalidate by MVA instructions are actually used. I would actually suggest clearing IBE if it set on Cortex-A8 r2 or later processors and a secure monitor call is available to do so (there is on the DM814x and AM335x, dunno about the 37xx), also for performance reasons: BTB invalidates are quite expensive instructions (when enabled). Matthijs -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6] media: i2c/adp1653: Documentation for devicetree support for adp1653
Hi! enable-gpios: Specifier of the GPIO connected to EN pin I can make the changes if you're ok with that, otherwise please send v7. Then I'll apply that to my tree. I'm ok with that. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6] media: i2c/adp1653: Documentation for devicetree support for adp1653
On Sat, Apr 04, 2015 at 07:11:16PM +0200, Pavel Machek wrote: Hi! enable-gpios: Specifier of the GPIO connected to EN pin I can make the changes if you're ok with that, otherwise please send v7. Then I'll apply that to my tree. I'm ok with that. Thanks. The patch is applied here: git://linuxtv.org/sailus/media_tree.git, branch adp1653 -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
