| 10:42 | _rmk_ | well, it gave a couple of stupid problems yesterday: the biggy was no audio what so ever; the deferred probing for the device did not work. |
| 11:11 | jnettlet | _rmk_, where were you showing the Cubox off? |
| 11:11 | jnettlet | if you don't mind me asking of course. |
| 12:06 | _rmk_ | jnettlet: not at some big show or anything, just to a group of friends |
| 12:07 | _rmk_ | just enough to ensure that any bug can be triggered with ease |
| 12:08 | _rmk_ | it took quite a while to get audio out of the damned thing, and it also seems that the lost galcore event problem still has a hole somewhere |
| 12:11 | _rmk_ | I should've left the debugging in place |
| 13:08 | dv_ | _rmk_: you mean, audio with this asoc stuff? |
| 13:08 | dv_ | oh, and jnettlet: the increase in current caused by using the GPU is something that can be adjusted? |
| 13:10 | _rmk_ | dv_: no, I had dropped the DPCM stuff out because I don't trust it yet (vlc causes the kernel to oops with it) |
| 13:11 | dv_ | so what are the difficulties? I got audio support out-of-the-box |
| 13:11 | jnettlet | dv_, that is just a problem with the newer chipsets. The older chipsets handled both 2d and 3d operations on the same core. But unfortunately that is with the nearly the slowest frequency. |
| 13:12 | jnettlet | while the gc1000 is a much more powerful GPU it is also a power suck by our standards |
| 13:12 | _rmk_ | dv_: firstly, the deferred probing stuff seems to be racy, and unless it gets solved, it's going to become more painful when distros start shipping single zImage kernels with lots of modules, with multithreaded loading of these modules |
| 13:13 | jnettlet | _rmk_, the deferred probing is racy. We ended up moving around some of our initialization structures to work around it. |
| 13:15 | _rmk_ | here's the details: http://archive.arm.linux.org.uk/lurker/message/20130812.100613.4a2f5183.en.html |
| 13:16 | _rmk_ | I currently see no way for that problem to be solved with a simple patch |
| 13:19 | _rmk_ | what could be done is to set a timer to trigger every 5 seconds to reprobe anything on the deferred queue, but that means every five seconds you'll end up with kernel spew from any driver yet to be probed |
| 13:20 | _rmk_ | and if you consider the implications of that if a driver is loaded but never has its resources satisfied... |
| 13:20 | _rmk_ | and in any case, if the probe is expensive you don't want to run that every five seconds |
| 13:34 | _rmk_ | btw, I noticed a problem on a Panasonic TV: the brightness switches depending on what is being displayed. I suspect that's because we're not sending the proper data to the TV with regards to the RGB range, and its switching between limited range and full range. |
| 13:35 | _rmk_ | ... something else to be solved with the non-NXP TDA998x driver |
| 14:18 | rabeeh | _rmk_: withregards the range; see patch from Rudi - https://github.com/rabeeh/linux/commit/c6c79eda4d81a5a3cd0f1219a2ffd6a7d133f992 |
| 14:52 | _rmk_ | that only works if you're using the NXP driver |
| 14:52 | _rmk_ | ... which is impossible to merge into mainline |
| 14:52 | _rmk_ | so is not useful |
| 14:53 | _rmk_ | the TDA998x driver in mainline does almost nothing with creating the VIF |
| 18:01 | jnettle | 18:01 * jnettlet just continues to wonder how a company is able to pull off what Apple has in terms of fanboyism. They literally have people arguing that marketshare doesn't matter as Apple still has the highest profit margins. |
| 18:01 | jnettlet | we need to get some of that in the Linux hardware space. |
| 18:42 | ojn | Hm, cubox doens't boot on current linux-next. I'll bisect later today. |
| 19:03 | jnettlet | ojn, I was not aware the cubox would boot linux-next without any patches. |
| 19:07 | ojn | jnettlet: depends on what you refer to as booting. it runs just fine with serial console, local storage and network. I don't use graphics (and I don't have anything using usb on this system), so I'm less sure about that. |
| 19:08 | ojn | but i boot it with upstream kernels as part of my automated build/boot environment |
| 19:09 | jnettlet | ojn, interesting good to know. |
| 19:12 | jnettlet | dv_, _rmk_, just looking over the chromecast sources and found that it is using directfb. Google must have been the ones interested in directfb a while back when Marvell and Vivante were harassing me about some of the early testing I had done with 1.6.1 |
| 19:12 | jnettlet | small world. However DirectFB makes a lot of sense for a streaming media player |
| 19:14 | jnettlet | unfortunately their repo does not have any of the libvmeta or libGAL binaries or source in the kernel tree that may be of any interest for poking and prodding |
| 19:31 | dv_ | directfb is interesting, yes |
| 19:32 | dv_ | it doesnt work with x11 though |
| 19:32 | dv_ | then again, I prefer not using x11 unless I have to on an embedded device |
| 20:17 | bencoh | definitely :) |
| 20:21 | dv_ | wayland on the other hand.. |