| joerg | that last sentence sounds like a citation of sth I wrote :-) | 08:58 |
|---|---|---|
| sicelo | :p | 11:20 |
| joerg | https://wiki.maemo.org/N900_Hardware_LED | 11:52 |
| joerg | :-) | 11:52 |
| joerg | the awesome speedevil, now cloudevil | 12:00 |
| joerg | https://wiki.maemo.org/index.php?title=N900_Hardware_LED&action=history | 12:02 |
| joerg | sicelo: 50mA is self-destruct setting for N900 indicator LEd. though you probably meant an integer: 50 in the led_current | 12:04 |
| joerg | another flaw in that driver kernel module. such values are always in microampere afaik | 12:06 |
| joerg | sicelo: you probably should read https://www.ti.com/lit/ds/symlink/lp5523.pdf - the LED control is not exactly trivial. There's current control, brighness control, iirc there's also conversion for physiological (log) brightness perception | 13:34 |
| sixwheeledbeast | 50uA seems more like it | 13:39 |
| joerg | sixwheeledbeast: nah, the units are messed up completely. it's like $value * 100uA | 13:41 |
| sixwheeledbeast | o.O | 13:41 |
| joerg | https://wiki.maemo.org/N900_Hardware_LED >>Despite the line #define LP5523_DEFAULT_CURRENT 50 /* microAmps */ suggesting different, the units in there are 0.1 mA (100 µA per step is correct). So the driver init default "50" for all LEDs is 5 mA ...<< | 13:42 |
| sixwheeledbeast | I certainly wouldn't expect 50mA to last long as you say but how misleading... | 13:43 |
| joerg | took me a while to spot this, evaluate it, dig up the sourcecode and "publish" my results ;-) | 13:43 |
| joerg | the kernel module is fubar | 13:44 |
| joerg | well, not fuBAR but pretty flawed | 13:44 |
| joerg | it was somewhat appropraze for the N810's LP5521, but the pimping it up for the LP5523 been done in a hurry, or by somebody not exactly competent or interested in doing it compiant with a linux FOSS kernel module / device interface and enabling all the features of the 5523 | 13:46 |
| joerg | and iirc the LED_current is only for the (semi-static) ABSMAX setting that the LED can cope with, at a btightness of 100% PWM duty cycle | 13:51 |
| joerg | >> The overall maximum current for each driver is set by an 8-bit register. The LP5523 controls LED luminance with a pulse width modulation (PWM) scheme with a resolution of 12 bits << [from dadashit] | 13:52 |
| joerg | https://e2e.ti.com/blogs_/b/powerhouse/posts/led-brightness-adjustment-high-frequency-pwm-dimming >>…For a fixed-frequency switched-mode power supply-type LED driver using a DC-to-DC conversion architecture, the loop bandwidth is typically designed at or below 50kHz. That imposes a limit on the contrast ratio to about 25-to-1 with a 2kHz PWM dimming frequency. To achieve a better contrast ratio, you must either use a lower PWM dimming frequency or try to | 13:56 |
| joerg | further increase the loop bandwidth.<< loosely related to "why 8bit linear current control are only capable of ~ 8 distinct levels of brightness" | 13:56 |
| joerg | sicelo: do you use an IRC client that makes it difficult to tell apart which channel a dialog is in? ;-) | 14:18 |
| sicelo | hehe, irssi | 14:19 |
| sicelo | i guess I'm trying to do too many things at same time | 14:19 |
| sicelo | #maemo is next to #maemo-leste in my window list | 14:20 |
| joerg | :-D | 14:20 |
| sicelo | btw, i think the driver in linux mainline doesn't have the limitations that exist in maemo kernel | 14:22 |
| joerg | fun factoid: I chatted with the chip developer of the LP5521/23 back in maybe 2010. He told me about some anecdotes and what he thought how to really use the chip's features to their full potential | 14:23 |
| sicelo | it's got really nice features | 14:28 |
| joerg | sicelo: >>the limitations that exist in maemo kernel<< what in detail are those? | 16:08 |
| sicelo | the pattern length, 'Supports 32-96 steps per engine, dynamically-assigned, alas the lp5523.ko driver is braindamaged and doesn't support more than 16 instructions per engine' | 16:11 |
| joerg | I know of: LED_current is a completely arbitrary and misleading unit of 100uA/count, and there's no concept to support dynamic allocation of the total 96 "steps" of program memory between the 3 machines (partitioning). I wouldn't call either of both a limitation, and it's pretty hard to come up with a "fix" that doesn't break the compatibility | 16:13 |
| joerg | I seem to recall I suggested a 32 steps per engine, fixed | 16:14 |
| joerg | which got implemented in powerkernel | 16:14 |
| joerg | iirc | 16:14 |
| sicelo | ah, ok. i'm on PK in fremantle, yes | 16:16 |
| joerg | a cool approach would allow arbitrary number of program steps written into the program register#N (for engine N {0-2}) and the kernel module driver auto-determines the partitioning and returns an error if you're trying to write more steps than available | 16:17 |
| joerg | so you could write a 16 steps to engine#2, 32 steps to engine#1 and then you could write up to 48 steps to engine#0. for example | 16:19 |
| joerg | but that's sort of annoying if you want to change the partitioning | 16:20 |
| joerg | well, it might work. When - in aboce example - you want to write a new program with more than 16, say e.g. 18steps to #2, you first need to write a new 2 steps shorter program to either #1 or #0, or you write a 1 step shorter program to #2 AND #1. So you got 2 steps freed that makes for a 18 available for #0 then. | 16:25 |
| joerg | damn, I mixed it up, please let me redo | 16:26 |
| joerg | well, it might work. When - in aboce example - you want to write a new program with more than 16, say e.g. 18steps to #2, you first need to write a new 2 steps shorter program to either #1 or #0, or you write a 1 step shorter program to #1 AND #0. So you got 2 steps freed that makes for a 18 available for #2 then. | 16:27 |
| joerg | https://termbin.com/rhe8 | 16:37 |
| joerg | I wonder if those filenames are actually listed anywhere in wiki | 16:38 |
| sicelo | yes they are | 16:45 |
| joerg | where? | 16:49 |
| joerg | I _think_ they would belong to https://wiki.maemo.org/LED_patterns#Low_Level or to https://wiki.maemo.org/N900_Hardware_LED (section "Software"?) | 16:51 |
| joerg | did the latter | 17:01 |
| sicelo | joerg: the engine<number>_<function> files are explained in the Hardware section of that same page, but no harm adding them all explicitly | 19:50 |
| sicelo | fwiw, in fremantle kernel, engineN_load and engineN_leds only appears after 'load' is written to engineN_mode. in mainline linux kernel they're always there. anyway end result is exactly the same | 19:52 |
| sicelo | oh and there's a little bug in the kernel model (both mainline and Fremantle) : | 23:05 |
| sicelo | when you disable an engine, and if an led was turned on at that moment, it remains on, until you manually turn it off yourself | 23:07 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!