| 00:08 | sraue | "please notice that LK 3.14.x is now hosted and moved to SolidRun github repo" so thats the one we should use now? |
| 00:21 | rabeeh | sraue: yes |
| 00:21 | rabeeh | the non working items for now are - pcie, analog audio, broken cec, lvds out |
| 00:21 | rabeeh | sraue: i think the most important one to focus on is proper cec support |
| 00:35 | sraue | pcie is used for what on cubox? |
| 00:35 | sraue | just tried mk01_'s PR for CEC to the kernel and his patches for libCEC but with this i dont have luck too |
| 00:37 | rabeeh | pcie is for HummingBoard (pci express cards) |
| 00:38 | sraue | ah ok |
| 00:38 | mk01_ | sraue: you don't have luck what |
| 00:38 | sraue | with getting CEC to work with kernel 3.14 |
| 00:39 | mk01_ | and what should be indication to luck |
| 00:39 | mk01_ | to no luck |
| 00:40 | mk01_ | comparing to 3.10.30 there was just one change affecting cec from jnettlet patches |
| 00:40 | mk01_ | force stop and force start |
| 00:40 | mk01_ | if kernel things he is going dvi |
| 00:41 | sraue | i tried with https://github.com/linux4kix/linux-linaro-stable-mx6/pull/14 now |
| 00:41 | mk01_ | yup and what you get |
| 00:43 | sraue | ha... wait... had restarted xbmc and now it works, so it dont works on first start, needs a xbmc restart |
| 00:46 | sraue | mk01_, could you cleanup your libcec branch, and maybe create a new one only with the imx6 patches and PR this to pulseeights libcec, i will speak with opdenkam to merge this in official libcec |
| 00:47 | mk01_ | didn't start or didn't get ActiveSource (if before that it already was) ? |
| 00:48 | sraue | now after a restart it works... cant show you you the error i got before actually |
| 00:52 | sraue | great, works now the 4th time after reboots |
| 00:54 | rabeeh | \o/ |
| 00:54 | mk01_ | sraue: the "critical" points for imx6 are hotplug events going together with cec startup - so if you want to test maybe with other TVs then set XBMC to turning on/off with xbmc / screensaver. |
| 00:56 | sraue | ok, will test another tv tomorrow... but they are both samsung |
| 00:56 | mk01_ | sraue: samsungs are polite |
| 00:56 | mk01_ | also don't have anything els |
| 00:56 | mk01_ | else |
| 00:57 | mk01_ | you should send imx6 board to popcornmix, he has LGs and sony ;) |
| 00:57 | sraue | 2 months ago i still had a sony... |
| 00:57 | sraue | popcornmix dont care about something different then RPi |
| 00:57 | mk01_ | I was just ugly way funny |
| 00:58 | sraue | na... it would be nice to convert him... he does a great job with RPi and XBMC |
| 01:00 | mk01_ | yes. indeed. btw: I can send the imx6 to odencamp but is some kind of busy - we just got him for shortly regarding the RPI repatch and then he disappeared again. |
| 01:01 | mk01_ | then there the general libcec fixes and + imx6 |
| 01:01 | mk01_ | click the pull button is least problem |
| 01:04 | sraue | i know he is busy, i will speak with him if i see him. i would do seperate PRs for libcec's core, the RPi patches you have and the imx6 support patches, they should be simple and easy to review... he often cant test byself and changes in libcec's core byself should be avoided if possible |
| 01:18 | mk01_ | it is already splitted and special branch rpi-fixes is with him. all other is imx6. beside two general code pure fixes. nothing new introduced or workflows altered. it is already complicated quite enough. |
| 01:19 | mk01_ | discuss with him, I just will Squash the imx6 into one or two commits |
| 01:20 | sraue | ok, great |
| 01:20 | sraue | yeah squashing makes sense too, will this also work without the " two general code pure fixes" ? |
| 01:22 | mk01_ | that repo is just for pulse eith. all incremental patches are in clone of wolfgar's libcec because there I stated - so I will create new branch in this one, cherry pick (it's up to 10, not more) and in clean branch squash afterwards. |
| 01:22 | mk01_ | so yes, it will work |
| 01:23 | sraue | ok, great |
| 01:24 | mk01_ | and that one has to go in https://github.com/mk01/libcec/commit/f03edb8f2d2ce246f7a54f1a55dd18a03f67c493 . it is responsible for 2 different bugs. if not three. |
| 01:25 | mk01_ | just stupid typo with brackets, but quite bad in actions after. |
| 01:28 | sraue | this one looks easy to review :-) |
| 01:35 | mk01 | I suppose |
| 01:35 | mk01 | ;) |
| 01:35 | mk01 | going to sleep |
| 01:35 | mk01 | bye |
| 01:37 | sraue | bye and thanks much for your work and help |
| 01:49 | sam_nazarko | sraue: mk01 I don't think you're going to convert popcornmix; he just took a job at Raspberry Pi and left Broadcom |
| 01:50 | mk01 | but it looks like you are on that direction. being at the right channel at least :) |
| 01:51 | sam_nazarko | me? |
| 02:04 | jmontleon | little load to get the temp up :) http://i8.photobucket.com/albums/a29/jmontleon/load4_zpsb0073939.png |
| 02:05 | jmontleo | 02:05 * jmontleon looks for some water to boil |
| 02:48 | rabeeh | jmontleon: which hb is that? |
| 02:49 | rabeeh | oh; hb-i2ex? |
| 02:49 | jmontleon | i4 |
| 02:49 | rabeeh | oh |
| 02:50 | rabeeh | you are reaching 89c with it? |
| 02:50 | rabeeh | what do you have besides that quad core? |
| 02:50 | jmontleon | yes |
| 02:50 | rabeeh | gpu working? |
| 02:50 | jmontleon | galcore driver is built, but no driver for x11 that works yet |
| 02:51 | jmontleon | xf86-armada dies complaining about not being able to become drm master |
| 02:51 | jmontleon | I guess etnaviv and it still need a little work |
| 02:51 | jmontleon | rabeeh, also cubox-i4 and hummingboard-i2ex |
| 02:52 | jmontleon | hummingboard-i4 has a nice msata drive installed too for / |
| 02:52 | rabeeh | aha |
| 02:52 | rabeeh | which one? any idea about it's power consumption? |
| 02:53 | rabeeh | i measured a lot the power of i4 on HB |
| 02:53 | rabeeh | without the gpu on it's tough to get to such degrees |
| 02:53 | jmontleon | msata? http://www.amazon.com/gp/product/B00BQ8RKT4/ |
| 02:54 | rabeeh | 240GB... nice :) |
| 02:54 | rabeeh | how good is it first of all? |
| 02:55 | rabeeh | i'm searching for specs to see it's power consumption |
| 02:56 | jmontleon | ya, I'm looking too, but it plays well. nice and fast |
| 02:56 | rabeeh | their web site doesn't say |
| 02:58 | jmontleon | one of the comments below on amazon says, "This is a drive which has fairly high power consumption, over 1W at idle and approaching 4W when busy." |
| 02:58 | jmontleon | but I don't know how they got to that conclusion |
| 03:03 | jmontleon | rabeeh, http://www.anandtech.com/show/7594/samsung-ssd-840-evo-msata-120gb-250gb-500gb-1tb-review/8 has power consumption for m500 480G and 960G |
| 03:04 | jmontleon | seems to back up the 1 to ~4W depending on use |
| 03:05 | rabeeh | jmontleon: that's way too high |
| 03:05 | jmontleon | heh |
| 03:05 | rabeeh | that explains why you are getting high temps on HB-i4pro |
| 03:05 | rabeeh | so basically the ssd is heating it pretty high |
| 03:06 | jmontleon | makes sense |
| 03:06 | jmontleon | but they can manage something like 105 safely, no? |
| 03:06 | rabeeh | the processors? |
| 03:07 | rabeeh | it can go even higher (i'v tested 120c) |
| 03:07 | rabeeh | for instance by removing the heatsink; nothing will happen to them |
| 03:07 | jmontleon | nice |
| 03:07 | rabeeh | only your skin when you want to test what 120c on the die means :) |
| 03:07 | rabeeh | well.. i'm exagerating |
| 03:07 | jmontleon | heh |
| 03:07 | rabeeh | typically your skin will die on 140-150c on a silicon die |
| 03:08 | rabeeh | that's when touching the die itself :) |
| 03:08 | rabeeh | i.e. not the heatsink |
| 03:09 | rabeeh | 4am here |
| 03:09 | rabeeh | time to get some sleep. good night. |
| 03:09 | jmontleon | well, im not too worried about it. It hasn't caused a problem. Hindsight being what it is I would have tried one of the samsungs; they're almost half the power consumption when going full tilt, but... |
| 03:10 | jmontleon | good night rabeeh |
| 04:05 | mk01 | jmontleon: on etnaviv build mesa with patched etna support. that means etna is gallium driver (it supports HW acceleration to Mesa's build APIs - EGL/GLES and GLESv2). so you get gallium backed by etna and providing EGL. And through xorg Glamor driver you get Xorg onto etna's EGL. |
| 05:13 | jmontleon | mk01, I'll have to look. I guess I don't understand. I though 3.14.14 was headed to supporting etnaviv with xf86-armada |
| 05:14 | mk01 | I'm just telling there is a way (general). this wasn't about 3.14 |
| 05:16 | mk01 | jmontleon: armada is what. DRI2 ? |
| 05:16 | mk01 | or FB / GLX ? |
| 05:16 | jmontleon | dri2 |
| 05:17 | jmontleon | i've managed to get it working as a kms driving disabling etnaviv and vivante support with the imx-drm driver on 3.17 |
| 05:17 | mk01 | so mesa gallium to EGL/etna ? |
| 05:17 | jmontleon | it unsurprisingly isn't fast, but it works |
| 05:18 | jmontleon | etna |
| 05:18 | jmontleon | I build it with --enable-etnaviv --disable-vivante |
| 05:18 | mk01 | that is what I was telling rabeeh. imx-drm has GEM ioctl, and guys rrom Xorg did small wraper (2k) between GEM and DDX |
| 05:19 | mk01 | so 2D |
| 05:19 | jmontleon | but it dies complaining about being unable to become drm master and from the sounds of it in 3.14.14 it's not a drm driver, so I guess that's sort of expected |
| 05:19 | mk01 | but for 20lines of code |
| 05:19 | mk01 | absolute performance |
| 05:20 | jmontleon | you're way over my head :) I want to build packages so Fedora works. but navigating the current set of dependencies is confusing |
| 05:21 | mk01 | why ? |
| 05:24 | jmontleon | vivante vs. etnaviv (and forks), imx-drm vs. mxc gpu_viv, then I don't understand if mesa comes in somehow, x86-armada, etc. |
| 05:24 | jmontleon | at every layer there seems to be multiple solutions |
| 05:25 | jmontleon | everything else works. Would love to figure out a path to accelerated graphics |
| 05:39 | mk01 | oh yes. this "little" details you mean |
| 05:39 | mk01 | :)) |
| 05:39 | mk01 | it is indeed hell |
| 05:40 | mk01 | it is crazy how much X output to display got complicated |
| 05:40 | mk01 | over the versions and years |
| 05:40 | mk01 | to at the end |
| 05:41 | mk01 | be reverted to the simplest .... |
| 05:41 | mk01 | look at Glamor |
| 05:41 | mk01 | It is again few lines of code |
| 05:41 | jnettlet | glamor is not a few lines of code. |
| 05:41 | mk01 | direct GL call ... going to GPU of gfx |
| 05:41 | mk01 | nothnig more |
| 05:42 | mk01 | (COMPARING TO OTHER WAYS) |
| 05:42 | mk01 | it is true, that it could return because ALL evolved |
| 05:42 | mk01 | to unified GL language as function calls |
| 05:43 | jnettlet | but it hasn't. All the programming has just gone into other subsystems. Rather all existing in the DDX |
| 05:43 | jnettlet | you are way oversimplying what is going on. |
| 05:43 | mk01 | and all gfxchips doing GL |
| 05:43 | mk01 | so easy again |
| 05:43 | jnettlet | all gfxchips also don't do GL. Most embedded GPU's use GLES1/2 which is a subset of GL |
| 05:43 | mk01 | jnettlet; it is NOT that bad |
| 05:44 | jnettlet | GLES1 is closer, but GLES2 is quite different than GL |
| 05:45 | mk01 | of course generally speaking . that I wanted to say. let's look at DRI/GLX design and implementation |
| 05:45 | jnettlet | and glamor is horribly power inefficient using the 3d engine for everything |
| 05:45 | mk01 | put someone behind the sources |
| 05:45 | mk01 | he would think it is warming caffe |
| 05:45 | mk01 | if you open glamor/dx |
| 05:45 | mk01 | ddx |
| 05:45 | mk01 | you see graphics driver |
| 05:53 | mk01 | btw gtkerf |
| 05:53 | mk01 | GtkEntry - time: 0.00 |
| 05:53 | mk01 | GtkComboBox - time: 1.72 |
| 05:53 | mk01 | GtkComboBoxEntry - time: 1.34 |
| 05:53 | mk01 | GtkSpinButton - time: 0.18 |
| 05:53 | mk01 | GtkProgressBar - time: 0.10 |
| 05:53 | mk01 | GtkToggleButton - time: 0.20 |
| 05:53 | mk01 | GtkCheckButton - time: 0.19 |
| 05:53 | mk01 | GtkRadioButton - time: 0.44 |
| 05:53 | mk01 | GtkTextView - Add text - time: 1.26 |
| 05:53 | mk01 | GtkTextView - Scroll - time: 0.41 |
| 05:53 | mk01 | GtkDrawingArea - Lines - time: 2.06 |
| 05:53 | mk01 | GtkDrawingArea - Circles - time: 4.24 |
| 05:53 | mk01 | GtkDrawingArea - Text - time: 1.29 |
| 05:53 | mk01 | GtkDrawingArea - Pixbufs - time: 0.24 |
| 05:54 | mk01 | Total time: 13.67 |
| 05:59 | jnettlet | and the 2D ddx does gtkperf in just under 12 seconds |
| 06:00 | jnettlet | and I bet the 3d core uses 30% more power |
| 06:00 | jnettlet | maybe even 50% |
| 06:00 | jnettlet | bumping the draw from 400mA's to 600 |
| 06:01 | jnettlet | and that is heat and battery life if you are running a laptop |
| 06:01 | jnettlet | so you get worse performance, more power consumption, and shorter battery life. |
| 06:02 | jnettlet | I am not saying there is anything wrong with glamor, but there are trade-offs |
| 06:29 | mk01 | jnett: jmontleon was sking if it runs. next time I tells him no. ok ? :) |
| 06:30 | mk01 | tells him = I tell him |
| 06:30 | mk01 | typo |
| 06:34 | mk01 | jnett: H1 on 3.14 should have network broken ? |
| 06:38 | jnettlet | mk01, the network should be fine |
| 06:38 | mk01 | ok |
| 06:38 | mk01 | then it is still wth the broken systemd <> shim |
| 06:38 | mk01 | on jessie |
| 06:39 | mk01 | as they chenged for ystemd |
| 06:39 | mk01 | systemd |
| 06:40 | mk01 | every iingle action is going through login tracker and session cookies |
| 06:40 | mk01 | and currently if ystemd is not init, it is not working |
| 06:41 | mk01 | booten system without load, no apps, no sessions logged / logged out |
| 06:42 | mk01 | just one bash |
| 06:42 | mk01 | and suddenly ssh refusing connections |
| 06:42 | mk01 | for hours |
| 06:43 | mk01 | then it again works. network was new rurprise. eth0 is up. LED is signalling traffic. but eth0 registers none as interface |
| 06:44 | mk01 | I thought it is eth0 problem so plugged dongle. wlan0 registered fine. |
| 06:44 | mk01 | trafik none |
| 06:45 | mk01 | worst thing is that this experimenting is with Jessie for more than 3 months . |
| 11:24 | mk01 | toto asi tiez nie je ok, ze ? |
| 11:24 | mk01 | xbian@cubox ~ $ systemctl -a |
| 11:24 | mk01 | Failed to get D-Bus connection: No connection to service manager. |
| 16:15 | mk01_ | jnettlet: you pyt the code to hdmi to change quant range from sysfs |
| 16:15 | jnettlet | mk01, yes |
| 16:15 | mk01_ | jnettlet: only the sysfs file is 444 |
| 16:16 | mk01_ | ;) |
| 16:17 | mk01_ | so put on a note to change . |
| 16:18 | jnettlet | mk01_, the module parameter is 444, that is not the sysfs interface. |
| 16:19 | mk01_ | ehm |
| 16:19 | mk01_ | then missed the other record somewhere |
| 16:19 | mk01_ | mea culpa |
| 16:19 | mk01_ | yes |
| 16:19 | jnettlet | it is buried down under the device file. But it is how all the other sysfs nodes are exposed |
| 16:19 | mk01_ | of course |
| 16:20 | mk01_ | with the other parameters |
| 16:20 | mk01_ | yes all |
| 16:20 | jnettlet | you are looking at the module parameter which I added because people requested a kernel commandline interface |
| 16:20 | jnettlet | and I didn't want to make that R/W without adding the other parameters. |
| 16:20 | mk01_ | no no that's as it shou7ld |
| 16:21 | mk01_ | shoould |
| 16:21 | mk01_ | just I always forget the paths |
| 16:21 | mk01_ | so using find with THE same file name |
| 16:21 | mk01_ | didn't realise I'm under wrong tree |
| 16:22 | mk01_ | are you considering going for |
| 16:22 | mk01_ | imxdrm (-hdmi, -fbdev) ... assuming from the intensive repatching lately ? |
| 16:23 | jnettlet | only for dev releases. There is a lot of work to bring the ipu and vpu around to be functional with it |
| 16:23 | jnettlet | and Android still needs fbdev |
| 16:24 | mk01_ | yes I know. HDMI comparing to mxc (as it got patched inbetween) was also miles back |
| 16:25 | mk01_ | and now serious Q. got H1. |
| 16:25 | jnettlet | yes |
| 16:25 | mk01_ | Q1 - galcore needs 256 as cma ? |
| 16:25 | mk01_ | iwht any other (lower) number I could not get it loaded |
| 16:25 | jnettlet | it does not, but both the gpu and vpu share that pool |
| 16:25 | mk01_ | ok |
| 16:26 | jnettlet | but that is what is nice about CMA is that if those devices aren't using it the kernel will allocate for other things |
| 16:26 | mk01_ | sure - just was nerwous about te errors |
| 16:26 | mk01_ | then realised it is only too low |
| 16:26 | mk01_ | 2Q! |
| 16:26 | mk01_ | 2Q |
| 16:27 | mk01_ | had to adapt arch imx 6 sl driver |
| 16:27 | mk01_ | for DMA map |
| 16:27 | mk01_ | is it working to others with stock kernel ???? |
| 16:28 | jnettlet | the upstream kernel, or the FSL kernel? |
| 16:28 | jnettlet | for 3.14.14 I only imported the iMX6SL stuff needed to make other patches merge. We aren't supporting it because we don't have any devices with that SOC on it |
| 16:29 | mk01_ | stock = i mean ours |
| 16:31 | mk01_ | OK than I have had messed DTS file |
| 16:32 | jnettlet | this is for the SDMA engine? |
| 16:33 | mk01_ | kernel is matching its platform code accorging to sting from dtb, right ? |
| 16:33 | mk01_ | sting = string |
| 16:33 | jnettlet | yes |
| 16:33 | mk01_ | because as I booted it as received |
| 16:34 | mk01_ | ID according kernel line was: from SPL: duallite |
| 16:34 | mk01_ | from kernel "sololite" |
| 16:35 | jnettlet | on SolidRun hardware? |
| 16:35 | mk01_ | H1 |
| 16:35 | jnettlet | It should say Solo/DualLite |
| 16:35 | mk01_ | and imx6sl.c doesn't have dma_zone defined |
| 16:36 | jnettlet | imx6sl is a different SOC that we don't use. |
| 16:36 | mk01_ | and due to he default (256MB ???) shift |
| 16:36 | jnettlet | we have imx6s imx6dl imx6d imx6q |
| 16:36 | mk01_ | CMA was mapped out of its 512mb on board |
| 16:36 | jnettlet | they get grouped together as imx6s/dl and imx6d/q |
| 16:37 | mk01_ | ok easy to fix, just who was putting kernel on the card messed this a bt |
| 16:37 | mk01_ | imagine the device is running week OK |
| 16:37 | mk01_ | on it |
| 16:38 | jnettlet | just note you do need the MX6_SOLO enabled in the kernel config, otherwise some of FSL's drivers break. They share code. I have some patches to clean that up but haven't pushed them yet |
| 16:39 | mk01_ | I know. that's why it wasn't THAT much strange to me (in meaning of BAD) |
| 16:40 | mk01_ | just the DMA shifted wrongly -> unusable was really strang |
| 16:40 | mk01_ | strange |
| 16:40 | mk01_ | because that would make all H1 users without GPU |
| 16:40 | mk01_ | o good that I asked |
| 16:41 | joelbaby | which .dtb file does the Cubox-i2Ultra use? the one with 2 cores and has vivante gc2000. |
| 16:42 | jnettlet | joelbaby, imx6q-cubox-i.dtb |
| 16:42 | joelbaby | thanks. |
| 16:42 | jnettlet | joelbaby, if you are using the default uboot it will autoconfigure that |
| 16:44 | joelbaby | oh, and should we git clone from jnettlet branch or solidrun now if we compile our own kernel? |
| 16:44 | mk01_ | jnettlet: could be that also reason why was the H1 constantly overheating ? 4mibutes ok, then 1minute at 1/64 |
| 16:45 | jnettlet | joelbaby, SolidRun is the stable branch. My branch is development and could be broken |
| 16:46 | jnettlet | mk01_, depends what you are doing. But generally we are continually optimizing the software. Recently we have found that we are more likely to overheat the SOC's, even the iMX6S |
| 16:46 | jnettlet | I am working on a better thermal management system |
| 16:46 | joelbaby | if your branch is broken, then solidrun's is a mere pile of sticks. |
| 16:47 | jnettlet | joelbaby, I am not saying it is broken, but it is possible I may break things as it is a development branch |
| 16:48 | mk01_ | jnettlet: nothing much. having it turned on for development - so basically doing nothing. |
| 16:48 | jnettlet | yeah, that shouldn't be happening |
| 16:48 | jnettlet | the default interactive cpu scaling governor? |
| 16:51 | joelbaby | would be good to have some kind of standby mode using <1W power. |
| 16:51 | joelbaby | then cubox-i could run off a battery pack |
| 16:51 | joelbaby | but minimum power is always around 3.5W |
| 16:51 | jnettlet | that seems very high |
| 16:51 | mk01_ | jnettlet: no. have admit to. was running full clock. |
| 16:51 | jnettlet | what are you running on it |
| 16:52 | mk01_ | but basically no load |
| 16:52 | joelbaby | geexbox, but putting fedora on today to take a look. |
| 16:52 | joelbaby | 3.5W is pretty much the minimum on a cubox-i2u |
| 16:52 | jnettlet | joelbaby, the problem with xbmc is it is always drawing the scrolling screen, which uses cpu and gpu power. |
| 16:52 | joelbaby | ok, i'll kill it and see what that does |
| 16:52 | jnettlet | so it is never really idle |
| 16:53 | jnettlet | if you aren't actively doing anything on it. The low power state will kick in which is less than 100mA's |
| 16:53 | jnettlet | I generally see it down around 92 |
| 16:53 | mk01_ | jnettlet: i have patch (quite simple) which is turning renderer COMPLETELY of according to hdmi (TV) state |
| 16:54 | joelbaby | Is there a way to manually select the low power state? |
| 16:54 | mk01_ | so as you change source or tv off, XBMC is gong 1% |
| 16:54 | joelbaby | at the command line |
| 16:54 | jnettlet | mk01_, for xbmc? |
| 16:54 | mk01_ | yes. |
| 16:55 | jnettlet | joelbaby, no it is done dynamically right now. freescale has it implemented rather rudimentary, I want to integrate it more into the newer kernels dynamic power management infrastructure |
| 16:55 | mk01_ | joelbaby: currently no, but it can be integrated into XBMC event system |
| 16:55 | jnettlet | mk01_, push it to the repos |
| 16:55 | mk01_ | and then you can control it with ES |
| 16:56 | jnettlet | joelbaby, we do have S/R working now, where Suspend to memory gets us down into the 30mA range |
| 16:56 | jnettlet | however I still have some more driver space work to get that fully exposed to userspace. |
| 16:57 | jnettlet | basically we don't have anything setup to wake the machine back up by default. |
| 16:57 | joelbaby | yes, it would need WOL, CEC, and IR |
| 16:57 | joelbaby | that's the problem with suspend modes |
| 17:01 | joelbaby | even with xbmc not running i'm still on 3.9W |
| 17:03 | jnettlet | that is 780mA's that still seems really really high. This is with my 3.14.14 kernel? |
| 17:06 | joelbaby | ok, down to 2.2W now |
| 17:06 | joelbaby | that's just a login prompt. |
| 17:06 | joelbaby | =440mA |
| 17:07 | joelbaby | and a USB keyboard probably using 30-40mA last time i looked |
| 17:08 | jnettlet | are you using gigabit ethernet? |
| 17:08 | joelbaby | with 3.14.14 |
| 17:08 | joelbaby | nope |
| 17:08 | joelbaby | 100Mbit |
| 17:08 | jnettlet | okay that saves you 100mA |
| 17:08 | jnettlet | any other USB devices? |
| 17:09 | joelbaby | i'll yank out some cables ;) |
| 17:09 | jnettlet | hdmi is like 40mA's |
| 17:09 | joelbaby | yup -hdmi 2.1W |
| 17:09 | joelbaby | ethernet yanking out did nothing. |
| 17:10 | joelbaby | -ethernet 1.9W |
| 17:10 | joelbaby | -usb wireless kb = 1.8W |
| 17:10 | joelbaby | -power cord = 0W :) |
| 17:12 | jnettlet | I do know that I need to patch the GPU to be better at letting the SOC go into deep idle |
| 17:12 | jnettlet | like I said I am working on re-architecting the PM stuff |
| 17:12 | joelbaby | yeah, that's why i thought I'd mention it now. |
| 17:52 | joelbaby | after issuing shutdown in fedora, power usage = 3.2W |
| 18:53 | sraue | rabeeh, mk01_ http://www.solid-run.com/community/topic1498-70.html#p12121 looks like CEC is working for more users then me alone, thanks much mk01_! :-) |
| 18:55 | malte | great work! |
| 18:55 | malte | will test it later |
| 19:06 | mk01_ | sraue: as we discussed yesterday - https://github.com/mk01/libcec-1 - branch rpi-fixes is already with PE - branch imx6 is pure imx6 support on two commits (1st wolfgar + 2nd myself) - libCeC is PE master + the one critical fix |
| 19:09 | mk01_ | all is it refork of PE repo, not wolgars to allow direct pull/merge. although I realised today the GIT already integrated ANY directions ANY repo (if hared some history). that wasnt working before. |
| 19:10 | sraue | mk01_, for the imx6 branch, maybe you could rebase?, there are wolfgars patches somewhere in 2013 and yours on top, i think this should be squashed together on top of libcec master |
| 19:11 | sraue | also i think wolfgar need to sign this Pulseeight contract or what this is ? |
| 19:13 | mk01_ | no big deal |
| 19:13 | mk01_ | actually a form name signature you agee |
| 19:13 | mk01_ | agree |
| 19:14 | sraue | yeah, will speak with opdenkamp, hope i see him soon |
| 19:14 | mk01_ | theoretically he can say he did that for our project and this is covered in XBian PE contract as internal matter (emploee and employer ) |
| 19:14 | mk01_ | but really to sign it is not problem |
| 19:15 | mk01_ | event it will guarantee his ownerhip on the code |
| 19:15 | mk01_ | not PE |
| 19:16 | mk01_ | I can send you email of office guy they have to manage this paper work |
| 19:16 | mk01_ | this will be faster for you |
| 19:16 | sraue | i know... its because of this dual licensing, but i think as the original dev he should sign this |
| 19:16 | mk01_ | SURE |
| 19:17 | mk01_ | this is the guy [email protected] |
| 19:18 | sraue | i know |
| 19:18 | mk01_ | he will manage it anyhow so do it now then once opdenkamp manages time you don;t have to waste time |
| 21:59 | wrexem | @rabeeh, did you see my post a minute ago? |
| 21:59 | wrexem | in the forums |
| 22:00 | wrexem | I also - I think - tried to do a pull request with at least part of the fix. |
| 22:01 | wrexe | 22:01 * wrexem makes cricket noises. |
| 22:01 | wrexem | :D |
| 22:04 | wrexem | brb |
| 22:06 | wrexe | 22:06 * wrexem makes more cricket noises. |
| 22:06 | wrexem | Anyone awake out there? Interested developer here, talking to himself. ;) |
| 22:12 | rabeeh | wrexem: i'v seen the patches |
| 22:12 | rabeeh | dear - you need first to change your editor that 'tab' is a real 'tab' and not 8 characters :) |
| 22:12 | rabeeh | notice that those patches will be upstreamed in some point by rmk :) |
| 22:12 | malte | yes |
| 22:13 | malte | wrexem thank u for waking me up :) |
| 22:17 | dv_ | gstreamer has some automated style checkers for that |
| 22:17 | dv_ | these script check your code before you commit it |
| 22:18 | wrexem | I think.. you're welcome. |
| 22:18 | wrexem | lol |
| 22:25 | wrexem | So, 3.14 doesn't like the pcie |
| 22:27 | wrexem | never saw this channel before; just noticed it in your sig rabeeh |
| 22:27 | wrexem | I'm excited; there are a lot of people here! |
| 22:27 | rabeeh | yup |
| 22:27 | rabeeh | welcome to the fun place :) |
| 22:28 | wrexem | So, let me tell you what I'm (trying) to work on. |
| 22:28 | wrexem | Or maybe, tell you what I've accomplished so far. |
| 22:29 | wrexem | I'm a little bit noob, so you'll have to forgive me if I have no clue what I'm talking about sometimes. |
| 22:29 | wrexem | I built a VM, on centos, for doing cross compiling. |
| 22:30 | wrexem | I'm planning to offer that up to the community, if anyone wants it; basically it has all the goodies set and you just set up your cross compile stuff. |
| 22:30 | wrexem | and press make |
| 22:30 | wrexem | It uses crosstool-ng |
| 22:31 | wrexem | So I've got that for doing compiling... and I'm working on this whole pci-e thing - doesn't seem like a major issue to most people, but I think it's one of the most interesting features of the board so I'm pretty focused there... |
| 22:31 | wrexem | e.g. I think it will be awesome to stick extra USB ports or wifi+bt cards on there. |
| 22:31 | wrexem | 4g... |
| 22:32 | wrexem | But yeah, need a place to host this vmdk for the cross compiling thing. Zips down to about 3GB. |
| 22:32 | wrexem | Anyone interested? |
| 22:33 | wrexem | The other thing I'm trying to get to work is mplayer from the command line - no x etc, and get it working with nice fast acceleration - it sounds like someone was working with gstreamer, I think that might be helpful as well. |
| 22:37 | wrexem | I went all crazy and bought an SSD so everything I'm running is on that too; pretty awesome. :) |
| 22:41 | wrexem | Anyone curious about write performance on that SSD? |
| 22:42 | wrexem | dd if=/dev/zero of=/testfile.0 bs=8M count=1000 ==> 96.7 MB/s |
| 22:42 | wrexem | Man these crickets are loud. :P |
| 22:46 | wrexem | Oh and I also figured out how to rsync my hummingboard from my compiler machine so it gets the goods after I run make on the CX |
| 22:53 | wrexem | haha, that's pretty neat :P |
| 22:53 | wrexem | dd if=/dev/zero of=/testfile.0 bs=32M count=20 => reboots after about 5s |
| 23:00 | wrexem | well, I'm going to leave this open overnight... maybe by tomorrow someone will say something lol |
| 23:21 | dv_ | wrexem: pcie is under development iirc |
| 23:22 | dv_ | as for gstreamer, you can use my gstreamer-imx plugins for that |
| 23:32 | jmontleon | wrexem you're saying writing to msata is causing a reboot? /me hasn't had any problems |
| 23:35 | jmontleon | wrexem, you may be interested in this: http://www.solid-run.com/community/topic1329.html |