00:13.19 | *** join/#maemo-ssu amizraa (~amizraa@gateway/tor-sasl/amizraa) |
00:19.11 | *** join/#maemo-ssu drathir_ (~kamiljk8@s51.linuxpl.com) |
02:17.28 | *** join/#maemo-ssu sixwheeledbeast (~paul@cl-1547.lon-02.gb.sixxs.net) |
02:17.29 | *** join/#maemo-ssu jon_y (~enforcer@2002:af8e:4df8::af8e:4df8) |
02:17.29 | *** join/#maemo-ssu nedko (~nedko@unaffiliated/nedko) |
02:17.29 | *** join/#maemo-ssu raccoon_ (user@ghs/raccoon) |
02:17.29 | *** join/#maemo-ssu merlin1991 (~merlin@Maemo/community/cssu/merlin1991) |
02:23.32 | *** part/#maemo-ssu nedko (~nedko@unaffiliated/nedko) |
02:51.57 | *** join/#maemo-ssu amiconn_ (quassel@rockbox/developer/amiconn) |
04:25.54 | *** join/#maemo-ssu jonwil (~jonwil@27-33-137-199.static.tpgi.com.au) |
04:26.35 | *** join/#maemo-ssu DrCode (~DrCode@gateway/tor-sasl/drcode) |
04:30.52 | *** join/#maemo-ssu luf (~luf@80.188.29.62) |
04:35.17 | *** join/#maemo-ssu dafox (~dafox@ip51cc571d.speed.planet.nl) |
05:30.57 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
06:31.23 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-93-219.residential.rdsnet.ro) |
07:04.13 | *** join/#maemo-ssu LaoLang_cool (~LaoLang_c@113.117.185.134) |
07:12.26 | *** join/#maemo-ssu Martix_ (~martix@static-84-242-103-180.net.upcbroadband.cz) |
07:13.50 | *** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali) |
07:31.03 | *** join/#maemo-ssu sunny_s (~sunny_s@business-092-079-020-027.static.arcor-ip.net) |
07:32.19 | *** join/#maemo-ssu arcean (~arcean@aadc120.neoplus.adsl.tpnet.pl) |
08:01.55 | *** join/#maemo-ssu BCMM (~BCMM@unaffiliated/bcmm) |
08:05.14 | freemangordon | Pali: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg95403.html |
08:05.44 | freemangordon | I knew there is something wrong in the clock fw :) |
10:48.41 | *** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1) |
11:01.39 | DocScrutinizer05 | it's a terrible feeling to see what botch is done sometimes in kernel land |
11:06.11 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-37-188-229-91.eurotel.cz) |
11:09.48 | *** join/#maemo-ssu arcean (~arcean@aadc120.neoplus.adsl.tpnet.pl) |
11:10.34 | DocScrutinizer05 | anyway nice find, hope you get cam working now |
11:14.41 | *** join/#maemo-ssu sailus_ (~sailus@valkosipuli.retiisi.org.uk) |
11:18.17 | *** join/#maemo-ssu sailus_ (~sailus@valkosipuli.retiisi.org.uk) |
11:38.40 | *** join/#maemo-ssu DrCode (~DrCode@gateway/tor-sasl/drcode) |
11:51.06 | *** join/#maemo-ssu lizardo (lizardo@nat/indt/x-vtwqixrdcfrjcbdg) |
12:00.20 | DocScrutinizer05 | God gracious, I think I got an angie-hangover - and that might last for the next 4 years |
12:07.31 | Pali | DocScrutinizer05: what is max value for lp5523 "led_current" sysfs entries? |
12:12.40 | DocScrutinizer05 | Pali: I honestly don't know, logically it's a u8 I guess |
12:13.48 | DocScrutinizer05 | the chip supports something as high as maybe 50mA, and anyway the value range is deep into the red regarding what the LEDs on N900 can do |
12:15.50 | DocScrutinizer05 | Pali: lp5523 datasheet: >> 9 programmable outputs with 25.5 mA full-scale current, << |
12:16.31 | DocScrutinizer05 | unit for led_current is 0.1mA |
12:16.44 | DocScrutinizer05 | that's a max 255 for this sysnode |
12:17.24 | DocScrutinizer05 | which conveniently will fry the indicator 3color LED anyway |
12:18.31 | DocScrutinizer05 | according to Nokia guy who designed the LED stuff, the max is 3*10mA for the indLED, aka 3* 100 for sysnode |
12:18.48 | DocScrutinizer05 | ...or LED will literally fry |
12:19.50 | DocScrutinizer05 | for the kbd LEDs I guess they can cope with 20mA each, but that's a guess of mine and nothing you should quote me on |
12:20.39 | *** join/#maemo-ssu DrCode_ (~DrCode@gateway/tor-sasl/drcode) |
12:22.52 | DocScrutinizer05 | Pali: so, what exactly is your question? |
12:24.03 | Pali | DocScrutinizer05: in upstream kernel there is property max_current which needs to be initliazed from board data. and driver allow to change led_current only if new led_current < max_current |
12:24.19 | Pali | by default max_current is 0, so you can think what happen :-) |
12:24.23 | DocScrutinizer05 | in original lp5523.ko of Nokia there are sane presets for the LED current iirc, and maybe or rather probably MCE also does some presets, but in the end nobody incl mce should mess with those values after initial setup |
12:24.45 | Pali | max_current current is only limit for led_current |
12:24.48 | DocScrutinizer05 | Pali: LOL |
12:25.02 | DocScrutinizer05 | well, sane concept |
12:25.10 | Pali | I set max_current to 255 (because led_current is uint8_t) |
12:25.38 | Pali | because original maemo 2.6.28 kernel has u8 led_current and no upper limit |
12:25.46 | DocScrutinizer05 | ok, I gonna takle responsibility for this and define: max_current for all 9 diodes on N900:: 100 aka 10mA |
12:26.24 | DocScrutinizer05 | take even, as well as tackle :-D |
12:27.11 | DocScrutinizer05 | when we already got sth as nice and useful as max_current, we shall use it to enforce sane maximum that keeps LEDs alive |
12:27.27 | DocScrutinizer05 | so: 10mA, set max_current to 100 |
12:27.59 | DocScrutinizer05 | I gather that value comes from board data? |
12:29.38 | DocScrutinizer05 | Pali: ^^^ |
12:30.29 | Pali | DocScrutinizer05: yes max_current is set in rx51 board data |
12:30.40 | Pali | so change it to 100 (it is 10mA?) |
12:30.48 | DocScrutinizer05 | yes |
12:31.08 | DocScrutinizer05 | please |
12:32.23 | Pali | DocScrutinizer05: initial value for all (kb1..kb6,b,r,g) is 50 |
12:32.31 | DocScrutinizer05 | I know |
12:32.36 | Pali | this is OK? |
12:32.39 | DocScrutinizer05 | yes |
12:32.40 | Pali | it is also in board data |
12:34.16 | DocScrutinizer05 | http://wiki.maemo.org/N900_Hardware_LED |
12:40.59 | DocScrutinizer05 | Pali: all the info in there is correct |
12:50.27 | Pali | DocScrutinizer05: I sent new version of patch and CCed you |
12:50.44 | DocScrutinizer05 | thanks |
12:51.16 | Pali | DocScrutinizer05: maybe you can review patch too and sign it |
12:51.24 | Pali | or comment other parts |
12:51.29 | DocScrutinizer05 | not for fame but for later flames you might want to add in patch that the values been defined by me |
12:51.38 | DocScrutinizer05 | sure |
12:53.01 | DocScrutinizer05 | aah, you did |
12:55.05 | DocScrutinizer05 | looks good, what shall I do? |
12:56.58 | DocScrutinizer05 | consider the patch "signed by me" |
13:02.14 | Pali | DocScrutinizer05: if patch is ok, just write something that is correct and you can sign patch by keyword "Signed-off-by:" |
13:07.12 | DocScrutinizer05 | done |
13:09.17 | *** join/#maemo-ssu DrCode (~DrCode@gateway/tor-sasl/drcode) |
13:22.56 | *** join/#maemo-ssu arcean (~arcean@aadc120.neoplus.adsl.tpnet.pl) |
14:21.54 | *** join/#maemo-ssu robotanarchy (~robotanar@f051202058.adsl.alicedsl.de) |
14:23.22 | *** join/#maemo-ssu sailus (~sailus@valkosipuli.retiisi.org.uk) |
14:23.34 | *** join/#maemo-ssu sailus_ (~sailus@valkosipuli.retiisi.org.uk) |
14:48.01 | *** join/#maemo-ssu lrtz (~lartza@IP-62-216-127-116.telemail.fi) |
14:57.04 | freemangordon | Pali: found a bug in the led driver or it is just fix to the board data? |
14:58.44 | Pali | freemangordon: where? |
14:59.12 | freemangordon | Pali: re your discussion with DocScrutinizer05 |
14:59.16 | freemangordon | ^^^ |
14:59.30 | freemangordon | about max current, etc |
14:59.31 | Pali | freemangordon: I did not pushed that new patch to gitorious yet |
14:59.41 | freemangordon | Pali: ok, but is there a bug? |
14:59.42 | DocScrutinizer05 | freemangordon: the latter |
14:59.45 | Pali | which changing 255 to 100 |
14:59.51 | freemangordon | ok |
15:00.16 | freemangordon | Pali: did you see the link I posted ^^^ |
15:00.20 | DocScrutinizer05 | it could be considered "bug in board data" |
15:00.26 | freemangordon | :nod: |
15:00.41 | freemangordon | can't we limit that to 50 instead of 100? |
15:00.54 | freemangordon | mce set it to 47 aiui |
15:01.05 | DocScrutinizer05 | I gather max_current is write-once, just like FMTX max power |
15:01.28 | DocScrutinizer05 | if it's n ot, then THAT would actually be a bug |
15:01.36 | DocScrutinizer05 | in driver |
15:01.57 | freemangordon | will check the permissions when I boot the kernel |
15:02.06 | DocScrutinizer05 | freemangordon: nope, the limits are checked and correct |
15:02.06 | Pali | DocScrutinizer05: it is const compile time variable |
15:02.14 | DocScrutinizer05 | ooh, even better |
15:02.21 | freemangordon | if it is anything but 0444 I guess we can fix it |
15:02.24 | Pali | for chaning it you need to recompile zImage |
15:02.45 | freemangordon | Pali: what are the permissions of sysfs entry? |
15:04.07 | DocScrutinizer05 | of which entry? |
15:04.27 | DocScrutinizer05 | max_current? this shall be r/o |
15:04.44 | freemangordon | sure, buit what are the actual permissions :) |
15:04.45 | Pali | freemangordon: this is not about permission, but it is variable in board data file in some structure |
15:04.55 | freemangordon | Pali: this is exposed in sysfs |
15:04.57 | Pali | permission is of course 0444 |
15:05.06 | DocScrutinizer05 | :-) |
15:05.07 | Pali | but you should not change it |
15:05.16 | Pali | and you also cannot |
15:05.17 | DocScrutinizer05 | 444 correct |
15:05.19 | freemangordon | Pali: it is fine then :) |
15:05.25 | Pali | ok :-) |
15:05.32 | Pali | going to push that patch into gitorious |
15:06.17 | Pali | pushed |
15:06.38 | freemangordon | Pali: see http://www.mail-archive.com/linux-omap@vger.kernel.org/msg95403.html |
15:07.10 | Pali | what is with that? |
15:07.32 | freemangordon | wrong dpll/frequency calculation |
15:07.42 | freemangordon | on 3430 |
15:07.58 | freemangordon | I'll try that patrch now |
15:08.17 | DocScrutinizer05 | and try if it actually kicks in |
15:08.19 | freemangordon | but it seems half of the clocks are wrong :) |
15:08.54 | DocScrutinizer05 | I'm musing about all that insane clock generation auto-guess code |
15:09.02 | freemangordon | DocScrutinizer05: for sure it kicks in, remember my discussion with sailus about strange frequencies? the same strange frequency I have with ssi clocks |
15:09.10 | DocScrutinizer05 | seems like an odd way to handle clocks |
15:09.16 | freemangordon | DocScrutinizer05: actually I like that "clock framework" |
15:09.29 | *** join/#maemo-ssu arcean (~arcean@aadc120.neoplus.adsl.tpnet.pl) |
15:09.52 | freemangordon | and maybe I will like this DT shit too, it seems after all those are not 3d objects :) |
15:10.50 | DocScrutinizer05 | setting up clock dividers and muxes and whatnot is a *very* complex thing to do the right way, even for humans using their brain and all the datasheets. It sounds weird to try and write an algo that does all this in a generic way |
15:11.22 | freemangordon | DocScrutinizer05: no algo, stuff is hardcoded |
15:11.27 | DocScrutinizer05 | mhm |
15:11.30 | DocScrutinizer05 | ok then |
15:11.40 | DocScrutinizer05 | that's actually what I'd do |
15:11.46 | freemangordon | there is a clock tree |
15:11.50 | *** join/#maemo-ssu NIN101 (~NIN@p5DD280A0.dip0.t-ipconnect.de) |
15:11.56 | DocScrutinizer05 | yep, it's a tree |
15:12.03 | DocScrutinizer05 | the clock dependencies |
15:12.08 | freemangordon | :nod: |
15:12.27 | freemangordon | the same goes for the power supplies iiuc |
15:12.52 | DocScrutinizer05 | so when they use a static data structure to represent that tree with all the solutions for various tuples of clocks, that's OK I guess |
15:13.19 | DocScrutinizer05 | rather a forest |
15:13.20 | freemangordon | so all that is up to you is to define which clocks and power supplies your device uses |
15:13.42 | DocScrutinizer05 | :nod: |
15:14.06 | freemangordon | framework finds the dependencies and enables the appropriate plls/dividers, etc |
15:14.12 | freemangordon | and power supplies |
15:14.21 | freemangordon | so it looks fine |
15:14.21 | DocScrutinizer05 | basically it's a sparse multidimensional array |
15:14.46 | DocScrutinizer05 | ideally augmented by allowing wildcards |
15:15.20 | freemangordon | ok, booting with ^^^ patch, lets see :) |
15:15.28 | DocScrutinizer05 | :-) |
15:15.34 | DocScrutinizer05 | good luck! |
15:16.29 | freemangordon | well, at least it still boots :D |
15:16.56 | freemangordon | Pali: btw I reverted your et8ek8 FW patch and the oops is gone |
15:17.17 | Pali | ok, will look at it later |
15:17.28 | Pali | at least we know what caused it |
15:17.37 | freemangordon | Pali: looking through the code, I wondered what "offset" is supposed to mean |
15:17.50 | freemangordon | could it be an offset into the file? not a pointer |
15:17.53 | freemangordon | ok |
15:20.33 | Pali | <PROTECTED> |
15:20.52 | Pali | freemangordon: so there is problem |
15:20.56 | Pali | you are right |
15:21.14 | freemangordon | :) |
15:23.40 | DocScrutinizer05 | hah |
15:23.54 | DocScrutinizer05 | bbl |
15:24.27 | Pali | this is retarded nonsense usage of pointers |
15:24.54 | Pali | specifing relative offset of of current stucture to another... |
15:27.10 | Pali | how can I write this C code? struct A a = { .val = 1 }; struct B b = { .val = &a - &b; }; |
15:27.17 | DocScrutinizer05 | err, that's frequently used in ~80% of file formats |
15:27.41 | Pali | C does not allow to do (&a - &b) in initlializer |
15:28.09 | Pali | and structure B b needs value which will be offset between struct A a and struct B b |
15:28.17 | freemangordon | Pali: hmm, those are different types I guess |
15:28.23 | Pali | it is even possible |
15:28.35 | freemangordon | try to cast to uintptr_t |
15:28.36 | Pali | freemangordon: casting to (uintptr_t) is possible |
15:28.46 | Pali | but problem is with operation minus |
15:28.59 | Pali | C does not allow that operation at compile time in initliaizer |
15:29.16 | Pali | error: initializer element is not constant |
15:29.22 | Pali | gcc output ^^^^ |
15:29.28 | DocScrutinizer05 | meh |
15:29.29 | freemangordon | Pali: declare structs as const |
15:29.42 | freemangordon | static const even |
15:29.50 | Pali | static are already |
15:29.53 | Pali | will try const |
15:30.39 | Pali | const does not helped, same problem |
15:31.15 | Pali | this is first time I saw someting ugly as this |
15:32.03 | freemangordon | Pali: try to cast the pointers to (const uintptr_t*) |
15:32.15 | Pali | only one solution I see to remove const, initliaze that values to 0L and then use init function for that |
15:32.34 | Pali | (const uintptr_t) |
15:32.36 | Pali | without * |
15:32.38 | freemangordon | :nod: |
15:32.58 | Pali | still not working |
15:32.58 | freemangordon | Pali: the correct way to handle that is to not use offsets :) |
15:33.16 | freemangordon | but to rewrite smiaregs to usee pointers |
15:33.20 | Pali | ok, will try to change smia code |
15:45.53 | Pali | freemangordon: try this patch: http://pastebin.com/M6WdEcYJ |
16:01.00 | FatPhil | Pali: you can't sensibly do "struct A a = { .val = 1 }; struct B b = { .val = &a - &b; };" - it's illegal C |
16:01.52 | FatPhil | You cannot subtract pointers of things which don't point to (parts of) the same object. |
16:03.53 | FatPhil | so I agree with freemangordon - these aren't offsets to C, so don't try and pretend they are. |
16:07.23 | Pali | FatPhil: I already changed code, so that offset (-&b) is not needed and using directly pointer |
16:07.48 | FatPhil | patch on pastebin looks like an improvement, certainly |
16:08.17 | FatPhil | The question that it raises is why the earlier horrors existed - it just looks wrong! |
16:08.49 | freemangordon | Pali: ok |
16:09.15 | FatPhil | Anything which removes casts is generally an improvement to code. |
16:09.32 | Pali | FatPhil: now i think why: that data structures comes from userspace via request_firmware and was created by gcc and objcopy |
16:10.21 | Pali | and in that userspace blob was every structure calucated against some "main" |
16:10.36 | FatPhil | I've not looked into the file as a whole, so take your word on that |
16:11.15 | Pali | and these hacks were needed for converting structures from that userspace blob which comes from request_firmware to native kernel structures |
16:11.27 | Pali | very ugly solution... |
16:12.13 | FatPhil | But the addresses that the compiler gives you (unless you're using linker hacks) tell you nothing about the location of data in firmware. |
16:12.26 | DocScrutinizer05 | yep |
16:12.32 | FatPhil | the compiler's permitted to allocate those structures in alphabetical order, or in reverse |
16:12.44 | FatPhil | The correct solution is to struct all of the structs together |
16:12.47 | DocScrutinizer05 | unless it's one large structure |
16:12.51 | Pali | do not look at that linker hacks... |
16:12.57 | Pali | it using lot of perl code |
16:13.13 | FatPhil | Perl to generate linker hacks? |
16:13.15 | FatPhil | NACK! |
16:14.09 | DocScrutinizer05 | wtf, nmap the firmware file, set readpointer to offset of data structure and read it in from file to local variable struct |
16:16.25 | FatPhil | well, request firmware is the standard way of getting the data in, there's no problem with that. |
16:17.03 | FatPhil | kernel shouldn't filp_open, for example |
16:18.39 | FatPhil | I can't really suggest anything - I don't have any et8ek8 here, I presume that's on my home machine. |
16:18.48 | FatPhil | goes home |
16:19.02 | FatPhil | (after he's finished his pot of tea) |
16:29.56 | *** join/#maemo-ssu bsdmaniak (~bsdmaniak@std93-20-88-120-139-80.fbx.proxad.net) |
16:31.25 | freemangordon | Pali: arch/arm/mach-omap2/board-rx51-peripherals.c:1272:34: warning: 'rx51_t2scripts_data' defined but not used [-Wunused-variable] |
16:31.51 | freemangordon | I guess this is a result from so-called "fix power off/restart problem" or whatever that patch was called |
16:32.22 | Pali | freemangordon: yes, ask more Skry |
16:32.35 | Pali | you can ignore that warning |
17:10.06 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
17:12.35 | freemangordon | Pali: hmm, but, but... this struct is the power management scripts, ain;t? |
17:12.59 | Pali | freemangordon: yes, but it causing poweroff problems |
17:13.13 | Pali | this needs to be fixed |
17:13.18 | freemangordon | ok |
17:19.25 | DocScrutinizer05 | FatPhil: you had a chance to check the part number on N9 PoP? |
17:36.14 | FatPhil | DocScrutinizer05: didn't know I was going to do that! |
17:36.44 | FatPhil | Isn't that identified in the boot log (although perhaps somewhat cryptically) |
17:37.04 | FatPhil | Can't check - don't have n9 jig |
17:40.23 | DocScrutinizer05 | don't worry, I'll disassemble my N9 then |
17:40.57 | DocScrutinizer05 | thanks nevertheless |
17:44.03 | DocScrutinizer05 | ooops, actually I mixed up things (rather persons), sorry |
17:46.02 | DocScrutinizer05 | and actually not only persons but also channels |
17:57.14 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
18:08.57 | *** join/#maemo-ssu arcean (~arcean@aadc120.neoplus.adsl.tpnet.pl) |
18:12.59 | *** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali) |
18:27.52 | *** join/#maemo-ssu _nicolai_ (~nicolai@pop8-126.catv.wtnet.de) |
18:29.04 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
18:52.31 | DocScrutinizer05 | I just noticed a bug in cameraui2: starting it via "Kamera" icon from applauncher opened the gui but didn't show the "Open Lens Door!" display. Opening lens door switched the display to something without any widgets, only viewfinder (and maybe one or two widgets remaining, like focus frame and close button). |
18:52.56 | DocScrutinizer05 | can't reproduce that effect, possibly only "works" after reboot |
18:53.44 | DocScrutinizer05 | comparing to a stock (non-CSSU) system didn't show same effect there |
19:19.10 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-89-177-124-88.net.upcbroadband.cz) |
19:30.44 | *** join/#maemo-ssu luf (~luf@ip-89-103-184-55.net.upcbroadband.cz) |
20:03.35 | *** join/#maemo-ssu sailus_ (~sailus@valkosipuli.retiisi.org.uk) |
20:13.30 | *** join/#maemo-ssu arcean (~arcean@aadc120.neoplus.adsl.tpnet.pl) |
20:22.41 | *** join/#maemo-ssu sailus (~sailus@valkosipuli.retiisi.org.uk) |
20:22.59 | *** join/#maemo-ssu sailus_ (~sailus@valkosipuli.retiisi.org.uk) |
20:33.59 | *** join/#maemo-ssu DrCode (~DrCode@gateway/tor-sasl/drcode) |
20:39.50 | *** join/#maemo-ssu xes (~xes@unaffiliated/xes) |
20:50.09 | *** join/#maemo-ssu BCMM (~user@unaffiliated/bcmm) |
21:20.07 | *** join/#maemo-ssu robotanarchy_ (~robotanar@g230128161.adsl.alicedsl.de) |
21:31.47 | *** join/#maemo-ssu int_ua (~int_ua@ip-602f.proline.net.ua) |
21:37.52 | *** join/#maemo-ssu mkaindl (~mkaindl@ama-dablam.markus-kaindl.de) |
21:39.59 | *** join/#maemo-ssu discopig (~discopig@unaffiliated/discopig) |
22:08.31 | *** join/#maemo-ssu freemangordon_ (~freemango@213.137.35.49) |
22:17.22 | *** part/#maemo-ssu _nicolai_ (~nicolai@pop8-126.catv.wtnet.de) |
23:52.43 | DocScrutinizer05 | I'm ambarassingly proud of jonwil, pali, freemangordon. Thnaks guys for your insight and your awesome work |
23:58.53 | *** part/#maemo-ssu mkaindl (~mkaindl@ama-dablam.markus-kaindl.de) |