**** BEGIN LOGGING AT Sat Nov 07 02:59:57 2009 Nov 07 06:40:12 Hello I was wondering where I could find the latest openmoko sdio patches? Nov 07 06:41:01 I would like to patch my kernel for the sdio atheros ar6001 module but I'm having issues with the svn patches Nov 07 07:57:15 Hi all Nov 07 07:58:48 dos1|neo: my idea was to not break installing stuff for mrmoku/unstable while we are still busy building Nov 07 08:05:47 btw /sys/bus/i2c/devices/0-0073/s3c2440-ts/calibration doesn't exist in 2.6.31, what is the replacement? Xorg calibration doesn't work in shr/merge with this new kernel.. Nov 07 08:06:06 * JaMa leaving Nov 07 09:20:59 Arhuaco: i'd like to know how to properly calibrate TS in the new kernel too ;) Nov 07 09:21:27 I can read the source myself of course. But probably you'll explain it better and faster anyway :) Nov 07 09:43:13 heyho Nov 07 10:10:10 hi morphis Nov 07 10:10:16 and bye :) bbl Nov 07 10:40:51 Sup3rkiddo, hi Nov 07 11:26:58 hey, does someone have some scripts to send messages over ssh? or is there some command line interface for messages stuff with inbox etc? Nov 07 11:50:54 naeg: talk? wall? Nov 07 11:52:54 blindcoder: sorry? Nov 07 11:54:25 naeg: answer to your question Nov 07 11:54:30 12:26 < naeg> hey, does someone have some scripts to send messages over ssh? or is there some command line interface for messages stuff with inbox etc? Nov 07 11:56:09 well "answer", you just told me that i am talking to a wall? ;) Nov 07 11:56:53 naeg: no, to use the programs 'talk' or 'wall' Nov 07 12:00:00 blindcoder: got a link? somehow hard to find something called "talk" or "wall" Nov 07 12:07:11 not really all that hard, just google "ssh message talk/wall" Nov 07 12:07:36 there's also talkd, ytalk Nov 07 12:07:46 hi sicu_ Nov 07 12:08:14 oh, you got me wrong. i want to send messages to people ;) Nov 07 12:08:52 hey bumbl =] Nov 07 12:11:55 naeg: try a terminal/text based IM client to one of the major services (like MSN, ICQ, or Google Chat {jabber}) Nov 07 12:12:25 though i might still be off on what it is you want Nov 07 12:13:32 i want to use the short message service(GSM), don't know if it's called this way in english Nov 07 12:14:07 naeg: SMS Nov 07 12:14:50 ah, ok, i wasn't sure if this phrase is used in english too ;) Nov 07 12:15:05 shortcut* Nov 07 12:15:10 naeg: afair it's used in most languages ;) Nov 07 12:15:51 so, do such scripts, or even a ncurses app, exist? Nov 07 12:15:56 SHR: 03seba.dos1 07opimd-utils * r0e7007fff120 10/opimd-resolve: resolve d: fix IndentationError Nov 07 12:16:11 if not, i know what i have to do :) Nov 07 12:16:23 naeg: emacs at least supports sending SMS on openmoko Nov 07 12:16:34 not really a fan of emacs : / Nov 07 12:20:13 SHR: 03seba.dos1 07opimd-utils * refb463eb58bd 10/opimd-messages: messages: fix IndentationError Nov 07 12:35:14 SHR: 03seba.dos1 07opimd-utils * r26adf7a7eddc 10/opimd-notifier: notifier: fix IndentationError Nov 07 12:35:28 TAsn: ping Nov 07 12:35:58 mrmoku, pong. Nov 07 12:36:16 ARM4 is what we have, no? Nov 07 12:36:31 the chip on the moko? yeah. Nov 07 12:37:00 because the article says ARM9 Nov 07 12:37:06 we have ARM9 Nov 07 12:37:13 other than that it's fine for me Nov 07 12:37:15 ahh Nov 07 12:37:19 architecture of ARM9 processor is armv4t Nov 07 12:37:24 oh. Nov 07 12:37:26 ok Nov 07 12:37:29 ok :) Nov 07 12:37:29 then all fine for me :) Nov 07 12:37:34 ;) Nov 07 12:37:39 other than that you are both fine? Nov 07 12:38:03 firstly i have to check about what you're talking Nov 07 12:38:05 ;) Nov 07 12:38:25 raster: ping Nov 07 12:38:33 dos1, sent you an email. Nov 07 12:38:57 TAsn: ok. well, i just woke up, i'm starting browser just ATM :P Nov 07 12:39:18 :) Nov 07 12:41:00 yeah, ok, dos1 is right. ;) Nov 07 12:42:16 dos1: pong Nov 07 12:42:38 raster: i found a weird bug in elementary Nov 07 12:43:00 raster: after clicking on anchor, you can't scroll anymore :P Nov 07 12:43:29 raster: in elementary_test it happens too, on both AnchorBlock and AnchorView tests Nov 07 12:43:31 dos1: yup. Nov 07 12:44:49 whole scroller is blocked and there is no way (or i didn't find it) to unblock it Nov 07 12:46:33 yup Nov 07 13:13:34 TAsn: ok, read article Nov 07 13:13:49 it's ok for me... except that one Freesmartphone.Org... it's ugly :P Nov 07 13:13:56 freesmartphone.org looks much better :D Nov 07 13:14:41 :) Nov 07 13:18:20 * morphis is now trying to boot into his own rootfs on the Palm Pre Nov 07 13:18:38 morphis: .... orly... like how ? Nov 07 13:18:45 hehe :) Nov 07 13:18:54 will that work.... Nov 07 13:18:56 let me first try before I till you how I do this Nov 07 13:19:07 it's very easy Nov 07 13:19:35 just create another partition, put your stuff on it and then change the root-partition to boot in the initrd on /boot on the palm pre Nov 07 13:20:15 ok Nov 07 13:20:26 mrmoku: you added blipomoko to feed before commiting recipe? :x Nov 07 13:21:16 huh? Nov 07 13:21:29 d1b: I am currently trying to build a second stage loader for the pre, so we can choose when starting the pre wether we want to boot SHR/FSO/... or webOS Nov 07 13:21:38 e9f0c25adfbdc9c4dc044df90f23c17155898012 Nov 07 13:21:44 dos1: ^^^ Nov 07 13:21:49 ok. Nov 07 13:21:59 morphis: but does gsm work ... Nov 07 13:22:13 mrmoku: python-blipapi != blipomoko Nov 07 13:22:23 ohh Nov 07 13:22:30 where is the patch for that then? :P Nov 07 13:22:37 python-blipapi is a library which blipomoko uses Nov 07 13:22:56 mrmoku: http://patchwork.dev.bearstech.com/patch/424/ :P Nov 07 13:25:59 hmmm Nov 07 13:32:07 spaetz_: guess mickey is waiting for the chockolate now :P Nov 07 13:40:53 mrmoku|away, yep. he'll get some Nov 07 13:40:58 ;) Nov 07 13:41:57 but there must be a way to abbreviate the branch name locally but still push to org.openembedded.dev branch Nov 07 13:42:34 i don't want to type git checkout org.openembedded.dev all the time to switch... Nov 07 13:45:11 d1b: actually not, but I am working on this too Nov 07 13:46:55 anyone know why I get this http://dpaste.com/117402/ Nov 07 13:53:42 anybody here who has already build lvm2 from oe repository? Nov 07 13:54:08 spaetz: do you have lvm2 in the shr feed? Nov 07 13:54:35 don't think so Nov 07 13:54:39 hm ok Nov 07 13:54:55 but we have lots in the feed i don't know of... Nov 07 13:55:14 no you don't have it in the feed Nov 07 13:55:27 hheck, we have reiserfs stuff ;) Nov 07 13:55:35 k Nov 07 13:56:01 anyone? :P Nov 07 13:57:53 Sup3rkiddo, never seen that Nov 07 13:58:03 spaetz, :/ Nov 07 13:58:21 man, getting that first build running is sooo hard.. Nov 07 13:59:07 Sup3rkiddo, linux-heades 2.6.22 ? do we use that? Nov 07 13:59:58 spaetz, i have no idea, maybe its a dependency... I have been scratchng my head over this one Nov 07 14:01:51 Sup3rkiddo, looks wrong Nov 07 14:01:57 we have this: Nov 07 14:02:22 lemme try running it through the debug flag Nov 07 14:02:36 2.6.29 in http://cgit.openembedded.org/cgit.cgi/openembedded/tree/conf/distro/include/preferred-shr-versions.inc?h=shr/merge Nov 07 14:03:56 hmm.. ok.. taking a look, but I am not using shr/merge branch as it seems to hang in the bitbake parse stage Nov 07 14:11:23 Sup3rkiddo, what did you change in fso? Nov 07 14:11:39 playya_, nothing yet.... :P Nov 07 14:11:56 playya_, i am trying to set a dev environment on my new computer Nov 07 14:12:02 my usual box died on me Nov 07 14:12:14 playya_, hello btw Nov 07 14:12:18 hi Nov 07 14:12:26 tried the shr-makefile? Nov 07 14:12:55 playya_, yeah, seems to hang though.. just one sec Nov 07 14:13:07 works for me Nov 07 14:13:08 letme do a quick switch of branches Nov 07 14:13:47 do you still use the old stuff from fso-makefile? Nov 07 14:14:04 bitbake switch to git, too. maybe it's only a old bug Nov 07 14:14:28 playya_, no no, I have a spanking new tree :D Nov 07 14:38:05 failed packages in task-shr-feed in shr/merge: http://pastebin.com/f309fb32c Nov 07 14:44:12 playya_, hmm, but how long?.. any idea.. have put it for a day now Nov 07 14:47:15 TAsn: oh, i read only our answers in mail before... now i saw whole article :) Nov 07 14:50:45 TAsn: answered to mail ;) Nov 07 14:57:19 Sup3rkiddo, atm i have a slow connection, too. Maybe about an hour? Nov 07 14:57:33 bitbake isn't verbose in this case Nov 07 14:58:45 playya_, hmmm ok Nov 07 14:59:01 * Sup3rkiddo notes that his router isnt' blinking much Nov 07 15:03:12 dos1: logs are on buildhost? Nov 07 15:03:45 JaMa: yup, they should be Nov 07 15:04:09 dos1: navit compiled fine here about 2 days ago.. and I'll send patch for font-misc-misc_1.1.0.bb .. I guess its just do_patch because there is left over patch from older version.. Nov 07 15:06:52 larsc: /sys/bus/i2c/devices/0-0073/s3c2440-ts/calibration doesn't exist in 2.6.31, what is the replacement? Xorg calibration doesn't work in shr/merge with this new kernel.. Nov 07 15:07:15 freesmartphone.org: 03mickey 07cornucopia * rd15ba1f6a610 10/misc-vapi/stuff/libnl.vala: misc: test for improved libnl binding Nov 07 15:13:40 JaMa: /sys/bus/platfrom/devices/s3c2440-ts Nov 07 15:13:43 maybe Nov 07 15:30:44 larsc: hmm also missing there, directory exits but subdirectory calibration is missing and it changed name from s3c2440-ts to s3c2410-ts Nov 07 15:39:28 root@OpenWrt:/sys# find . -name calibration Nov 07 15:39:29 ./class/i2c-adapter/i2c-0/0-0073/s3c2410-ts/calibration Nov 07 15:42:06 hmm I'll recheck my kernel config, because this doesn't exist here too.. using config from arch/configs/arm/gta02-defconfig Nov 07 15:42:51 find /sys -name calibration is empty here.. Nov 07 15:43:31 should be the linear filter Nov 07 15:43:37 which creates that file Nov 07 15:45:59 dos1: navit is in do_fetch.. so no log accessible through tinderbox :/ Nov 07 15:46:04 larsc: so you wanted to tell me all good drivers that need non-trivial irq processing should use "threaded interrupt handlers", right? Nov 07 15:47:07 maybe Nov 07 15:47:52 JaMa: ok, i'll look at navit Nov 07 15:48:07 dos1: font-misc-misc should be ok now.. just clean and build Nov 07 15:48:31 larsc: i meant that's how i got your "for pcf50606 to be accepted upstream it needs to be converted to use genirq". Nov 07 15:49:29 threaded irqs whould be a step in the right direction Nov 07 15:50:42 larsc: does it mean that the next step is to use some generic irq demultiplexing method? Nov 07 15:53:04 yes Nov 07 15:53:18 irq_chip Nov 07 15:54:57 but for threaded irqs we neet IQRF_ONESHOT which is only in 2.6.32 Nov 07 15:57:08 Ok, thanks Nov 07 16:07:54 seems we finally get around fixing messed up IRQ which always felt to me like being fundamentally insane Nov 07 16:10:14 or maybe finally come to business for fixing... Nov 07 16:15:09 DocScrutinizer: are you sure currently pcf506x6 irqs are messed up? I think we agreed button handling was strange but larsc implemented buttons via generic driver now, obsoleting OM-specific driver. Nov 07 16:19:39 PaulFertser: I'm not referring to a particular issue wrt IRQ handling. It just *felt* to me like done without most basic principles in mind Nov 07 16:20:10 spaetz: depends all on your git config Nov 07 16:20:32 I'm coming from uC-development in Assembler. Nov 07 16:21:08 there you inevitably learn how to do IRQ the right way Nov 07 16:21:38 mrmoku, do you have any clue why the mic volume (all upgrades) is alsways set to the lowest possible value? it is kind of annoying to always have to incerease it before putting the phone to my ear (i already overwrite all he alsastates with my cusom ones) Nov 07 16:21:43 at least that's been the case in the 1980s Nov 07 16:22:17 brb Nov 07 16:22:52 DocScrutinizer: hehe, some of the devices designed at my dayjob do not use irqs at all for anything, polling everywhere. Some people never learn... Nov 07 16:23:53 clock of those chips was maybe 1MHz, and you really needed to care about stack depth, IRQ-latency time, and due to the nature of projects you better learned how to avoid any potential race from very beginning Nov 07 16:25:35 nowadays reentrant design is "it's fast enough to finish before next IRQ ever can happen" :-(( Nov 07 16:26:26 DocScrutinizer: there're some cheap parts available currently that support (quite powerful for 8-bit) AVR instruction set but lack RAM completely. Stack for irq handlers/procedures is hardware, 3 entries max. Attiny15 iirc. Nov 07 16:27:00 I know Nov 07 16:27:31 usual kernel devels are totally lost on a platform like that Nov 07 16:28:30 they tend to deny any useful code ever could be implemented on such a chip XD Nov 07 16:41:21 any idea? ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8753.ko] undefined! Nov 07 16:43:01 yayyy Nov 07 16:43:46 snd-soc-wm8753.ko -- a real evergreen XD Nov 07 16:43:57 JaMa, you're doing floating point in the driver. Nov 07 16:44:06 muhaha Nov 07 16:45:10 mwester: I just enabled that option in kernel config :) Nov 07 16:45:39 great idea for S3C2442 Nov 07 16:45:41 mwester: and I would expect to auto enable all remaining needed options Nov 07 16:45:55 Ok, then there's a bug in the kernel. Nov 07 16:46:21 thats not floating point Nov 07 16:46:33 ok, it's long int div Nov 07 16:47:01 JaMa: blame your compiler Nov 07 16:47:49 !curse gcc_4.4.2 Nov 07 16:48:01 anyway, i have to run to catch my train, see you tomorrow Nov 07 16:49:30 longint in a sounddriver seems equally insane as float Nov 07 16:50:15 and enabling float for snd kernel modules is... :-X Nov 07 16:50:59 Well you can't do float at all in the kernel, and you shouldn't do long int math even if it lets you (but I'm not sure it does anyway) Nov 07 16:51:57 Float creeps into some drivers because, of course, the x86 has hw float so it "just works". I've fixed a few of those, and the message you get is very similar to the on JaMA has... Nov 07 16:53:01 * DocScrutinizer suggests using float for timestamps XD Nov 07 16:55:58 let's see... usual audio is u16le, very good AD converters do 24bit. So a 32bit word should yield a 8bit headroom for all audio math at least Nov 07 16:59:41 Arhuaco: hey Nov 07 16:59:52 Arhuaco: good morning ;) Nov 07 17:00:12 Hello PaulFertser :-) Bootstraping here. What's new? Nov 07 17:00:39 Arhuaco: JaMa asked how to properly calibrate TS with .31, i assumed you have the most straightforward answer. Nov 07 17:02:24 PaulFertser: I have always used the default calibration. But I guess you can run the calibration program and replace /etc/tscal.conf (I don't remember the exact name of the file now). Nov 07 17:03:27 PaulFertser: I think I erased this file once and the calibration program ran but I'm not sure now... I just don't remember. Nov 07 17:04:15 PaulFertser: Is that what you were looking for? Nov 07 17:05:14 Arhuaco: so there's no kernel-level calibration anymore? Nov 07 17:05:46 PaulFertser: Ah, we have it also. It might be useful for a boot loader or something. Nov 07 17:06:05 PaulFertser: It's in Andy-tracking. I have a file for that. Let me look it up. (I guess it will never go upstream). Nov 07 17:06:13 Arhuaco: JaMa couldn't find the sysfs files for it in .31. Nov 07 17:06:25 Arhuaco: so probably he shouldn't try even. Nov 07 17:06:57 PaulFertser: This is the program I used: http://svn.arhuaco.org/svn/src/openmoko/touchscreen/set-cal.py Nov 07 17:07:49 PaulFertser: Oh, I see. Nov 07 17:08:20 PaulFertser: Let me boot 2.6.31 to check. Nov 07 17:08:54 mwester: problem seems to be caused by poor math education nowadays, due to cheap electronic calculators at school. 1/3 + 1/3 != 0.6666 Nov 07 17:09:34 mwester: as it's so fsckng "complicated" to get correct results using int math, coders tend to use float I guess Nov 07 17:10:52 DocScrutinizer: I was amazed to see that some cheap calculators now use fractions by default! Nov 07 17:13:56 SHR: 03piotr 07shr-themes * r1541a8297484 10/e-wm/e-wm-illume-dict-pl/Polish.dic: e-wm-illume-dict-pl: update Nov 07 17:15:11 Arhuaco: they made that mandatory for educational purpose calculators when first space vessels crashed due to float instead of proper int being used in nav systems XD Nov 07 17:16:21 DocScrutinizer: :-) Nov 07 17:16:23 PaulFertser, Arhuaco: problem with sysfs files was because ts is disabled in gta02_defconfig and linear filter too Nov 07 17:16:49 Arhuaco: now they consider to talk ntel into implementing fraction int math into their math coprocessors ;-) Nov 07 17:17:15 JaMa: Easy to fix.... Nov 07 17:17:41 DocScrutinizer: Are you kidding? I guess so :-P Nov 07 17:18:43 Arhuaco: sure.. I just need to rebuild twice because I also enabled sound while modifiing config and ended with ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8753.ko] undefined! Nov 07 17:18:59 btw you kernel gurus are using phone without snd module? Nov 07 17:21:25 JaMa: I've only used the newer kernel for tests. I could not build support for GTA02 audio chip in upstream but I did not debug much. Nov 07 17:23:31 * DocScrutinizer wonders wtf might have been wrong with the audio kernel driver as of Aug-08 (except the known annoying bugs and flaws) Nov 07 17:26:30 JaMa: last time i built kernel it was with CONFIG_SND_S3C24XX_SOC_NEO1973_WM8753=m Nov 07 17:26:52 JaMa: and folks with gta01 confirmed sound is working for them with the same driver. Nov 07 17:27:01 And yes, driver is now unified. Nov 07 17:28:04 Arhuaco: btw, did you finally agree with RMK's reasoning that in-kernel TS filters are bad and if you need to dynamically adjust adc rate then a kernel interface for that should be introduced and everything else can be done in userland then. Nov 07 17:28:57 PaulFertser: Yes, but don't tell anyone. :-P Nov 07 17:29:30 Arhuaco: ts works ok now .. (when enabled in kernel as well as linear filters) :) Nov 07 17:31:24 Arhuaco: sure :) Nov 07 17:32:32 PaulFertser: We have to send a lot more points to userspace... Nov 07 17:32:40 JaMa: Good. Nov 07 17:33:52 Arhuaco: me, kidding?? NEVER! ;-) The datatype format is already ISO-standardized: ppppsxxx[x*p]yyyy[y*(16-p)] expanding to (sign:1)xxx/y[24] ... (sign:1)x[19]/y[8] depending on partitioning of pppp Nov 07 17:35:52 DocScrutinizer: Mmm. I didn't know. Nice then. I think I implemented naive fraction in math once (not packing bytes). I didn't understand your spec :-P I'll have to read about it. Nov 07 17:36:04 PaulFertser: and any hint for __aeabi_uldivmod? larsc had time just to say its gcc problem.. but I have no idea, do I need 4.3* or something? try to change CFLAGS? Nov 07 17:37:27 JaMa: i'd not say so Nov 07 17:37:35 Arhuaco: A hoax! Of course I'm kidding - at least I *hope* I am Nov 07 17:37:43 JaMa: kernel doesn't require the compiler to provide _any_ function. Nov 07 17:38:03 JaMa: all aux helpers should be provided from the kernel source. Nov 07 17:39:09 Arhuaco: though could be real fun to write the microcode for the ALU to handle that datatype ;-D Nov 07 17:39:15 DocScrutinizer: :-) It's a clever hoax. Nov 07 17:39:50 DocScrutinizer: Specially if you use 128-bit registers (sharing space with SSE code or something). Nov 07 17:40:09 JaMa: but apparently this particular function shouldn't be used, no idea why your gcc emits a reference, probably you might want to look at asm listing. Nov 07 17:41:19 JaMa: gcc 4.1.2 here Nov 07 17:41:23 Arhuaco: I was planing to use 64bit for my above fake datatype. But I was too lazy to count all the sizes then to make a reasonable format ;-) Nov 07 17:42:12 DocScrutinizer: Wait until April first and write something nice :-) Nov 07 17:42:21 PaulFertser: ok, I'll try in old shr/import where is 4.1.2 Nov 07 17:42:49 sth like ppppppsxxxxxxx[x*p-48]/yyy... errks Nov 07 17:43:14 DocScrutinizer: Here the day for that is December 28. I always make jokes on April 1st but nobody gets them. Thus I have to make them on the internet. Nov 07 17:43:58 JaMa: it'd be more interesting to tell for what particular place does you compiler emit that reference. Nov 07 17:46:26 somewhere inside a malformed math expression where a intermediate result exceeds standard int range, I guess Nov 07 17:47:34 DocScrutinizer: implicit type casting should be predictable enough and if it really fails on some expression, that expression must be fixed obviously. Nov 07 17:48:18 sure Nov 07 17:49:07 PaulFertser: mmt building now with both gccs Nov 07 17:49:08 int_c = int_a * int_b / MAXINT Nov 07 17:49:49 * Arhuaco will hunt lunch. BBL. Nov 07 17:49:58 same here Nov 07 17:50:54 JaMa, check for bad stuff creeping in via macro defs. Nov 07 17:52:21 btw built ok with gcc_4.1.2 Nov 07 17:54:04 JaMa: so now you have an excellent opportunity to report a bug ;) Nov 07 17:54:36 PaulFertser: gcc bug or kernel bug? ;) Nov 07 17:55:07 JaMa: OM driver bug Nov 07 17:55:59 btw binaries here.. http://jama.homelinux.org/org.openembedded.shr/codecs/ Nov 07 17:58:26 * Copyright 2003 Wolfson Microelectronics PLC. * Author: Liam Girdwood Nov 07 17:58:27 snd-soc-wm8753.ko using a math expression not compatible with gcc_4.4.2. For a decent bug report it needs to spot the particular expression though Nov 07 17:58:47 hmm I've seen some lrg guy in #oe is it him? Nov 07 18:00:07 JaMa: most probably yes Nov 07 18:00:26 I'd try #alsa-soc though there's mo liam girdwood there Nov 07 18:00:31 JaMa: but i think neither him nor broonie are interested in fixing the driver themselves. Nov 07 18:00:44 s( mo/ no/ Nov 07 18:00:58 you bet Nov 07 18:01:28 JaMa: just provide asm listing for the code in question, objdump should do that Nov 07 18:02:38 err, I always thought gcc can create a asm intermediate listing Nov 07 18:02:53 DocScrutinizer: that way it works too but one'd need to modify Makefile etc Nov 07 18:03:04 nicely interleaved with c srclines Nov 07 18:03:38 it looks like lines 710,712 in wm8753.c Nov 07 18:04:08 could you just paste the 3 lines here please? Nov 07 18:05:44 sure.. mmt testing if it compiles without htem Nov 07 18:05:45 or URL to some html-git or the like Nov 07 18:06:08 yes.. it compiles fine Nov 07 18:06:15 (no local srctree here) Nov 07 18:07:02 #define FIXED_PLL_SIZE ((1 << 22) * 10) Nov 07 18:07:04 Kpart = FIXED_PLL_SIZE * (long long)Nmod; Nov 07 18:07:13 do_div(Kpart, source); Nov 07 18:07:22 fiiiiiishy Nov 07 18:07:34 whole file http://jama.homelinux.org/org.openembedded.shr/codecs/wm8753.c Nov 07 18:07:42 thanks Nov 07 18:08:47 kpart = ((1 << 22) * 10) * (long long)Nmod; Nov 07 18:08:52 ouch Nov 07 18:09:03 uldivmod? Nov 07 18:09:36 do_div Nov 07 18:10:18 whole file http://jama.homelinux.org/org.openembedded.shr/codecs/div64.h Nov 07 18:10:37 there is do_div Nov 07 18:10:43 The same code is in wm9713 which is pretty recent and maintained i think. Nov 07 18:11:13 JaMa: asm listing would be more helpful Nov 07 18:11:18 PaulFertser: grep -R uldivmod for whole tree returns just 2 files *wm8753.o Nov 07 18:11:23 mmt Nov 07 18:12:54 wm8753.o.asm same url Nov 07 18:13:56 sorry mmt Nov 07 18:14:00 its still commented out.. Nov 07 18:14:55 * gcc versions earlier than 4.0 are simply too problematic for the Nov 07 18:14:57 * optimized implementation below. First there is gcc PR 15089 that Nov 07 18:14:58 * tend to trig on more complex constructs, spurious .global __udivsi3 Nov 07 18:14:59 * are inserted even if none of those symbols are referenced in the Nov 07 18:15:01 * generated code, and those gcc versions are not able to do constant Nov 07 18:15:03 * propagation on long long values anyway. Nov 07 18:16:02 asm regenerated Nov 07 18:16:11 that's the result of "optimizing" c source instead of just inline assembler :-( Nov 07 18:18:09 nah, need dinner before this mess has any impact on my mood Nov 07 18:18:12 cya Nov 07 18:19:09 JaMa: __aeabi_uidivmod , not __aeabi_uldivmod ? Nov 07 18:19:45 PaulFertser: __aeabi_uldivmod but its only in .o not in asm :/ Nov 07 18:19:48 JaMa: did you reupload the new file? Nov 07 18:19:53 yes Nov 07 18:19:55 JaMa: weird Nov 07 18:20:09 can binutils optimize somehow? Nov 07 18:20:18 someone testes new images? Nov 07 18:20:34 grep -R in same dir where .o are and .asm returns still .o Nov 07 18:21:00 so its in .o for sure.. and recalling objdump -d returns it without Nov 07 18:21:24 I guess that kernel has thumb off Nov 07 18:22:10 JaMa: (objdump optimize out) i doubt that. What a wondeful riddle you have there :) Nov 07 18:22:25 JaMa: probably i want to install your gcc version just to enjoy it myself Nov 07 18:23:12 PaulFertser: I was thinking about ld optimizations not objdump :) Nov 07 18:23:23 #define do_div(n, base) is a real beauty XD Nov 07 18:23:46 JaMa: you say you have .o which calls it. And you say you disassemble it and there's no function like that mentioned. That's strange. Nov 07 18:23:59 PaulFertser: sure Nov 07 18:24:32 and I had only 1,5 beer so no kidding Nov 07 18:24:40 hehe, highly optinized Nov 07 18:25:22 rarely ever seen such a mess, honestly Nov 07 18:25:45 JaMa: share the binary :D Nov 07 18:25:55 PaulFertser: its all there.. Nov 07 18:26:05 create a decent gcc intermediate asm listing Nov 07 18:26:09 Yo Nov 07 18:29:23 PaulFertser: an old modula compiler created a 30k entries jumptable with 30k-2 jumps to runtime error out of a "case i; 1:foo; 30000:bar; endcase" ;-D Nov 07 18:31:19 I only got to learn this from intermediate asm listing, as the only adverse effect was the resulting binary was too large for the max 64k of program text I had on this machine Nov 07 18:32:51 err s/modula/pascal/ Nov 07 18:34:31 DocScrutinizer: a decent example of optimisation :D Nov 07 18:34:40 yep - lol Nov 07 18:35:20 also a good example of the benefit of intermediate asm listings Nov 07 18:36:50 the nasty part was the compiler simply segfaulted somewhere later when code space got used up, so the intermediate listing had to be printed to lineprinter in realtime to even get it Nov 07 18:38:43 well probably not exactly segfaulted but more like "runtime error in line ??????: array out of bounds" or sth like that Nov 07 18:40:59 JaMa: hehe, googling is better than me in investigating: http://article.gmane.org/gmane.linux.ports.arm.kernel/39915 Nov 07 18:41:27 PaulFertser: http://jama.homelinux.org/org.openembedded.shr/codecs/wm8753.S Nov 07 18:42:09 JaMa: looks like it emits the reference but then optimizes it out Nov 07 18:42:56 nice catch Mr. PaulFertser! Nov 07 18:43:41 that should be enough for decent bug report, no? :) Nov 07 18:43:42 excuse me where i can download last images of SHR? Nov 07 18:44:10 JaMa: a really decent would be the one with the latest gcc i'm afraid :( Nov 07 18:44:15 mwester: thanks :) Nov 07 18:44:52 PaulFertser: latest from trunk or 4.4. branch? Nov 07 18:45:18 JaMa: i guess from trunk since it's something people are actively working on. Nov 07 18:46:07 diff from 4.4. branch could be easy to check and test.. but I guess that with stage0 4.5 trunk I won't go that far to build snd modules :) Nov 07 18:46:17 but I'll try .. maybe later Nov 07 18:46:48 any idea how to workaround this now? (other then removing it manually? Nov 07 18:46:55 JaMa: what's cool about it is that to compile the kernel you do not need the whole toolchain, i.e. libc. Nov 07 18:47:04 Date: 2008-03-25 18:05:30 GMT (1 year, 32 weeks, 2 days, 18 hours and 35 minutes ago) -- amazing Nov 07 18:49:13 DocScrutinizer: do you know where are last SHR images? Nov 07 18:49:30 PaulFertser: hmm another idea, did something change in that driver between 2.6.28 and 2.6.31? I can check.. but 2.6.28 compiles fine with this gcc... Nov 07 18:49:48 PaulFertser: and I guess we have snd module enabled there :) Nov 07 18:49:54 pbaxter: sorry, I'm not even aware what's common notion about "latest" for SHR Nov 07 18:50:19 JaMa: do_div looks extremely tricky :( Nov 07 18:50:39 #define do_div(n, base) is a real beauty XD Nov 07 18:50:58 pbaxter: latest greatest, in need for testing http://build.shr-project.org/tests/mrmoku/oemerge/images/om-gta02/ Nov 07 18:51:00 [2009-11-07 19:14:52] * gcc versions earlier than 4.0 are simply too problematic for the Nov 07 18:51:07 [2009-11-07 19:16:08] that's the result of "optimizing" c source instead of just inline assembler :-( Nov 07 18:51:11 thanks JaMa Nov 07 18:52:15 I'll unpack 2.6.28 tree just for diff.. Nov 07 18:52:32 maybe there is less optimized version which works ok for us Nov 07 18:54:29 hmm arm/include/asm/div64.h is the same in andy-tracking Nov 07 18:55:24 tbh Nov 07 18:55:28 Kpart = FIXED_PLL_SIZE * (long long)Nmod; Nov 07 18:55:29 do_div(Kpart, source); Nov 07 18:55:31 K = Kpart & 0xFFFFFFFF; Nov 07 18:55:44 looks like rather poor code to me Nov 07 18:56:05 wm8753.c changed but do_div is still the same Nov 07 18:56:14 * JaMa agree Nov 07 18:57:00 Nmod and K are uint Nov 07 18:57:25 source as well Nov 07 18:58:10 to me it seems you should be able to do that math without any u64 which in turn needs do_div() Nov 07 18:58:59 but now for real: bbl Nov 07 19:00:39 dos1, too late, already sent that. :) Nov 07 19:06:24 hehe found an workaround.. its source param in do_div.. if its u64 than its ok for gcc.. Nov 07 19:07:17 JaMa: u64? Getting casted back to uint32_t ? Nov 07 19:08:02 Kpart is u64 if I use u64 instead of original source than do_div is ok again Nov 07 19:08:31 not sure how is u32/u64 related to unsigned int here Nov 07 19:08:52 JaMa: hm, interesting uint32_t do_div(uint64_t *n, uint32_t base) Nov 07 19:08:54 *n ? Nov 07 19:13:23 PaulFertser: ahh thats even worse... if I use same logic as the patch you linked then I get more uldivmod (for every usage of source variable before do_div) Nov 07 19:14:00 JaMa: i mean is the comment in the header wrong? The code doesn't seem to use a pointer to uint64_t for the first parameter. Nov 07 19:22:28 PaulFertser: I have no idea what PLLs are.. but I guess its typo in header.. Nov 07 19:23:03 JaMa: PLLs are basically devices that allow you to derive a higher frequency clock from a lower frequency generator. Nov 07 19:23:50 PaulFertser: would be interesting to get a lecture on that kind of electronics stuff :) Nov 07 19:23:51 JaMa: so do you cast the first macro argument to u64 or the second for a workaround? Nov 07 19:24:06 yep, and they need a divider for source clock, and a divider for generated clock Nov 07 19:24:13 lindi-: it's out of my area of competence unfortunately. Neither i heard such a lecture at my university :( Nov 07 19:24:35