10:58 | jnettle | 10:58 * jnettlet found the performance problems with 3.10 after not looking for a day or two. 3.10 has cpu-freq scaling working and it was broken. |
10:59 | jnettlet | :-\ |
11:03 | Wizzup | Silly question, is some support for cuboxes going in mainline? |
11:03 | Wizzup | Silly as in, I haven't been active here for a bit |
11:04 | jnettlet | Wizzup, the original cubox? |
11:04 | Wizzup | jnettlet: both, preferrably |
11:05 | Wizzup | Although I fear for the cubox-i, since it's freescal |
11:05 | Wizzup | e |
11:05 | Wizzup | (or are both?) |
11:05 | jnettlet | Wizzup, _rmk_ has device-tree support for Carrier-1 that should hopefully be in for 3.14 |
11:06 | jnettlet | that will allow basic boot functionality and KMS but not graphics acceleration or VPU. |
11:06 | Wizzup | Cool. |
11:06 | Wizzup | Ah, I don't need vpu/graphics |
11:06 | jnettlet | I believe the same support is already in mainline for the original Cubox |
11:06 | Wizzup | just sata,usb,ethernet |
11:06 | Wizzup | Awesome. |
11:06 | Wizzup | Thanks! |
11:06 | jnettlet | except for KMS that should be in the next release |
11:07 | _rmk_ | KMS on Dove Cubox... the code is there but there's no DT support for it |
11:09 | Wizzup | Now I'll definitely pick up Gentoo on (orig) cubox again. |
11:09 | jnettlet | we should probably release a u-boot update that has a new device-tree |
11:09 | Wizzup | The wiki page seems lonely without me |
11:10 | _rmk_ | it needs my componentised device thing which I've sorted out for imx-drm to have dt support working there |
11:11 | jnettlet | right |
11:12 | jnettlet | _rmk_, I have all your relevant patches ported to the V4 Vivante codebase now. |
11:59 | hste_ | jnettlet: did u fix or just find the broken cpu-freq scaling or just disable it? |
12:23 | jnettlet | hste_, well that is a good question. So it was defaulting to interactive which would load, but then didn't scale the frequency. That is probably due to me running things from an ssh session, but I haven't looked at that. |
12:24 | jnettlet | Then when I selected either performance, or ondemand random crashes would happen on boot. I fixed that problem...pretty trivial |
12:25 | jnettlet | but then I also had to go in because the stupid Ubuntu image has both debian cpufreq init script as well as it's ondemand initscript enabled. Ubuntu's ondemand initscript just looks at the list of governors provided and chooses either interactive or ondemand depending what it finds first. Well it was then finding interactive and resetting my default....grrrrr |
12:26 | jnettlet | But with a kernel fix, and some initscript changes I have the ondemand scaling working properly |
12:36 | hste_ | :) So it was a mixed rootfs problem also |
12:37 | jnettlet | well the kernel was completely broken |
12:38 | jnettlet | do you have 3.10 running on anything you could check on your rootfs. |
12:38 | hste_ | nope only 4.1.0 |
12:39 | hste_ | there isn't uboot supporting dts for gk802 |
12:39 | jnettlet | now performance is fixed for graphics but I am getting corruption using the 3d core |
12:39 | jnettlet | hste_, oh you can just append the dtb to the kernel image for testing. |
12:40 | hste_ | a corruption only on 3.10 ? |
12:41 | jnettlet | yep |
12:41 | jnettlet | could be a change in the dri interface. Need to check that now. |
12:42 | jnettlet | and I broke glesv2. It went from running really well to not running. Never a dull moment. |
12:42 | _rmk_ | :) |
14:57 | MikeSeth | snow in Tel Aviv |
14:57 | MikeSeth | expect Israeli post office to screw you |
14:57 | MikeSeth | (those two statements are unrelated) |
15:30 | xraxor | MikeSeth: really? shit |
15:31 | xraxor | so no hope to receive my i4Pro till next year? this sucks |
17:05 | nikotime | http://www.haaretz.com/news/national/.premium-1.563057 on the tel aviv weather (sorry if already been covered - continuing from the log of this irc). sounds pretty nasty |
18:44 | xraxor | great news, someone have received his cubox-i today :D |
18:44 | xraxor | its on the forum |
18:52 | jnettlet | how does that help me? |
18:52 | jnettlet | :-) just kidding, that is great news. |
18:53 | jnettlet | I am just pissed at Vivante again. |
18:53 | _rmk_ | heh |
18:53 | jnettlet | I have reduced the latency on the driver enough that I have created more races :-( |
18:53 | _rmk_ | why does "vivante" and "races" always seem to go together :p |
18:54 | jnettlet | actually I think _rmk_'s patchset is partially to blame |
18:54 | _rmk_ | that depends what you've done to my patches :) |
18:54 | jnettlet | they are working perfectly. All the event handling is seamless. |
18:55 | jnettlet | and don't worry you will get to review them soon enough. |
18:55 | jnettlet | This has to do with the power handling. A race between the GPU becoming idle and the commit atom decrementing it's lock. |
18:55 | _rmk_ | I think this evening I'll make all the fencing optional (defaulting to off) in my xorg driver |
18:56 | jnettlet | we are processing events so efficiently now that they are processed before the code can exit the commit :-P |
18:57 | jnettlet | processed by the hardware that is. |
18:58 | jnettlet | so poor power management is angry because it said we should be able to suspend but there are still commit atoms ready to go. |
19:05 | _rmk_ | there we go, one xorg driver with batching removed |
19:07 | _rmk_ | fastest to connect and then disconnect? :) |
19:07 | jnettlet | as long as userspace can keep up with the commits |
19:07 | jnettlet | the irc quickdraw |
19:07 | _rmk_ | that doesn't matter... since commit with stall=true should now properly wait for the previously submitted operations to complete before returning |
19:08 | jnettlet | true. |
19:09 | jnettlet | I am thinking if it would help performance. Especially since Xorg loves lots of small little copies and fills. |
19:10 | _rmk_ | well, it means once less GPU operation per batch |
19:10 | _rmk_ | even though it is a single pixel fill :) |
19:13 | jnettlet | If the numbers I have found posted for the gc2000 don't lie, then I have the gc880 running at over 1/3 the performance the gc2000 is doing. which if the hardware is supposed to be 1/4 as fast it is a pretty decent bump |
19:14 | jnettlet | let me amend that....we have the gc880 |
19:14 | jnettlet | :-) |
19:15 | jnettlet | can't wait to test this on the Marvell hardware |
19:15 | jnettle | 19:15 * jnettlet has to go install a new faucet now. |
19:15 | jnettlet | ttyl |
19:15 | _rmk_ | that's the 3d engine, the 2d engine appears to be gc320 if the hex number can be believed |