| 01:42 | _rmk_ | btw, I put v3.13-rc3 for carrier-1 up today |
| 01:44 | _rmk_ | rabeeh: is the naming contest all done? |
| 03:53 | NetScr1be | ne1 home? |
| 03:53 | NetScr1be | any wisdom on getting sensors working in debian headless? |
| 09:07 | jnettlet | dv_, sorry I missed the conversation last night. Did you get the iwmmxt compilation sorted? |
| 09:07 | jnettlet | Also I just cleaned up another part of the v4 driver that resulted in a 12% performance increase |
| 10:28 | hste_ | jnettlet: how is perfomance on v4 now compared to 4.1.0? |
| 10:33 | jnettlet | hste_, performance under 3.10 is still down from 3.0.35 |
| 10:33 | jnettlet | I am sure there is one big stupid thing happening and once I fix that I am hoping to really see things fly. |
| 10:34 | jnettlet | From where I started with the current Vivante driver in the IMX kernels I am at about 30% improvements. I guess I could backport it to 3.0.35 to see where I am there. |
| 10:36 | hste_ | jnettlet: If its not a big job backporting it, it would be a nice way to meassure the performance tweeks you do :) |
| 10:37 | jnettlet | well I am not really doing performance tweaks. I am fixing things that are really broken that just help performance :-) |
| 10:37 | hste_ | :) |
| 10:37 | jnettlet | A lot of it is just doing things the proper linux way instead of this generic OS abstraction way. |
| 10:56 | jnettlet | hste_, just ran gtkperf on 3.0.35 with my new driver changes and I cut the run by 50% |
| 10:56 | jnettlet | gtkperf now takes 20secs to complete!!! |
| 11:04 | bnilsen | Do any of you happen to know anything about power management on linux related to imx6 chip? It seems that with 3.12 none of my wakeup sources are able to wake up the system |
| 11:07 | bnilsen | I'm tempted to think it is either related to dts or a lacking wakeup bit in the configuration. Problem is to where one should start looking |
| 11:10 | hste_ | jnettlet: very nice :) do u have a git where you have 3.0.35 with your changes or a diff ? |
| 11:11 | jnettlet | hste_, oh I just hacked it in. I still need to do some more testing. |
| 11:11 | jnettlet | running under an xfce gtkperf drops to 28 secs, but still a big improvement over 40 |
| 11:12 | jnettlet | still need to test 3d. |
| 11:12 | hste_ | jnettlet: what about heat/power consumption. Does it get hotter do u think? |
| 11:13 | jnettlet | oh crap that is right. I forgot I had turned compositing on xfce, That used to run at 50 or 60 seconds for gtkperf. Now I am down to 28 |
| 11:13 | jnettlet | bam that is huge |
| 11:15 | jnettlet | hste_, I still need to test those things. I have improved some efficiencies where before the chip would go to sleep and then wake right back up resulting in a bunch of work. |
| 11:15 | jnettlet | I have also fixed up some stupid interrupt handling which I think is helping with the performance. I need to check though if the spinlock I added is actually causing the CPU to clock up more. |
| 11:16 | jnettlet | but even XRender composited the XFCE desktop is really fast. |
| 11:16 | hste_ | jnettlet: Ii think u don't need worry about cpu, its the change on gpu that could be a problem.. |
| 11:17 | jnettlet | that is some of the testing I will need to do. |
| 11:18 | hste_ | jnettlet: but the work you have done looks really promising :) |
| 11:20 | hste_ | jnettlet: hopefully u'll find the bootleneck for 3.10 |
| 12:03 | _rmk | 12:03 * _rmk_ prods RobClark |
| 12:33 | dv_ | jnettlet: do you have patches for meta-cubox? for gcc 4.8 and -mtune=marvell-pj4 ? |
| 13:14 | unununium_ | jnettlet: Although I was not here for quite I while, I'm still interested and that's why I'm asking: Did you have any success with the graphics card for the CuBox? |
| 13:20 | robclar | 13:20 * robclark rubs sleep out of eyes.. |
| 13:20 | robclark | _rmk_, hrm? |
| 13:25 | _rmk_ | just wondering if my four armada fix patches made it through the spam filters |
| 13:31 | robclark | _rmk_, yeah, ones you sent y'day? |
| 13:34 | _rmk_ | Sunday evening/night for me :) yea. |
| 13:34 | robclark | hmm, are you subscribed to dri-devel? If so you shouldn't end up in moderation queue.. |
| 13:35 | _rmk_ | I'm not... I wouldn't have time to read it if I were :p |
| 13:37 | robclark | that is what mail filters are for ;-) |
| 13:37 | robclark | esp. at least filter out all the bugzilla emails to different folder |
| 13:52 | _rmk_ | robclark: I'm just getting rather graunchy with the amount of time it takes to get fixes upstream... I've just waited a month for someone elses one-liner to get into the usb gadget code which allegedly fixes all the build problems... umm no, it only fixes some of the build problems, so here we go around the loop again. |
| 13:52 | _rmk_ | ... of rmk reporting the bug to the author of the original patch which produced the problems... |
| 13:53 | _rmk_ | its times like this when I get to the point of thinking "fuck it, I'm going to patch it up and send the fix in my git tree irrespective of normal process, because normal process is broken" |
| 13:53 | robclark | _rmk_, drop "RFC" from the subject, and send as a pull-req for 3.13.. with RFC in the subject Dave isn't going to pull it into drm-next or drm-fixes |
| 13:54 | robclark | otherwise he will assume it is stuff you are lining up for 3.14 |
| 13:54 | _rmk_ | robclark: ok, you're happy with the changes? |
| 13:54 | robclark | _rmk_, btw, the patches look fine, feel free to add my r-b |
| 13:54 | robclark | yeah |
| 13:54 | _rmk_ | that's what I was after :) The rfc was just to stop them being applied as patches rather than being pulled |
| 13:55 | robclark | ahh, gotcha, I was wondering why they were RFC |
| 13:56 | robclark | oh, I didn't even noticed your 0/4 where you ask me to review 'em |
| 13:56 | _rmk_ | the cubox primerily runs 3.12 when I'm fiddling around with userspace, so I like to keep fixes based on or before that version :) |
| 13:57 | robclark | _rmk_, btw, probably a good idea if stuff to dri-devel that you want me to specifically look at, go ahead and ping me on IRC.. otherwise it might get buried in dri-devel folder ;-) |
| 13:57 | robclark | heh, well at least 3.12 is better than this shit 3.4 android kernel I have on some of my other boards :-( |
| 14:01 | _rmk_ | robclark: okay, will do... looking forward to v3.13 when I lose some patches from my cubox tree :) |
| 14:02 | robclark | :-) |
| 14:03 | jnettlet | dv_, that whole project got held up by a bug in something and I can't for the life of me remember what it is. |
| 14:03 | jnettlet | I have notes for that project somewhere I will dig them out. |
| 14:03 | _rmk_ | robclark: thanks for the r-b email |
| 14:04 | robclark | np |
| 14:04 | jnettlet | unununium_, I am still working through patches. Just made a big performance gain yesterday/today. |
| 14:49 | unununium_ | jnettlet: That's great! :D I'm very happy to hear that! :) |
| 15:33 | dv_ | jnettlet: was the bug something with eglibc perhaps? |
| 15:37 | jnettlet | dv_, that was one of them, but I think they pulled in the upstream patch from glibc to fix that. |
| 15:49 | dv_ | jnettlet: with these flags, eglibc build breaks |
| 15:49 | dv_ | I will now just try -mfpu=vfpv3-d16 -march=marvell-pj4 |
| 16:13 | jnettlet | dv_, I don't use the march= flag. I have -mcpu=iwmmxt2 -mtune=marvell-pj4 -mfpu=vfpv3-d16 |
| 16:14 | dv_ | I tried that, and eglibc build failed |
| 16:14 | dv_ | I am now trying -march=armv7-a -mfpu=vfpv3-d16 -mtune=marvell-pj4 |
| 16:14 | jnettlet | I see what I got bogged down in and then distracted. I was re-adding the iwmmxt code that got removed from libav |
| 16:14 | dv_ | during eglibc compilation an ICE happens |
| 16:15 | dv_ | also, I found this XBMC patch: http://www.xilka.com/xilka/source/patches/06-Xbmc-Configure-platform-Marvell-Dove-20130427.patch |
| 16:15 | dv_ | (this is all actually just preparation for including the kernel and vmeta work you guys did) |
| 16:16 | jnettlet | dv_, oh I know that regression. That happened in 4.8.1 |
| 16:17 | jnettlet | I got cc'd on an email because I am in the iwmmxt gcc patch loop |
| 16:17 | jnettlet | dv_, there are backported patches you need |
| 16:18 | jnettlet | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57735 |
| 16:32 | dv_ | jnettlet: ok, it seems this wasnt pulled in in yocto yet |
| 16:32 | dv_ | I'll stick with -march=armv7-a -mfpu=vfpv3-d16 -mtune=marvell-pj4 for the time being, since eglibc builds just fine with it |
| 16:36 | jnettlet | chicken :-P |
| 16:38 | dv_ | pff :P |
| 16:38 | dv_ | I need to keep this layer usable by others as well |
| 16:41 | jnettlet | well then you don't need the libav and libvp8 iwmmxt support patches |
| 16:41 | dv_ | huh? sure I do |
| 16:41 | dv_ | as long as I dont have to patch gcc |
| 16:41 | dv_ | (patching gcc in a BSP layer is a very bad idea) |
| 16:42 | dv_ | speaking of patches and versions: currently, meta-cubox uses kernel 3.6.9 . can I use your 3.10 kernel ? |
| 16:47 | jnettlet | dv_, I think you should stick with 3.6.9 a bit longer. I think I will drop ION for bmm and all dmabuf support. |
| 16:48 | jnettlet | just trying to work on the unification a bit more. |
| 16:49 | _rmk_ | yea, I need to push out the vmeta bit too |
| 16:49 | _rmk_ | but I'm distracted with omap stuff atm :( |
| 16:57 | dv_ | the bizarre part about these gcc flags is that gcc 4.8 supports -march=marvell-pj4 and -mcpu=marvell-pj4 according to the release notes, but when I try to built it, it just tells me these are not valid cpu architectures |
| 16:58 | dv_ | it could also be a yocto specific thing.. who knows. |
| 17:39 | Wizzup | the links on this page are wrong: http://solid-run.com/store/products/1-cubox-miniature-computer |
| 17:39 | Wizzup | (links to the shops) |
| 17:39 | Wizzup | the eu one links to the aus one |
| 17:39 | Wizzup | and the aus one it mostly a dead ink |
| 17:52 | hste | jnettlet,dv_: Have u seen this patch http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.0.35_4.1.0&id=4dcd0c3746c0125b6f78145f75352b32c05b4674 |
| 17:55 | jnettlet | I have not. I haven't done a git pull in a bit. |
| 17:55 | jnettlet | thanks for the heads up. |
| 18:02 | hste | jnettlet: yes it was some patchec added 7 days ago |
| 18:11 | _rmk_ | oh for fuck sake. yes, really fuck sake. |
| 18:12 | _rmk_ | I've just looked at that commit |
| 18:12 | _rmk_ | typical venduh code |
| 18:12 | _rmk_ | fscking broken |
| 18:12 | Wizzup | wow, the cubox-i base versions are cheap -- interesting |
| 18:12 | _rmk_ | what circumstances can wait_event_interruptible() return? |
| 18:12 | Wizzup | the cubox suddenly because a lot more interesting for my purposes... |
| 18:13 | Wizzup | too bad there isn't a single core one with sata, though |
| 18:13 | _rmk_ | 1. when the waited for condition becomes true and the wait queue is activated. |
| 18:13 | _rmk_ | 2. a signal is received |
| 18:13 | _rmk_ | it returns a code to tell you which one of these events happened |
| 18:13 | hste | rmk: projectgus had a patch for this long time ago https://github.com/imx6-dongle/linux-imx/commit/b8a4b014ead3840271b00948b4970051b13e4ff2 |
| 18:14 | _rmk_ | if (2), it returns an error number which MUST be propagated back and the operation _restarted_ |
| 18:14 | purch | what you use as first sector of the first partition on SD cards? |
| 18:15 | purch | 2048, 4096 or 8192? |
| 19:03 | lycanthropist_ | purch: Given a sector size of 512 bytes: 2048 (1 MiB) |
| 21:17 | jnettlet | hste, okay I got a bit ahead of myself. I forgot my 3.0.35 test server had some things changed in the xorg.conf that added up to some of performance bump. Regardless after putting that back to normal I am still seeing a 25% performance bump. For some reason drm stopped working so I need to sort that out before I do more 3d testing. |
| 21:18 | jnettlet | software rendered glxgears has gone from 50fps to 70fps |
| 21:19 | hste | :) |
| 21:20 | jnettlet | actually it is averaging about 75 right now. So I am getting a 50% speed up in some instances. |
| 21:22 | dv_ | Wizzup: you can always buy a dual core one and shut off one core :) |
| 21:23 | dv_ | aargh |
| 21:23 | dv_ | messed up yocto build dir |
| 21:23 | dv_ | have to rebuild it from start :/ |
| 21:24 | Wizzup | dv_: Yes, but money matters, hehe |
| 21:24 | Wizzup | Cubieboard is still my fav atm |
| 21:24 | Wizzup | dv_: I want to use them in orders or 100's |
| 21:24 | Wizzup | So then suddenly that matters quite a bit |
| 21:24 | dv_ | hm i see |
| 21:24 | dv_ | perhaps you can cut a deal with solidrun? |
| 21:25 | Wizzup | Possibly, I'll play around with my old, first gen cubox first |
| 21:34 | xraxor | Wizzup: what cubieboard you have? why do you like it better? |
| 21:36 | Wizzup | xraxor: Like I mentioned, price plays a large role. cubieboard is good stuff for the buck, cubox felt a bit overpriced usually, but the cubox-i seems nicer |
| 21:36 | Wizzup | It's just that I probably need esata |
| 21:36 | Wizzup | xraxor: I have both cubie and cubie2 |
| 21:37 | xraxor | thanks. specs wise the cubietruck same around same price as i4pro |
| 21:37 | xraxor | I did almost but a cubietruck |
| 21:38 | xraxor | *buy |
| 21:38 | xraxor | yea the original cubox was prob too expensive |
| 22:23 | _rmk_ | ok, that's the fixes to armada drm sent to airlied |
| 23:38 | dv_ | otavio: something is wrong with the linux-imx yocto recipes |
| 23:38 | dv_ | I cannot fetch the kernel |
| 23:40 | dv_ | also, why does bitbake try to do git fetch and download a 750M tarball with wget at the same time? |