| 09:58 | MikeSeth | hey rabeeh |
| 09:59 | MikeSeth | looked for me? |
| 11:21 | MikeSet | 11:21 * MikeSeth pokes rabeeh |
| 11:45 | rabeeh | xraxor: ping |
| 11:45 | xraxor | hi |
| 11:46 | rabeeh | so i'v sent an update yesterday night. |
| 11:47 | rabeeh | http://imx.solid-run.com/forums/viewtopic.php?f=2&t=279 |
| 11:47 | rabeeh | just after you left the channel |
| 11:47 | xraxor | great. I seen it! |
| 11:48 | xraxor | whats the feedback been like? |
| 11:49 | xraxor | this will help some of the customers to hold on a bit more :) |
| 11:49 | xraxor | so the i4 are meant to arrive to solidrun this week? |
| 11:51 | rabeeh | xraxor: the feedback was really positive; but this doesn't mean we are not 1 week late ! |
| 11:51 | rabee | 11:51 * rabeeh hates to be late |
| 11:51 | rabeeh | for when; operations will provide a plan today and we will publish it. |
| 11:53 | xraxor | today? great |
| 11:53 | xraxor | this is great. keep the hopes up :) |
| 11:53 | xraxor | hope the plan is good ;) |
| 11:55 | xraxor | is it possible for you to post an quick update about the OS distros? like when the guys receive theirs i1 and i2 will they be able to install android or xbmc distro? |
| 12:52 | MikeSeth | rabeeh: poke |
| 12:52 | rabeeh | MikeSeth: pong |
| 16:21 | _rmk_ | yay, now importing bmm buffers into vmeta and retrieving their details from there |
| 16:54 | _rmk | 16:54 * _rmk_ kills that bit in the bmm stuff |
| 16:55 | _rmk_ | ... thereby making bmm even smaller |
| 16:57 | Coolgeek | in the end, there will be not bmm module anymore :> |
| 16:58 | _rmk_ | $ wc -l drivers/misc/bmm_drv.[ch] |
| 16:58 | _rmk_ | 651 drivers/misc/bmm_drv.c |
| 16:58 | _rmk_ | 60 drivers/misc/bmm_drv.h |
| 16:58 | _rmk_ | $ wc -l *.[ch] |
| 16:58 | _rmk_ | 38 bmm_drv.h |
| 16:58 | _rmk_ | 250 bmm_lib.c |
| 16:58 | _rmk_ | 56 bmm_lib.h |
| 16:58 | _rmk_ | 549 rb.c |
| 16:58 | _rmk_ | 128 rb.h |
| 16:58 | _rmk_ | and it'll use CMA if CMA is enabled |
| 16:59 | _rmk_ | and it's not bmm as you know it either - it's 100% rewritten now |
| 16:59 | Coolgeek | for a further integration in the mainline kernel ? |
| 17:00 | _rmk_ | everything is a dma_buf... bmm provides no physical addresses either - just a way to get a allocate a dma_buf of a certain size/alignment and - maybe - do some cache flushing on it (which I've not added yet) |
| 17:01 | _rmk_ | you can mmap() them using standard mmap() on the dma_buf fd, and you can get rid of them by calling close() and unmapping all associated mappings |
| 17:01 | _rmk_ | and you can pass them to any other driver which accepts dma_bufs |
| 17:01 | _rmk_ | ... which now includes vmeta |
| 17:02 | _rmk_ | so now, all the nasty "we need a physical address for vmeta" is all contained within vmeta itself |
| 17:02 | Coolgeek | so, bmm is just an interface between memory and driver ? :p |
| 17:03 | _rmk_ | bmm is really just a "please allocate me X bytes of DMA memory and give me a file descriptor to it" interface and nothing more |
| 17:03 | Coolgeek | ok ! |
| 17:04 | _rmk_ | I may consider renaming it "dmm" but that to me means "digital multi-meter" and not "dma memory manager" |
| 17:04 | Coolgee | 17:04 * Coolgeek try to understand you hard work. It's so easy for me ! |
| 17:04 | Coolgeek | not easy* |
| 17:05 | _rmk_ | it basically means we get all the management for these buffers via standard interfaces - and the management effectively comes along for free |
| 17:05 | Coolgeek | yup |
| 17:05 | Coolgeek | I have basic C understanding |
| 17:06 | hste | This vmeta is it for general use or imx6-soc spesific? |
| 17:06 | Coolgeek | I know what is mmap, fd, dma |
| 17:06 | _rmk_ | hste: vmeta is the video decoder on the marvell dove SoCs |
| 17:06 | hste | ok |
| 17:06 | Coolgeek | so I understand what you say right know.. but when you talk with other like dv_ or jnettlet, it become difficult :> |
| 17:27 | jnettlet | Coolgeek, that is okay I don't understand half of what I say either :-) |
| 17:27 | Coolgeek | jnettlet: it's worse than me then :p |
| 17:27 | jnettlet | _rmk_, saw that you got bmm backed with CMA rocking last night. Any surprises? |
| 17:27 | Coolgeek | it's scary |
| 17:28 | jnettlet | kernel geekinese |
| 17:30 | hste | jnettlet: I saw an article about even danish people had problems understanding danish :) |
| 17:31 | _rmk_ | jnettlet: nothing of any note - it's been pretty easy give or take a few bugs |
| 17:32 | _rmk_ | I need to send airlied a dma_buf refcounting fix for v3.12 though - DRM's behaviour changed between 3.11 and 3.12 which caused chaos :p |
| 17:33 | _rmk_ | stracing gstreamer now, I see this: |
| 17:33 | _rmk_ | open("/dev/vmeta", O_RDWR|O_CLOEXEC) = 6 |
| 17:33 | _rmk_ | open("/dev/bmm", O_RDWR|O_CLOEXEC) = 7 |
| 17:33 | _rmk_ | ... |
| 17:33 | _rmk_ | ioctl(7, 0xc0184740, 0xbed99ea8) = 0 |
| 17:33 | _rmk_ | ^^^ allocate dma_buf, returning a fd for it |
| 17:33 | _rmk_ | mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_SHARED, 8, 0) = 0xb5bec000 |
| 17:33 | _rmk_ | ^^^ map the dma_buf |
| 17:33 | _rmk_ | ioctl(6, VIDIOCSCAPTURE, 0xbed99ed8) = 0 |
| 17:33 | _rmk_ | ^^^ import dma_buf into vmeta and return the phys address |
| 17:34 | _rmk_ | and release looks like this: |
| 17:34 | _rmk_ | munmap(0xb5bec000, 131072) = 0 |
| 17:34 | _rmk_ | ioctl(6, VIDIOCSPLAYMODE, 0x1) = 0 |
| 17:34 | _rmk_ | ^^^ drop the dma_buf from vmeta |
| 17:34 | _rmk_ | close(8) = 0 |
| 17:34 | _rmk_ | ^^^ close the fd handle to it |
| 17:36 | _rmk_ | if we're cheeky, we _could_ avoid having the phys address in userspace - by forwarding the register write of the phys address to kernel space but that really doesn't gain us much protection because the address register in vmeta is still exposed to userland |
| 17:37 | _rmk_ | and it also involves much more code in the path to write that |
| 17:37 | _rmk_ | anyway... the next potential stage on this journey is... whether to combine /dev/bmm and /dev/vmeta together |
| 17:45 | prae | Hi all. I'm looking to put together a xbmc image for cuboxi devices, I've been looking around for recommended platforms and see some using yocto, buildroot |
| 17:46 | Coolgeek | see geexbox, if there is a working image |
| 17:46 | prae | I'm happy to put together something based on either of those, but is their an "officially" supported/recommended platfor |
| 17:47 | prae | geexbix doesn't provide what I want - exactly and I will be using to base for a couple of other projects |
| 17:48 | prae | as mentioned I'm happy putting a yocto/buildroot base togeher, but wondering what the shipping base image will be based on |
| 17:48 | Coolgeek | ubuntu I guess |
| 18:16 | jnettlet | hste, don't even get me started on Danish as a language. Having to learn it has been one of the most arduous tasks I have ever attempted. |
| 18:16 | Coolgeek | try learn french :p |
| 18:17 | jnettlet | Not to mention my general anger in having to waste my time and learn a language that only 6 million people speak. It is like if half of NYC had its own language they only they spoke. |
| 18:17 | jnettlet | it makes no sense in the modern day world. |
| 18:19 | jnettlet | last month I was pondering that most good SciFi gets it correct. There needs to be a common language that is used in schools and then local languages are taught and used for language, and local culture and history. |
| 18:20 | jnettlet | and don't get me wrong, I am not saying it has to be english. It should just be something that makes sense. |
| 18:20 | jnettle | 18:20 * jnettlet is done being off topic and going back to arguing with Vivante's power management. |
| 18:20 | hste | :) |
| 18:21 | jnettlet | just needed to vent, sorry guys |
| 18:23 | jnettlet | _rmk_, my only reason at all to keep bmm/dmm/bufmm separate is that it could be useful for all the other existing drivers that need physical addresses exported to drivers running in userspace. |
| 18:24 | jnettlet | _rmk_, in my perusing ION implementation I found that Samsung has copied my ION example to do just that. |
| 18:26 | jnettlet | however since Android doesn't do dmabuf, most those drivers will continue to stick with ION is my guess. |
| 18:26 | jnettlet | but that does still leave us Marvell and Freescale. |
| 18:27 | _rmk_ | dmabuf of course has the advantage that it is already in the kernel, and is already established in various subsystems |
| 18:28 | _rmk_ | now... do I rename this to libdmabuf |
| 18:28 | _rmk_ | and get rid of the bmm_ prefix on all the function names |
| 18:29 | jnettlet | are you going to try and get this accepted upstream? |
| 18:31 | _rmk_ | well, that's always going to be difficult with the userspace blobs - we can't use that as a justification for it |
| 18:31 | _rmk_ | hang on, didn't dv_ say that the freescale video decode is all open source? |
| 18:32 | jnettlet | the userspace part yes. I think it is all ioctl's and register writes |
| 18:32 | jnettlet | not pretty, but open |
| 18:33 | _rmk_ | okay, so we can use that as a justification if we can get it supported there. |
| 18:35 | jnettlet | now the question is, is it worth adding an abstraction for different memory allocation types and undermine the work that Google and Linaro have been doing on Android for the past 2 years :-) |
| 18:36 | _rmk_ | just be aware of this: http://linux.slashdot.org/story/12/10/11/1918251/alan-cox-to-nvidia-you-cant-use-dma-buf |
| 18:36 | jnettlet | just joking. Happy to just have CMA allocations |
| 18:37 | _rmk_ | jnettlet: well... strange you should mention that, because adding several different allocators behind this wouldn't be _that_ difficult |
| 18:38 | jnettlet | _rmk_, well this would actually fix the problem for nvidia. None of the closed source bits ever talk to dmabuf, that is all done through our OSS libraries that get linked to. |
| 18:38 | jnettlet | nvidia wanted to use it directly with their binaries. |
| 18:39 | _rmk_ | yep |
| 18:40 | jnettlet | this is going to ruffle quite a lot of feathers....maybe you should go to the nVidia team |
| 18:47 | _rmk_ | jnettlet: on the other hand, if you read the comparison on http://lwn.net/Articles/480055/, this fills in one of the holes :) |
| 18:49 | jnettlet | oh I am way to familiar with that article. Once we started talking about it yesterday everything just made sense in a simple straight forward way. |
| 18:51 | jnettlet | I think part of the problem with all of this is that all the parties involved got way too caught up in why their way was best. |
| 18:51 | _rmk_ | there's one problem remaining in this which needs solving... |
| 18:52 | _rmk_ | the marvell libcodecvmetadec starts allocating buffers before it initialises the vmeta backend |
| 18:52 | jnettlet | yep |
| 18:52 | _rmk_ | while I can work around that, the problem is how do you shut stuff down |
| 18:53 | _rmk_ | consider something like vlc, where you start something playing, it loads the libraries. you stop it, it unloads the libraries. but the file descriptor for /dev/bmm remains open |
| 18:53 | _rmk_ | when you play again, the libraries get reloaded and /dev/bmm gets opened again |
| 18:54 | jnettlet | why does the /dev/bmm descriptor stay open if the libraries are unloaded? |
| 18:54 | _rmk_ | because there's no way to know when the app has done with it |
| 18:55 | _rmk_ | I suppose I could count the number of buffers allocated, but then I'd have to hold a pthread mutex over every allocation/free call |
| 18:56 | _rmk_ | and I'd prefer not to make it effectively single threaded because of marvell's closed source stuff |
| 18:56 | jnettlet | could you make unmap/free a single ioctl? |
| 18:57 | _rmk_ | the problem extends to /dev/vmeta too when you consider you now need that device node open to get the phys address |
| 18:57 | jnettlet | pid tracking? |
| 18:57 | _rmk_ | pid tracking is just broken :) |
| 19:00 | _rmk_ | well, it's a minor issue - it's something that actually the original stuff leaked too |
| 19:00 | _rmk_ | since nothing ever called bmm_exit() |
| 19:00 | _rmk_ | let me put that a different way: I'm not introducing anything that wasn't already broken :) |
| 19:02 | jnettlet | _rmk_, well gcc would let us work around this. We could set an __attribute__((destructor)) on a function that closes the fd |
| 19:02 | jnettlet | but that would only work for gcc as best as I know |
| 19:03 | _rmk_ | that might be the best solution actually |
| 19:04 | jnettlet | You could probably use that to send one last ioctl to the kernel to do any cleanup in case of an ugly shutdown as well. |
| 19:07 | jnettlet | yeah I think that is the best solution for that problem, can't think of anything else. |
| 19:10 | jnettle | 19:10 * jnettlet is reading more of those slashdot comments. Everyone is like haha this will force Nvidia to open source their IP to use the kernels new features. |
| 19:11 | jnettlet | or wait until other hackers find a way around this because they just want crap to work! |
| 19:19 | _rmk_ | well, if fsl's video decode is 100% open, then I'd like to hack on that... but... first I want the imx drm plane stuff to work properly (iow, with scaling) |
| 19:20 | jnettlet | you will need to talk to dv_ about that |
| 19:21 | _rmk_ | ok, vlc doesn't bother unloading the video decoder! |
| 19:21 | dv_ | hm ? |
| 19:21 | _rmk_ | b3cae000-b3cb0000 r-xp 00000000 08:02 401726 /usr/lib/libbmm.so.3.0.0 |
| 19:21 | _rmk_ | b3cb9000-b3cbc000 r-xp 00000000 08:02 401682 /usr/lib/libvmeta.so |
| 19:21 | _rmk_ | well, the destructor is now there |
| 19:22 | dv_ | _rmk_: there are two places to look at: imx-vpu, and libfslvpuwrap |
| 19:23 | dv_ | currently my plugins use the latter. I plan to move them to the former. libfslvpuwrap is a wrapper around imx-vpu. in theory a nice idea, because imx-vpu is a thin layer above the registers, and the wrapper abstracts away imx version peculiarities. but in practice, the wrapper has some big deficiencies that I can only partially overcome. |
| 19:23 | dv_ | in essence, all imx-vpu does is open /dev/mxc_vpu , read out a base address for the registers, and thats it. |
| 19:24 | dv_ | the rest are functions that wrap register access |
| 19:25 | dv_ | however: the simple buffer pool logic seems to be part of VPU itself (not just imx-vpu), which might be an issue with dmabuf |
| 19:27 | _rmk_ | jnettlet: the destructor works :) |
| 19:27 | _rmk_ | I'll stick that into libvmeta too after supper |
| 19:28 | dv_ | _rmk_: is this about modifications to userspace so the vpu works with CMA dmabufs? |
| 19:28 | _rmk_ | dv: yep - I've got vmeta working with all that now :) |
| 19:28 | dv_ | oh cool |
| 19:28 | _rmk_ | bbiab |
| 19:29 | jnettlet | _rmk_, hurray |
| 20:16 | _rmk_ | okay, vmeta cleanup also works |
| 22:25 | _rmk_ | dv_: I think I can make fsl's vpu work with libav |
| 22:25 | _rmk_ | including for h264 |
| 22:25 | _rmk_ | they seem to provide a way to force new h264 SPS/PPS |
| 22:54 | _rmk_ | http://ftp.arm.linux.org.uk/cgit/libbmm.git/commit/?id=f4c9c43c6b11b80475104b4612a55d0e4a5ad17f |
| 22:55 | _rmk_ | hang on a mo... |
| 22:59 | _rmk_ | http://ftp.arm.linux.org.uk/cgit/libbmm.git/commit/?id=9d2afe8 |
| 23:01 | _rmk_ | that's better... |
| 23:01 | _rmk_ | http://ftp.arm.linux.org.uk/cgit/libbmm.git/commit/?id=2c1e101 |
| 23:17 | _rmk_ | http://ftp.arm.linux.org.uk/cgit/libvmeta.git/commit/?id=c46faad66 |
| 23:27 | dv_ | _rmk_: you mean for encoding? |
| 23:56 | _rmk_ | dv: no, for decoding |
| 23:56 | _rmk_ | DEC_PARA_SET |