**** BEGIN LOGGING AT Thu Dec 15 02:59:56 2022 Dec 15 07:58:21 that last sentence sounds like a citation of sth I wrote :-) Dec 15 10:20:41 :p Dec 15 10:52:19 https://wiki.maemo.org/N900_Hardware_LED Dec 15 10:52:21 :-) Dec 15 11:00:13 the awesome speedevil, now cloudevil Dec 15 11:02:46 https://wiki.maemo.org/index.php?title=N900_Hardware_LED&action=history Dec 15 11:04:36 sicelo: 50mA is self-destruct setting for N900 indicator LEd. though you probably meant an integer: 50 in the led_current Dec 15 11:06:37 another flaw in that driver kernel module. such values are always in microampere afaik Dec 15 12:34:05 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 Dec 15 12:39:40 50uA seems more like it Dec 15 12:41:13 sixwheeledbeast: nah, the units are messed up completely. it's like $value * 100uA Dec 15 12:41:52 o.O Dec 15 12:42:18 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 ...<< Dec 15 12:43:22 I certainly wouldn't expect 50mA to last long as you say but how misleading... Dec 15 12:43:46 took me a while to spot this, evaluate it, dig up the sourcecode and "publish" my results ;-) Dec 15 12:44:22 the kernel module is fubar Dec 15 12:44:43 well, not fuBAR but pretty flawed Dec 15 12:46:41 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 Dec 15 12:51:36 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 Dec 15 12:52:56 >> 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] Dec 15 12:56:09 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 Dec 15 12:56:11 further increase the loop bandwidth.<< loosely related to "why 8bit linear current control are only capable of ~ 8 distinct levels of brightness" Dec 15 13:18:38 sicelo: do you use an IRC client that makes it difficult to tell apart which channel a dialog is in? ;-) Dec 15 13:19:16 hehe, irssi Dec 15 13:19:45 i guess I'm trying to do too many things at same time Dec 15 13:20:14 #maemo is next to #maemo-leste in my window list Dec 15 13:20:22 :-D Dec 15 13:22:00 btw, i think the driver in linux mainline doesn't have the limitations that exist in maemo kernel Dec 15 13:23:02 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 Dec 15 13:28:06 it's got really nice features Dec 15 15:08:25 sicelo: >>the limitations that exist in maemo kernel<< what in detail are those? Dec 15 15:11:27 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' Dec 15 15:13:32 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 Dec 15 15:14:04 I seem to recall I suggested a 32 steps per engine, fixed Dec 15 15:14:19 which got implemented in powerkernel Dec 15 15:14:25 iirc Dec 15 15:16:07 ah, ok. i'm on PK in fremantle, yes Dec 15 15:17:02 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 Dec 15 15:19:10 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 Dec 15 15:20:36 but that's sort of annoying if you want to change the partitioning Dec 15 15:25:35 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. Dec 15 15:26:20 damn, I mixed it up, please let me redo Dec 15 15:27:26 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. Dec 15 15:37:58 https://termbin.com/rhe8 Dec 15 15:38:28 I wonder if those filenames are actually listed anywhere in wiki Dec 15 15:45:49 yes they are Dec 15 15:49:07 where? Dec 15 15:51:19 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"?) Dec 15 16:01:22 did the latter Dec 15 18:50:45 joerg: the engine_ files are explained in the Hardware section of that same page, but no harm adding them all explicitly Dec 15 18:52:44 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 Dec 15 22:05:52 oh and there's a little bug in the kernel model (both mainline and Fremantle) : Dec 15 22:07:18 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 **** ENDING LOGGING AT Fri Dec 16 02:59:56 2022