| 23:59 | _rmk_ | rabeeh: dual licensing has never been a problem |
| 23:59 | Bluerise | +same/similar |
| 00:00 | _rmk_ | the stuff I write gets GPLv2 because that's the license I'm happy with, but if we want to share it with openbsd, I'm happy to add something else too for those DT bits which I own. |
| 00:02 | Bluerise | I'd love a dual license on the device tree sources. |
| 00:04 | _rmk_ | ok, it'll take more than just me to get a complete solution: in this case I think that includes pengutronix and/or freescale. imx6dl.dtsi claims to be authored by freescale. |
| 00:05 | Bluerise | so does imx6q.dtsi, which I just had opened |
| 00:08 | Bluerise | What I dream of is having one device tree which works on multiple OSes |
| 00:08 | Bluerise | I think freebsd has just crafted its own DTSes |
| 00:13 | _rmk_ | well, that's one of the points of DT. |
| 00:13 | _rmk_ | but in any case, it shouldn't really matter what the license is on the DT source: it's not supposed to be OS specific |
| 00:14 | _rmk_ | and one day it _should_ be moving out of the kernel source into a separate project |
| 00:14 | Bluerise | Currently it matters, as it has a license tag. But one day it shouldn't anymore. |
| 00:14 | Bluerise | I agree. |
| 00:15 | _rmk_ | no, it has to have a license tag, because the law defaults to "restrictive copyrighted work" unless there's something to say otherwise |
| 00:15 | Bluerise | true that |
| 00:15 | Bluerise | but something like /* public domain */ might be enough |
| 00:16 | _rmk_ | or maybe just sticking it under 3-clause bsd |
| 00:16 | Bluerise | Something, that works for everyone. |
| 00:17 | Bluerise | _rmk_: Not sure about your contacts, but I guess you could open that discussion on some mailing list? |
| 00:18 | Bluerise | arch/arm/boot/dts/imx6q-pinfunc.h |
| 00:18 | Bluerise | this might need that, too... |
| 00:20 | _rmk_ | Well, I've just pinged someone about the general question on this. |
| 00:21 | _rmk_ | bear in mind that lots of people are probably travelling today/tomorrow away from the kernel summit meet up in Edinburgh, and next week some of them will be at Linaro Connect, so it may take a while to get answers |
| 00:21 | _rmk_ | and it looks like the UK will be subjected to a nasty storm tomorrow/tomorrow night |
| 00:22 | _rmk_ | so there may be travel disruption for people leaving Edinburgh if they haven't already left |
| 00:23 | Bluerise | Heh. :) |
| 00:23 | jnettlet | Bluerise, _rmk_, This falls under my thoughts that the device-tree should have its own repo, much like pci-ids does |
| 00:23 | Bluerise | I think I met Arnd Bermann at some German ARM conference |
| 00:23 | Bluerise | some Linaro guy |
| 00:23 | Bluerise | Was quite insightful chatting with him :) |
| 00:25 | jnettlet | _rmk_, did your Cubox survive the trip? |
| 00:25 | _rmk_ | jnettlet: yep, it was just the hotel tv being silly |
| 00:25 | jnettlet | great |
| 00:25 | Bluerise | jnettlet: I don't really care if it's in an own repo or not. I'm also fine with Linux maintaining it, as most of the work is done there. |
| 00:25 | Bluerise | jnettlet: But yes, I guess a separate repo/maintainer would be better. |
| 00:26 | _rmk_ | which is what I suspected from day 1 because it was doing 1080p but when music starts/stops or on some track changes, the tv would briefly blank |
| 00:27 | _rmk_ | Bluerise: long term we need it to be a separate project to persuade kernel devs that they shouldn't keep changing stuff in there with changes in the kernel... it makes it much more obvious to people that its supposed to be independent of the kernel version |
| 00:28 | jnettle | 00:28 * jnettlet off to bed. ttyl |
| 14:50 | jnettlet | _rmk_, any signs of the storm yet? |
| 14:54 | _rmk_ | its a little windy, but one site I looked at this morning suggests the strongest winds will be in France |
| 14:55 | _rmk_ | and it'll just be a bit blustery here |
| 14:56 | _rmk_ | I have a suspicion that they're all being ultra cautious though; they don't want to become the next Michael Fish (though I pitty him because everyone quotes him out of context and he was actually correct; it's people's understanding of what he said was wrong.) |
| 15:37 | jnettle | 15:37 * jnettlet googles "Michael Fish" |
| 15:38 | _rmk_ | http://www.youtube.com/watch?v=uqs1YXfdtGE |
| 15:40 | jnettlet | seems pretty reasonable to me. |
| 15:40 | _rmk_ | yea, because the storm that night was not a hurricane |
| 15:41 | Bluerise | Oh, rain is starting here. |
| 15:41 | jnettlet | It has been pretty rainy with strong winds for the last couple of days |
| 15:43 | _rmk_ | http://www.bbc.co.uk/news/uk-19923565 |
| 15:44 | Bluerise | It's been pretty sunny until now actually. |
| 16:19 | jnettlet | _rmk_, is your next project the imx-drm rewrite? |
| 16:21 | _rmk_ | it can be, but I want to first concentrate on a few drm core bits first which should make that easier |
| 16:22 | jnettlet | hopefully device dependencies |
| 16:25 | _rmk_ | talking to Daniel Vetter at KS, he pointed out that at the moment DRM unload is very risky |
| 16:26 | _rmk_ | like... it just pulls things out when shutting down and hopes for the best |
| 16:26 | jnettlet | haha |
| 16:37 | _rmk_ | btw, pengutronix say they've spent three years battling problems with imx-drm |
| 16:37 | _rmk_ | hardware problems |
| 16:39 | jnettlet | well based on the comments I have read the early imx6q hardware had some problems |
| 16:39 | _rmk_ | the ipu has been around for some time so far |
| 16:39 | jnettlet | really I have run into the same issues with mmp3 chips from Marvell. We constantly had cache problems until the b3 chip release |
| 16:42 | jnettlet | sometimes you just need someone to step in and give a fresh look to get things back on track. |
| 16:42 | _rmk_ | hmm. |
| 16:42 | jnettlet | I read through it a bit over the weekend, and it is messy but nothing looks unfixable. |
| 16:43 | _rmk_ | I think I may need to resolder the optical out on the cubox. |
| 16:43 | jnettlet | quick do it before the big storm! |
| 16:43 | _rmk_ | I may see about drilling a hole in the metalwork to make that more secure |
| 16:43 | _rmk_ | its rather floaty - it seems to rely on just being soldered via its pins to the upper board |
| 16:44 | jnettlet | you should also charge up your XO-4! nothing better than vMeta decoded playback on battery when the power is out. |
| 16:45 | _rmk_ | I think if the power goes out, even though I have a UPS, I may have some major problems. |
| 16:45 | _rmk_ | I don't think the network has ever been completely off for the last 15+ years. |
| 16:46 | jnettlet | not much upgraded to SSD then. |
| 16:48 | _rmk | 16:48 * _rmk_ doesn't want SSDs yet. Don't trust them not to lose data. |
| 16:53 | _rmk | 16:53 * _rmk_ grumbles about g+ not letting me tag myself in Thorsten's photo of us all. |
| 17:06 | _rmk_ | well, I just looked at the barometer again... it's risen slightly. |
| 18:27 | _rmk_ | jnettlet: 21: 0 orion_irq kirkwood-i2s |
| 19:07 | jnettlet | _rmk_, the soldering job was successful? |
| 19:07 | _rmk_ | haven't done that yet. |
| 19:08 | jnettlet | is that just the new audio solution? |
| 19:09 | _rmk_ | its what I just posted to g+ |
| 19:09 | jnettle | 19:09 * jnettlet goes to look. |
| 19:10 | jnettlet | oh very cool |
| 19:11 | _rmk_ | I need to check vlc plays properly |
| 20:16 | _rmk_ | DPCM just failed with vlc. |
| 23:48 | dv__ | jnettlet, _rmk_ : did you by any chance see something about a PLL hooked between the audio I2S connection and the clock? |
| 23:49 | dv_ | thats useful if the PLL can be adjusted by several ppm, so synchronize receivers to sender clocks. calculate the difference between clock speeds in ppm, set the PLL accordingly. |
| 23:49 | dv_ | I think I saw something like that in the big imx PDF, but I cant find it anymore. |