IRC log for #maemo-ssu on 20130923

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.14freemangordonPali: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg95403.html
08:05.44freemangordonI knew there is something wrong in the clock fw :)
10:48.41*** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1)
11:01.39DocScrutinizer05it'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.34DocScrutinizer05anyway 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.20DocScrutinizer05God gracious, I think I got an angie-hangover - and that might last for the next 4 years
12:07.31PaliDocScrutinizer05: what is max value for lp5523 "led_current" sysfs entries?
12:12.40DocScrutinizer05Pali: I honestly don't know, logically it's a u8 I guess
12:13.48DocScrutinizer05the 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.50DocScrutinizer05Pali: lp5523 datasheet: >> 9 programmable outputs with 25.5 mA full-scale current, <<
12:16.31DocScrutinizer05unit for led_current is 0.1mA
12:16.44DocScrutinizer05that's a max 255 for this sysnode
12:17.24DocScrutinizer05which conveniently will fry the indicator 3color LED anyway
12:18.31DocScrutinizer05according to Nokia guy who designed the LED stuff, the max is 3*10mA for the indLED, aka 3* 100 for sysnode
12:18.48DocScrutinizer05...or LED will literally fry
12:19.50DocScrutinizer05for 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.52DocScrutinizer05Pali: so, what exactly is your question?
12:24.03PaliDocScrutinizer05: 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.19Paliby default max_current is 0, so you can think what happen :-)
12:24.23DocScrutinizer05in 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.45Palimax_current current is only limit for led_current
12:24.48DocScrutinizer05Pali: LOL
12:25.02DocScrutinizer05well, sane concept
12:25.10PaliI set max_current to 255 (because led_current is uint8_t)
12:25.38Palibecause original maemo 2.6.28 kernel has u8 led_current and no upper limit
12:25.46DocScrutinizer05ok, I gonna takle responsibility for this and define: max_current for all 9 diodes on N900:: 100 aka 10mA
12:26.24DocScrutinizer05take even, as well as tackle :-D
12:27.11DocScrutinizer05when 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.27DocScrutinizer05so: 10mA, set max_current to 100
12:27.59DocScrutinizer05I gather that value comes from board data?
12:29.38DocScrutinizer05Pali: ^^^
12:30.29PaliDocScrutinizer05: yes max_current is set in rx51 board data
12:30.40Paliso change it to 100 (it is 10mA?)
12:30.48DocScrutinizer05yes
12:31.08DocScrutinizer05please
12:32.23PaliDocScrutinizer05: initial value for all (kb1..kb6,b,r,g) is 50
12:32.31DocScrutinizer05I know
12:32.36Palithis is OK?
12:32.39DocScrutinizer05yes
12:32.40Paliit is also in board data
12:34.16DocScrutinizer05http://wiki.maemo.org/N900_Hardware_LED
12:40.59DocScrutinizer05Pali: all the info in there is correct
12:50.27PaliDocScrutinizer05: I sent new version of patch and CCed you
12:50.44DocScrutinizer05thanks
12:51.16PaliDocScrutinizer05: maybe you can review patch too and sign it
12:51.24Palior comment other parts
12:51.29DocScrutinizer05not for fame but for later flames you might want to add in patch that the values been defined by me
12:51.38DocScrutinizer05sure
12:53.01DocScrutinizer05aah, you did
12:55.05DocScrutinizer05looks good, what shall I do?
12:56.58DocScrutinizer05consider the patch "signed by me"
13:02.14PaliDocScrutinizer05: if patch is ok, just write something that is correct and you can sign patch by keyword "Signed-off-by:"
13:07.12DocScrutinizer05done
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.04freemangordonPali: found a bug in the led driver or it is just fix to the board data?
14:58.44Palifreemangordon: where?
14:59.12freemangordonPali: re your discussion with DocScrutinizer05
14:59.16freemangordon^^^
14:59.30freemangordonabout max current, etc
14:59.31Palifreemangordon: I did not pushed that new patch to gitorious yet
14:59.41freemangordonPali: ok, but is there a bug?
14:59.42DocScrutinizer05freemangordon: the latter
14:59.45Paliwhich changing 255 to 100
14:59.51freemangordonok
15:00.16freemangordonPali: did you see the link I posted ^^^
15:00.20DocScrutinizer05it could be considered "bug in board data"
15:00.26freemangordon:nod:
15:00.41freemangordoncan't we limit that to 50 instead of 100?
15:00.54freemangordonmce set it to 47 aiui
15:01.05DocScrutinizer05I gather max_current is write-once, just like FMTX max power
15:01.28DocScrutinizer05if it's n ot, then THAT would actually be a bug
15:01.36DocScrutinizer05in driver
15:01.57freemangordonwill check the permissions when I boot the kernel
15:02.06DocScrutinizer05freemangordon: nope, the limits are checked and correct
15:02.06PaliDocScrutinizer05: it is const compile time variable
15:02.14DocScrutinizer05ooh, even better
15:02.21freemangordonif it is anything but 0444 I guess we can fix it
15:02.24Palifor chaning it you need to recompile zImage
15:02.45freemangordonPali: what are the permissions of sysfs entry?
15:04.07DocScrutinizer05of which entry?
15:04.27DocScrutinizer05max_current? this shall be r/o
15:04.44freemangordonsure, buit what are the actual permissions :)
15:04.45Palifreemangordon: this is not about permission, but it is variable in board data file in some structure
15:04.55freemangordonPali: this is exposed in sysfs
15:04.57Palipermission is of course 0444
15:05.06DocScrutinizer05:-)
15:05.07Palibut you should not change it
15:05.16Paliand you also cannot
15:05.17DocScrutinizer05444 correct
15:05.19freemangordonPali: it is fine then :)
15:05.25Paliok :-)
15:05.32Paligoing to push that patch into gitorious
15:06.17Palipushed
15:06.38freemangordonPali: see http://www.mail-archive.com/linux-omap@vger.kernel.org/msg95403.html
15:07.10Paliwhat is with that?
15:07.32freemangordonwrong dpll/frequency calculation
15:07.42freemangordonon 3430
15:07.58freemangordonI'll try that patrch now
15:08.17DocScrutinizer05and try if it actually kicks in
15:08.19freemangordonbut it seems half of the clocks are wrong :)
15:08.54DocScrutinizer05I'm musing about all that insane clock generation auto-guess code
15:09.02freemangordonDocScrutinizer05: for sure it kicks in, remember my discussion with sailus about strange frequencies? the same strange frequency I have with ssi clocks
15:09.10DocScrutinizer05seems like an odd way to handle clocks
15:09.16freemangordonDocScrutinizer05: actually I like that "clock framework"
15:09.29*** join/#maemo-ssu arcean (~arcean@aadc120.neoplus.adsl.tpnet.pl)
15:09.52freemangordonand maybe I will like this DT shit too, it seems after all those are not 3d objects :)
15:10.50DocScrutinizer05setting 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.22freemangordonDocScrutinizer05: no algo, stuff is hardcoded
15:11.27DocScrutinizer05mhm
15:11.30DocScrutinizer05ok then
15:11.40DocScrutinizer05that's actually what I'd do
15:11.46freemangordonthere is a clock tree
15:11.50*** join/#maemo-ssu NIN101 (~NIN@p5DD280A0.dip0.t-ipconnect.de)
15:11.56DocScrutinizer05yep, it's a tree
15:12.03DocScrutinizer05the clock dependencies
15:12.08freemangordon:nod:
15:12.27freemangordonthe same goes for the power supplies iiuc
15:12.52DocScrutinizer05so 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.19DocScrutinizer05rather a forest
15:13.20freemangordonso all that is up to you is to define which clocks and power supplies your device uses
15:13.42DocScrutinizer05:nod:
15:14.06freemangordonframework finds the dependencies and enables the appropriate plls/dividers, etc
15:14.12freemangordonand power supplies
15:14.21freemangordonso it looks fine
15:14.21DocScrutinizer05basically it's a sparse multidimensional array
15:14.46DocScrutinizer05ideally augmented by allowing wildcards
15:15.20freemangordonok, booting with ^^^ patch, lets see :)
15:15.28DocScrutinizer05:-)
15:15.34DocScrutinizer05good luck!
15:16.29freemangordonwell, at least it still boots :D
15:16.56freemangordonPali: btw I reverted your et8ek8 FW patch and the oops is gone
15:17.17Paliok, will look at it later
15:17.28Paliat least we know what caused it
15:17.37freemangordonPali: looking through the code, I wondered what "offset" is supposed to mean
15:17.50freemangordoncould it be an offset into the file? not a pointer
15:17.53freemangordonok
15:20.33Pali<PROTECTED>
15:20.52Palifreemangordon: so there is problem
15:20.56Paliyou are right
15:21.14freemangordon:)
15:23.40DocScrutinizer05hah
15:23.54DocScrutinizer05bbl
15:24.27Palithis is retarded nonsense usage of pointers
15:24.54Palispecifing relative offset of of current stucture to another...
15:27.10Palihow can I write this C code? struct A a = { .val = 1 }; struct B b = { .val = &a - &b; };
15:27.17DocScrutinizer05err, that's frequently used in ~80% of file formats
15:27.41PaliC does not allow to do (&a - &b) in initlializer
15:28.09Paliand structure B b needs value which will be offset between struct A a and struct B b
15:28.17freemangordonPali: hmm, those are different types I guess
15:28.23Paliit is even possible
15:28.35freemangordontry to cast to uintptr_t
15:28.36Palifreemangordon: casting to (uintptr_t) is possible
15:28.46Palibut problem is with operation minus
15:28.59PaliC does not allow that operation at compile time in initliaizer
15:29.16Palierror: initializer element is not constant
15:29.22Paligcc output ^^^^
15:29.28DocScrutinizer05meh
15:29.29freemangordonPali: declare structs as const
15:29.42freemangordonstatic const even
15:29.50Palistatic are already
15:29.53Paliwill try const
15:30.39Paliconst does not helped, same problem
15:31.15Palithis is first time I saw someting ugly as this
15:32.03freemangordonPali: try to cast the pointers to (const uintptr_t*)
15:32.15Palionly one solution I see to remove const, initliaze that values to 0L and then use init function for that
15:32.34Pali(const uintptr_t)
15:32.36Paliwithout *
15:32.38freemangordon:nod:
15:32.58Palistill not working
15:32.58freemangordonPali: the correct way to handle that is to not use offsets :)
15:33.16freemangordonbut to rewrite smiaregs to usee pointers
15:33.20Paliok, will try to change smia code
15:45.53Palifreemangordon: try this patch: http://pastebin.com/M6WdEcYJ
16:01.00FatPhilPali: you can't sensibly do "struct A a = { .val = 1 }; struct B b = { .val = &a - &b; };" - it's illegal C
16:01.52FatPhilYou cannot subtract pointers of things which don't point to (parts of) the same object.
16:03.53FatPhilso I agree with freemangordon - these aren't offsets to C, so don't try and pretend they are.
16:07.23PaliFatPhil: I already changed code, so that offset (-&b) is not needed and using directly pointer
16:07.48FatPhilpatch on pastebin looks like an improvement, certainly
16:08.17FatPhilThe question that it raises is why the earlier horrors existed - it just looks wrong!
16:08.49freemangordonPali: ok
16:09.15FatPhilAnything which removes casts is generally an improvement to code.
16:09.32PaliFatPhil: now i think why: that data structures comes from userspace via request_firmware and was created by gcc and objcopy
16:10.21Paliand in that userspace blob was every structure calucated against some "main"
16:10.36FatPhilI've not looked into the file as a whole, so take your word on that
16:11.15Paliand these hacks were needed for converting structures from that userspace blob which comes from request_firmware to native kernel structures
16:11.27Palivery ugly solution...
16:12.13FatPhilBut 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.26DocScrutinizer05yep
16:12.32FatPhilthe compiler's permitted to allocate those structures in alphabetical order, or in reverse
16:12.44FatPhilThe correct solution is to struct all of the structs together
16:12.47DocScrutinizer05unless it's one large structure
16:12.51Palido not look at that linker hacks...
16:12.57Paliit using lot of perl code
16:13.13FatPhilPerl to generate linker hacks?
16:13.15FatPhilNACK!
16:14.09DocScrutinizer05wtf, nmap the firmware file, set readpointer to offset of data structure and read it in from file to local variable struct
16:16.25FatPhilwell, request firmware is the standard way of getting the data in, there's no problem with that.
16:17.03FatPhilkernel shouldn't filp_open, for example
16:18.39FatPhilI can't really suggest anything - I don't have any et8ek8 here, I presume that's on my home machine.
16:18.48FatPhilgoes home
16:19.02FatPhil(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.25freemangordonPali: arch/arm/mach-omap2/board-rx51-peripherals.c:1272:34: warning: 'rx51_t2scripts_data' defined but not used [-Wunused-variable]
16:31.51freemangordonI guess this is a result from so-called "fix power off/restart problem" or whatever that patch was called
16:32.22Palifreemangordon: yes, ask more Skry
16:32.35Paliyou can ignore that warning
17:10.06*** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172)
17:12.35freemangordonPali: hmm, but, but... this struct is the power management scripts, ain;t?
17:12.59Palifreemangordon: yes, but it causing poweroff problems
17:13.13Palithis needs to be fixed
17:13.18freemangordonok
17:19.25DocScrutinizer05FatPhil: you had a chance to check the part number on N9 PoP?
17:36.14FatPhilDocScrutinizer05: didn't know I was going to do that!
17:36.44FatPhilIsn't that identified in the boot log (although perhaps somewhat cryptically)
17:37.04FatPhilCan't check - don't have n9 jig
17:40.23DocScrutinizer05don't worry, I'll disassemble my N9 then
17:40.57DocScrutinizer05thanks nevertheless
17:44.03DocScrutinizer05ooops, actually I mixed up things (rather persons), sorry
17:46.02DocScrutinizer05and 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.31DocScrutinizer05I 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.56DocScrutinizer05can't reproduce that effect, possibly only "works" after reboot
18:53.44DocScrutinizer05comparing 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.43DocScrutinizer05I'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)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.